JEP draft: Prepare to Restrict The Use of JNI

[Peter Tribble]

Hi,

Just a couple of thoughts as a JNI user:

Using the same flag as FFM makes it look the same, but it would appear
that it's then not possible to disable JNI but enable FFM. I can imagine
that I would want to apply different policies to the old way and new way.
As proposed, if I enable FFM then JNI can run riot without my knowledge.

Does the manifest element only work if present in the jar file directly
called
via java -jar, or would it be taken if declared in a secondary jar file
listed
in the Class-Path for that first jar?

Thanks,


On Mon, Aug 21, 2023 at 1:42 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

> Hi.
>
> 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.
>
> — Ron
>
> [1]: https://openjdk.org/jeps/442
> [2]: https://openjdk.org/jeps/8305968
> [3]: https://openjdk.org/jeps/8307341
>
>

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230822/4bb95872/attachment.htm>