We Are Finally Getting Panama

After years of patience and multiple Java Enhancement Proposals, Java’s Project Panama is here.

by

Published

Last Thursday, the finalization of the Foreign Function & Memory Access API (FFMA) was merged into the main OpenJDK repository. Today, some lingering work was merged, and is now considered “final“.

Java has had a crusty and disliked way of interoperating with native code, Java Native Interface (JNI). JNI required, among other things, that native code be written (“glue code”) and then compiled for each target platform.

JNI also has other downsides, like being unsafe and having performance penalties for the interoperation.

Bringing that functionality into the JDK itself allows for developers to interact with native code, without going through the hoops of JNI.

Using the FFMA API will also result in better performance, especially from native code calling Java code (upcalls). By how much? No idea.

FFMA is exciting, and it brings Java into better competition with languages like C#. Developers should thoughtfully move away from using JNI and to FFMA as soon as they are reasonably able to.

Libraries like LWJGL whose sole function is to improve interoperability with special libraries will be so much better. (LWJGL’s maintainer, Ioannis Tsakpinis, says that the plan for LWJGL 4 is to wait for Project Valhalla with value classes.)

JNI has no plans of being removed, but it should be noted that there is a desire to restrict the use of JNI, requiring a flag --enable-native-access to work.

Components inside the JDK itself can also use FFMA’s APIs for calling native code, especially java.desktop, which I hope to return to contributing.