graalvm 2021-03-19 | Slack Archive

chrisn18:03:55

@borkdude - I have avclj compiling down into a graal native executable that generates video - https://github.com/cnuernber/avclj

phronmophobic18:03:45

is the main Idea using the stuff in JDK-16 instead of jna?

chrisn18:03:04

Graal native has literally nothing to do with JDK-16 or JNA.

phronmophobic18:03:09

I'm just curious how the c ffi is done.

chrisn18:03:35

One second, doing a release because I missed some files in the check-in.

chrisn18:03:11

It takes the same library definition as before but outputs a static class. That uses all the graal native C stuff in order to cause the system to link with the libraries when graal builds the executable.

phronmophobic18:03:12

oh ok. I haven't look at JDK-16, but it seemed plausible that its cffi might be graalvm compatible.

chrisn18:03:42

Not in the least.

chrisn18:03:53

Not even closely compatible at this time. Maybe in the future.

chrisn18:03:04

JDK-16 is way better and more flexible.

chrisn18:03:03

https://github.com/cnuernber/avclj/blob/master/native_test/avclj/main.clj

👍 3

borkdude18:03:44

congrats :)

chrisn18:03:03

I wrote a new dtype-ffi driver.

Huahai21:03:53

i saw some jdk.incubator.foreign classes, so does it rely on some jdk16 features?

chrisn22:03:49

No not at all. My graal install is jvm 1.8

chrisn22:03:50

The system will automatically use what is installed favoring JNA over JDK-16. But for this pathway I hardcoded it for https://github.com/cnuernber/avclj/blob/master/native_test/avclj/main.clj.

Huahai22:03:37

since tech.v3.datatype.ffi.graalvm only works for graalvm, i believe, one has to have write another ffi if running on jvm?

Huahai22:03:51

i saw that you asked in graalvm channel if they are going to unify these, that’s what I wanted to know as well.

Huahai22:03:31

otherwise, it’s a pity having to write two versions of ffi every time, which is what i am doing in datalevin right now

2021-03-19

Channels