[HN Gopher] JEP draft: Prepare to restrict the use of JNI
___________________________________________________________________
JEP draft: Prepare to restrict the use of JNI
Author : mfiguiere
Score : 44 points
Date : 2023-09-20 16:26 UTC (6 hours ago)
(HTM) web link (openjdk.org)
(TXT) w3m dump (openjdk.org)
| koito17 wrote:
| 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
| [deleted]
| josephcsible wrote:
| This is going to be just as big of a mess as the --add-opens
| fiasco.
| pjmlp wrote:
| In recent JVM those options are going away, time to update
| naughty dependencies.
| doctorpangloss wrote:
| Nothing is as objectively worthless as modularity.
| pjmlp wrote:
| Hence microservices.
| bitcharmer wrote:
| 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.
| exabrial wrote:
| That didn't take long!
| phoe-krk wrote:
| Bet they've been working on that one before the new API was
| released.
| SOLAR_FIELDS wrote:
| 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.
| grishka wrote:
| 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.
| pjmlp wrote:
| 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.
| bitcharmer wrote:
| 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 wrote:
| This could be a double negative...
| WirelessGigabit wrote:
| 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...
___________________________________________________________________
(page generated 2023-09-20 23:02 UTC)