4 ms·

JEP draft: Prepare to restrict the use of JNI

47 points by mfiguiere 3y ago

bitcharmer 3y ago
From the JEP: Non-Goals There is no plan to remove JNI from the Java Platform. You will be able to use JNI with a JVM flag set. Therefore no need to panic. Yet.
- josephh 3y ago
  This could be a double negative...
exabrial 3y ago
That didn't take long!
- phoe-krk 3y ago
  Bet they've been working on that one before the new API was released.
josephcsible 3y ago
This is going to be just as big of a mess as the --add-opens fiasco.
- bitcharmer 3y ago
  As much as I hate all the mess caused by Jigsaw, they specifically mentioned JNI is not getting removed. Just accessible behind a JVM flag. It's in the JEP itself.
- doctorpangloss 3y ago
  Nothing is as objectively worthless as modularity.
  - pjmlp 3y ago
    Hence microservices.
- pjmlp 3y ago
  In recent JVM those options are going away, time to update naughty dependencies.
SOLAR_FIELDS 3y ago
Is FFM intended to be a full replacement? I am kind of curious what the differences are in greater detail. A previous place I worked built an entire library mostly around calling C lib from a Java interface.
- pjmlp 3y ago
  In the JVM, long term, yes. On Java based platforms like Android, most likely never. At least since ART became APEX compliant, Java 11 and 17 LTS are now available.
- grishka 3y ago
  The main difference is that for JNI, you need a library that exports specifically Java-callable functions with signatures like void Java_org_package_name_ClassName_method(JNIEnv *env, jobject _this, ...) These are bound to `native` methods in classes when you load the library with `System.loadLibrary()`. Most often these libraries are thin wrappers that call into a C/C++/Rust library and convert data between Java and C representations (especially arrays and strings). It's tedious, it's annoying, and it's a platform-dependent artifact you need to ship with your app and build for all platforms on which your app runs. FFM, on the other hand, is a proper foreign function interface. You don't need any wrappers with it, you'd just load your native library of interest directly and obtain method handles to call its C functions.
  - marwis 3y ago
    On the other hand C/C++ APIs only truly exist in textual format. Without going through C you don't have access to type definitions (you have to redeclare them in Java) or macros (sometimes not even impossible). Structure layout might be different across platforms/versions/variants, symbols can be aliased through preprocessor etc. even though end API is the same. This is a problem with any FFI that tries to avoid C. Look at this mess of trying to do POSIX in JNR: https://github.com/jnr/jnr-posix/tree/master/src/main/java/jnr/posix https://github.com/jnr/jnr-posix/tree/master/src/main/java/j... - each system needs different implementation and within them there is further branching based on versions. There is no guarantee that any of this will work in the future (except on Windows which maintains stable userland ABI).
koito17 3y ago
Honestly, Project Panama seems much more promising for interop with the C ABI from the Java platform. This is anecdotal, but a lot of commercial Clojure projects seem to have a small JNI-using library that nobody dares to touch with a 10 ft. pole lest something in it breaks and debugging is tedious, if possible at all. I've been eagerly waiting for the release of Java 21 since it means projects like coffi[1] can be used in a stable release of Java, and the API is honestly much more ergonomic than dealing with SWIG and using JNI directly. [1] https://github.com/IGJoshua/coffi https://github.com/IGJoshua/coffi
- deleted 3y ago
  [deleted]
WirelessGigabit 3y ago
If we look at the hacks that jRuby needs to do to get the native file pointer is insane. If only where was a simple API that allowed us to get the handle...
sebazzz 3y ago
> Non-Goals > There is no plan to remove JNI from the Java Platform. So it is a goal?

47 points by mfiguiere 3y ago

From the JEP: Non-Goals There is no plan to remove JNI from the Java Platform. You will be able to use JNI with a JVM flag set. Therefore no need to panic. Yet.

josephh 3y ago
This could be a double negative...

exabrial 3y ago

That didn't take long!

phoe-krk 3y ago
Bet they've been working on that one before the new API was released.

josephcsible 3y ago

This is going to be just as big of a mess as the --add-opens fiasco.

bitcharmer 3y ago
As much as I hate all the mess caused by Jigsaw, they specifically mentioned JNI is not getting removed. Just accessible behind a JVM flag. It's in the JEP itself.
doctorpangloss 3y ago
Nothing is as objectively worthless as modularity.
- pjmlp 3y ago
  Hence microservices.
pjmlp 3y ago
In recent JVM those options are going away, time to update naughty dependencies.

SOLAR_FIELDS 3y ago

Is FFM intended to be a full replacement? I am kind of curious what the differences are in greater detail. A previous place I worked built an entire library mostly around calling C lib from a Java interface.

pjmlp 3y ago
In the JVM, long term, yes. On Java based platforms like Android, most likely never. At least since ART became APEX compliant, Java 11 and 17 LTS are now available.
grishka 3y ago
The main difference is that for JNI, you need a library that exports specifically Java-callable functions with signatures like void Java_org_package_name_ClassName_method(JNIEnv *env, jobject _this, ...) These are bound to `native` methods in classes when you load the library with `System.loadLibrary()`. Most often these libraries are thin wrappers that call into a C/C++/Rust library and convert data between Java and C representations (especially arrays and strings). It's tedious, it's annoying, and it's a platform-dependent artifact you need to ship with your app and build for all platforms on which your app runs. FFM, on the other hand, is a proper foreign function interface. You don't need any wrappers with it, you'd just load your native library of interest directly and obtain method handles to call its C functions.
- marwis 3y ago
  On the other hand C/C++ APIs only truly exist in textual format. Without going through C you don't have access to type definitions (you have to redeclare them in Java) or macros (sometimes not even impossible). Structure layout might be different across platforms/versions/variants, symbols can be aliased through preprocessor etc. even though end API is the same. This is a problem with any FFI that tries to avoid C. Look at this mess of trying to do POSIX in JNR: https://github.com/jnr/jnr-posix/tree/master/src/main/java/jnr/posix https://github.com/jnr/jnr-posix/tree/master/src/main/java/j... - each system needs different implementation and within them there is further branching based on versions. There is no guarantee that any of this will work in the future (except on Windows which maintains stable userland ABI).

koito17 3y ago

Honestly, Project Panama seems much more promising for interop with the C ABI from the Java platform. This is anecdotal, but a lot of commercial Clojure projects seem to have a small JNI-using library that nobody dares to touch with a 10 ft. pole lest something in it breaks and debugging is tedious, if possible at all. I've been eagerly waiting for the release of Java 21 since it means projects like coffi[1] can be used in a stable release of Java, and the API is honestly much more ergonomic than dealing with SWIG and using JNI directly. [1] https://github.com/IGJoshua/coffi https://github.com/IGJoshua/coffi

deleted 3y ago
[deleted]

WirelessGigabit 3y ago

If we look at the hacks that jRuby needs to do to get the native file pointer is insane. If only where was a simple API that allowed us to get the handle...

sebazzz 3y ago

> Non-Goals > There is no plan to remove JNI from the Java Platform. So it is a goal?