Java Enhancement Proposal Aims to Maintain JNI Standard While Restricting Default Interoperation with Native Code
A new Java Enhancement Proposal (JEP) is addressing concerns about the Java Native Interface (JNI) and its use in future JDK releases. The proposal, named “Prepare to Restrict the Use of JNI,” aims to prepare for a future where interoperation with native code is not the default behavior. Originally created in May 2023 and updated on July 16, the JEP outlines a plan to issue warnings about JNI usage and adjust the Foreign Function & Memory (FFM) API to maintain consistency in these warnings.
The proposal is slated for inclusion in JDK 24, which is expected around March 2025. It suggests that developers will need to explicitly enable JNI and FFM usage at startup, marking a shift from the current approach where JNI usage is more permissive. This change is intended to enhance the security and integrity of Java applications by requiring explicit developer approval for any JNI or FFM interactions.
One key aspect of the JEP is that it does not aim to deprecate or remove JNI from the Java platform. Instead, it focuses on preserving JNI as a standard way to interface with native code while restricting its default use. The JEP outlines that native JNI functions will remain usable, and there are no plans to restrict the behavior of native code called via JNI. The goal is to ensure that JNI usage is controlled and intentional, reducing the risk of compromising application integrity.
The proposal also highlights the intention to align the use of JNI and the FFM API, allowing for smoother transitions between the two. Library maintainers will be able to migrate from JNI to the FFM API without requiring changes to command-line options or developer configurations. This alignment is designed to facilitate easier adoption of newer APIs while maintaining compatibility with existing code.
Overall, the JEP reflects a growing emphasis on maintaining the integrity and security of Java applications. By preparing developers for these changes and providing clear warnings about JNI usage, the proposal aims to strike a balance between preserving JNI’s role and mitigating potential risks associated with native code interoperation.