Oracle software architect Maurizio Cimadamore, who leads the work on Java’s Foreign Function and Memory (FFM) API, reports that the technology is likely to be fully released in Java 22.
“We now believe that the FFM API is largely stable, and that, modulo disasters :-), it should exit preview in the next Java SE release,” Cimadamore said in a port to the Open JDK mailing list. The feature is in its 3rd preview in JDK 21, to be released in September. JDK 22 is set for release in March 2024.
“We’ve been waiting for this day for a long time” said a comment to the post. It is true. A post by Oracle’s John Rose in March 2014 introduced “a new OpenJDK Project, to be titled ‘Project Panama’, for native interconnect between code managed by the JVM and APIs for libraries not managed by the JVM.” Goals for the project included “A better experience than JNI for Java programmers to use C and C++ APIs,” where JNI (Java Native Interface) is the long-standing framework for enabling Java to call native code, introduced in JDK 1.1 in 1997. JNI has multiple issues, being complex to implement and not always performing well – though note that there is no intention to deprecate JNI, which will be supported alongside the new FFM API.
When Java was first introduced, in 1996, developers were encouraged to code purely in Java, to ensure cross-platform capability. The reality though is that native code interop is important for many use cases, for performance of compute-intensive code, access to libraries written in other languages, and access to native platform features.
A goal of the new FFM API, which Cimadamore has been working on (with others) for more than five years, is to “replace the brittle machinery of native methods and JNI with a concise, readable, pure-Java API.” It is also safer to use than JNI, with the intention to “guarantee no use-after-free bugs, even when memory is allocated and deallocated across multiple threads,” though native code interop does have inherent risks which cannot be eliminated.
Use of the FFM API is also made easier by a tool called Jextract, which generates Java bindings from native library header using the clang C API.
The full draft of the Java Enhancement Proposal (JEP) submitted for JDK 22 is here.
“This is huge for using Java with other libraries,” said a developer on Reddit, while another said that “I’ll shift to latest Java Versions because of these features alone.” Use cases mentioned are working with the SQLite 3 database, working with 3D raytracing, and working with binary formats and network protocols.