Coincidentally I just discovered JNI working on a personal project this past weekend - had no idea about all the work in this area! Very cool stuff and great presentation
A great presentation! machine learning in c++ is where the world is going to, with quantized gguf models. if we could catch up to c++ it will definately make java give a serious competition to python in that area.
I have used this and it’s great, but what’s urgently needed is C++ support, otherwise a C interface to all functionality has to be written and maintained for each platform. Also, I have recent migrated all my work to Aarch64, which is not yet supported by jextract, which is a nuisance (it would be more of a nuisance if I didn’t have to write a C layer to C++). Also, using clang? Surely there should be a pure Java solution - no need no install extra C/C++ tools. C++ support is the thing I need most, and I’m sure I’m not alone.
Yeah, that's going to require some work on the C++ side. The main difference between the two is that C has a standardized ABI, which is why it is used to build system libraries and why many other language can generate shared object libraries that conform to the ABI. But C++ doesn't have that; so it's compile to C ABI or bust. Guess there's a reason it's called C++ ("C++ is more that C, but just use C").... That said, the choice in Panama to connect at ABI level already makes so many obstacles go away. I experimented a bit with the preview in Java 19 and talked to code written in Rust. Have fun doing that through JNI.
@@bentels5340 I’ve connected to Delphi using JNI. It’s got some problems. I know C++ makes things tricky, but I would imagine it’s a substantial target for JNI use. I find that once you have set things up so I can develop a C layer to interface to C++ and other languages, JNI doesn’t add that much more complexity. After all, there is work getting data between C and C++. JNI isn’t that bad for this kind of thing if you are already having to manage C interfaces to libraries on each platform. So, until C++ support arrives, it’s JNI for me.
Thanks for the presentation. Looks very promising. I just wish that the "Arena" class was named differently. The current name is very abstract and makes me think of gladiators instead of memory segments. According to the java doc this class manages the lifecycle of memory segments, but this cannot be inferred from its name. So, at the very least it should be named "MemorySegmentArena" (still not great) or something different like "MemorySegmentLifecycleController" or "MemorySegementContainer".
I am starting to have faith in java again.
Coincidentally I just discovered JNI working on a personal project this past weekend - had no idea about all the work in this area! Very cool stuff and great presentation
This is really amazing. Panama looks to mirror python ctypes module features.
A great presentation! machine learning in c++ is where the world is going to, with quantized gguf models. if we could catch up to c++ it will definately make java give a serious competition to python in that area.
JNI version of qsort upcall does not use cached jmethodID. Can this be a reason for bad performance? Was presented code actually used in benchmark?
I have used this and it’s great, but what’s urgently needed is C++ support, otherwise a C interface to all functionality has to be written and maintained for each platform. Also, I have recent migrated all my work to Aarch64, which is not yet supported by jextract, which is a nuisance (it would be more of a nuisance if I didn’t have to write a C layer to C++). Also, using clang? Surely there should be a pure Java solution - no need no install extra C/C++ tools.
C++ support is the thing I need most, and I’m sure I’m not alone.
Yeah, that's going to require some work on the C++ side. The main difference between the two is that C has a standardized ABI, which is why it is used to build system libraries and why many other language can generate shared object libraries that conform to the ABI. But C++ doesn't have that; so it's compile to C ABI or bust. Guess there's a reason it's called C++ ("C++ is more that C, but just use C")....
That said, the choice in Panama to connect at ABI level already makes so many obstacles go away. I experimented a bit with the preview in Java 19 and talked to code written in Rust. Have fun doing that through JNI.
@@bentels5340 I’ve connected to Delphi using JNI. It’s got some problems. I know C++ makes things tricky, but I would imagine it’s a substantial target for JNI use. I find that once you have set things up so I can develop a C layer to interface to C++ and other languages, JNI doesn’t add that much more complexity. After all, there is work getting data between C and C++. JNI isn’t that bad for this kind of thing if you are already having to manage C interfaces to libraries on each platform. So, until C++ support arrives, it’s JNI for me.
Thanks for the presentation. Looks very promising. I just wish that the "Arena" class was named differently. The current name is very abstract and makes me think of gladiators instead of memory segments. According to the java doc this class manages the lifecycle of memory segments, but this cannot be inferred from its name. So, at the very least it should be named "MemorySegmentArena" (still not great) or something different like "MemorySegmentLifecycleController" or "MemorySegementContainer".