JEP draft: Prepare to Restrict The Use of JNI

[Sergey Bylokhov]

Hello, Ron.

There is big discussion about this new flag and the new restrictions. I would like to clarify your 
opinion about the next situation. The old options added to the JDK like "--add-opens" forced the 
user to update their code and/or libraries and use some "new or other" API instead of access to some 
internals of the JDK(or some other modules). But this new property restrict an access to some 
API(JNI) which does not have an alternatives. For example if the library uses sound device or uses 
OGL or uses the native file system attributes - what is your expectation about the users of such 
libraries should do? Just use this option at runtime till the end of the world? They cannot migrate 
to other API, they cannot stop using the native code. What other things such users can do?



On 8/21/23 05:41, Ron Pressler wrote:
> JNI has been part of the Java Platform since JDK 1.1, but it is inherently
> unsafe, so we are proposing to restrict the use of JNI in line with the use of
> restricted methods in the Foreign Function & Memory (FFM) API [1].
> 
> The FFM API, expected to become permanent in JDK 22, has methods for interacting
> with native code that are inherently unsafe. To protect the integrity of the
> Java Platform [2], use of these methods is restricted. This means that calling
> them causes warnings, unless the user enables unsafe native access on the
> command line. In a future release, calling them will cause exceptions instead
> of warnings.
> 
> We propose to align JNI and FFM as follows. Starting in JDK 22, the Java runtime
> will give warnings about the use of JNI, unless the user (as for FFM) enables
> unsafe native access on the command line. In a future release, using JNI will
> cause exceptions instead of warnings.
> 
> In other words, our proposal is: In the future, code that uses JNI will run only
> if unsafe native access is enabled, and to prepare for that future, JDK 22
> should spotlight the use of JNI with warnings. We've published a draft JEP that
> explains why using JNI is unsafe and describes the warnings [3].
> 
> We recognize that many applications use JNI and will be impacted by this
> proposal. It is bound to spark discussion that continues even after the
> preparatory warnings in JDK 22. Comments are welcome.

-- 
Best regards, Sergey.