JEP draft: Prepare to restrict the use of JNI

https://openjdk.org/jeps/8307341

by mfiguiere • 3 years ago

47 25 3 years ago

openjdk.org

exabrial• 3 years ago

That didn't take long!

phoe-krk• 3 years ago

Bet they've been working on that one before the new API was released.

josephcsible• 3 years ago

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

bitcharmer2• 3 years 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• 3 years ago

Nothing is as objectively worthless as modularity.

pjmlp3• 3 years ago

Hence microservices.

pjmlp3• 3 years ago

In recent JVM those options are going away, time to update naughty dependencies.

SOLAR_FIELDS• 3 years 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.

pjmlp3• 3 years 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.

grishka4• 3 years 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.

marwis5• 3 years 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/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).

bitcharmer2• 3 years 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• 3 years ago

This could be a double negative...

koito17• 3 years 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

WirelessGigabit• 3 years 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• 3 years ago

Non-Goals There is no plan to remove JNI from the Java Platform.

So it is a goal?

JEP draft: Prepare to restrict the use of JNI

Related Stories