JEP draft: Prepare to restrict the use of JNI | Hacker News Reader

JEP draft: Prepare to restrict the use of JNI

openjdk.org

47 pointsmfiguiere25 comments

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

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.

This could be a double negative...

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...

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.

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.

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.

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).

Panama FFI has a tool called jextract that parses C headers and writes the Java bindings for you.

But can it generate bindings for multiple abi variants?

This would seem extremely complicated to automate.

It can understand preprocessor macros, and the FFI's CLinker class understands different platform ABIs. So I guess you could generate several different packages with variant ABIs, abstract over them and then use whichever one seems to be available.

Abstract over them meaning writing wrappers by hand?

The ABI stuff is taken care of at runtime.

What do you mean?

You only specify the function signatures and structs. The JVM then figures out how to put arguments and return values into registers/stack/whatever at runtime, depending on which OS and CPU it's running on. That's what the `CLinker` class is responsible for. It's like regular dynamic linking, but taken a bit further.

The problem is structs and function signatures of standard APIs can have differences for each os/version combination.

Then you have to take care of making sure you call the right thing. But I suppose this doesn't happen very often because OS APIs usually maintain backwards compatibility. Also a well-designed API would take complex structs by pointer, thus allowing the addition of fields at the end without breaking the ABI.

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

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.

Nothing is as objectively worthless as modularity.

Hence microservices.

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

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

So it is a goal?

That didn't take long!

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

Reply on news.ycombinator.com