6 ms·

If you want to use JNI to interface with an existing C library, you need to write a thin C or C++ wrapper that is called via JNI and interfaces with that C libr

If you want to use JNI to interface with an existing C library, you need to write a thin C or C++ wrapper that is called via JNI and interfaces with that C library. This new Java API allows you to call C functions directly and manipulate data structures on the C side, too. It's also possible to create a C function pointer for a Java method, to enable callbacks/upcalls from C.

dkersten 3y ago
JNA exists which already let you do that. What does this change or add over JNA? https://en.m.wikipedia.org/wiki/Java_Native_Access https://en.m.wikipedia.org/wiki/Java_Native_Access
- thayne 3y ago
  Well for one thing, it is part of OpenJDK, instead of a third party library built on top of JNI, and can thus, at least in theory, integrate better with the runtime.
- MrBuddyCasino 3y ago
  JNI: fast but tedious JNA: comfortable but slow Panama: comfortable & fast
  - matheusmoreira 3y ago
    What is it about JNA that makes it slow? What is it about Panama that makes it fast? Soon I'll start working on similar features for my own language. This could give me a massive head start.
    - pjmlp 3y ago
      Panama is part of the runtime, it can be made to make the best use of that knowledge. JNA relies on JNI, and exposes a better Java interface.
    - fweimer 3y ago
      As far as I understand it, with JNA, all calls into C code go through libffi: https://github.com/java-native-access/jna/blob/master/www/FunctionalDescription.md https://github.com/java-native-access/jna/blob/master/www/Fu... This means that every call sets up some libffi data structures and libffi uses this information to perform the native call. Likewise in the other direction for return values. With JNI (and Panama), Hotspot can directly emit the argument/return code a the call, not too dissimilar from what a C or C++ compiler would do. There is still some overhead from maintaining JVM invariants. For example, I think a thread blocked in an FFI call can still participate in a safepoint. But that applies to JNI as well.
- paulddraper 3y ago
  JNA is 10x slower than JNI. FFM should offer the perf of JNI with the usability of JNA.

dkersten 3y ago

JNA exists which already let you do that. What does this change or add over JNA? https://en.m.wikipedia.org/wiki/Java_Native_Access https://en.m.wikipedia.org/wiki/Java_Native_Access

thayne 3y ago
Well for one thing, it is part of OpenJDK, instead of a third party library built on top of JNI, and can thus, at least in theory, integrate better with the runtime.
MrBuddyCasino 3y ago
JNI: fast but tedious JNA: comfortable but slow Panama: comfortable & fast
- matheusmoreira 3y ago
  What is it about JNA that makes it slow? What is it about Panama that makes it fast? Soon I'll start working on similar features for my own language. This could give me a massive head start.
  - pjmlp 3y ago
    Panama is part of the runtime, it can be made to make the best use of that knowledge. JNA relies on JNI, and exposes a better Java interface.
  - fweimer 3y ago
    As far as I understand it, with JNA, all calls into C code go through libffi: https://github.com/java-native-access/jna/blob/master/www/FunctionalDescription.md https://github.com/java-native-access/jna/blob/master/www/Fu... This means that every call sets up some libffi data structures and libffi uses this information to perform the native call. Likewise in the other direction for return values. With JNI (and Panama), Hotspot can directly emit the argument/return code a the call, not too dissimilar from what a C or C++ compiler would do. There is still some overhead from maintaining JVM invariants. For example, I think a thread blocked in an FFI call can still participate in a safepoint. But that applies to JNI as well.
paulddraper 3y ago
JNA is 10x slower than JNI. FFM should offer the perf of JNI with the usability of JNA.