pron 7 hours ago

FFM is the recommended alternative, but JNI is not being deprecated. There are some things that JNI can do that FFM can't, in particular - initiating calls from native code to arbitrary Java methods. FFM only supports upcalls to Java in the form of Java callbacks that are passed to the native code. However, this is enough for the vast majority of Java-native interactions, so FFM should be preferred in new code (it's much easier to use than JNI).

Reply View 0 replies
cogman10 10 hours ago

Notice the delivery version (24). That was literally just sent out in March. The FFM interface was stabilized in 22. 21 is the latest LTS version which is the furthest most orgs will go.

Reply View 1 reply
  • da_chicken 10 hours ago

    That doesn't mean you should happily go out and build a new cathedral of technical debt.

    Reply View 0 replies
immibis 10 hours ago

This says:

> It is not a goal to deprecate JNI or to remove JNI from the Java Platform.

It says they want to put a safety barrier in front of JNI, so you'll have to explicitly indicate that you want a module to use JNI.

Reply View 1 reply
  • aeonik 6 hours ago

    I know that's the goal, but I was doing deeper reading and didn't understand the nuances here. It felt deprecated, and I remember reading that you should prefer FFM.

    That's one of the reasons I posted it. A lot of knowledgeable people here can chime in more details. And a sibling comment did!

    Reply View 0 replies