OpenJDK plan calls for restricting JNI usage

A proposal to preserve the status of Java Native Interface (JNI) as a standard way to interoperate with native code is moving forward in the Java community.

Originally created in May 2023 and updated on July 16, the JDK enhancement proposal (JEP), called “Prepare to Restrict the Use of JNI,” is slated for JDK 24, which would not likely arrive until March 2025. The proposal calls for  warnings about uses of JNI and adjusting the Foreign Function & Memory (FFM) API to issue warnings in a consistent manner. These warnings are intended to prepare developers for a future release that disallows interoperation with native code by default, whether via JNI or the FFM API. As of that release, developers will have to explicitly enable the use of JNI and the FFM at startup.

In addition, the plan would align the use of JNI and the FFM API so that library maintainers can migrate from one to the other without requiring developers to change any command-line options. Non-goals include deprecating JNI or removing JNI from the Java platform and restricting behavior of native code called via JNI. As an example, all of the native JNI functions would remain usable by native code.

JNI was introduced in JDK 1.1, which dates back to February 1997, as the primary means for interoperating between Java code and native code, typically written in C. The interface allows Java code to call native code (a downcall) and native code to call Java code (an upcall). But any interaction between Java code and native code is risky because it could potentially compromise the integrity of applications and the Java platform itself. Based on the policy of integrity by default, all JDK features capable of breaking integrity by default must obtain explicit approval from the application’s developer.