EP 472: Prepare to Restrict the Use of JNI
This seems like the correct approach. There are real perils associated with interoperating Native and Java Code they are necessary but should be done with care and attention. I think it’s wise to approach this with a balance approach like the one used in FFM.
The stated goals are to:
- Preserve the status of JNI as a standard way to interoperate with native code.
- Prepare the Java ecosystem for a future release that disallows interoperation with native code by default, whether via JNI or the FFM API. As of that release, application developers will have to explicitly enable the use of JNI and the FFM API at startup.
- Align the use of JNI and the FFM API so that library maintainers can migrate from one to the other without requiring application developers to change any command-line options.
Uniformly applying the restrictions and raising runtime warnings consistent with Foreign Function & Memory (FFM) API will likely be welcomed by most developers. As will the ability to turn the warnings off with boot time command arguments.
