<div dir="ltr"><div><div>Hi,<br><br></div>Just a couple of thoughts as a JNI user:<br><br>Using the same flag as FFM makes it look the same, but it would appear<br>that it's then not possible to disable JNI but enable FFM. I can imagine<br>that I would want to apply different policies to the old way and new way.<br>As proposed, if I enable FFM then JNI can run riot without my knowledge.<br><br>Does the manifest element only work if present in the jar file directly called<br>via java -jar, or would it be taken if declared in a secondary jar file listed<br>in the Class-Path for that first jar?<br><br></div>Thanks,<br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 21, 2023 at 1:42 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi.<br>
<br>
JNI has been part of the Java Platform since JDK 1.1, but it is inherently<br>
unsafe, so we are proposing to restrict the use of JNI in line with the use of<br>
restricted methods in the Foreign Function & Memory (FFM) API [1].<br>
<br>
The FFM API, expected to become permanent in JDK 22, has methods for interacting<br>
with native code that are inherently unsafe. To protect the integrity of the<br>
Java Platform [2], use of these methods is restricted. This means that calling<br>
them causes warnings, unless the user enables unsafe native access on the<br>
command line. In a future release, calling them will cause exceptions instead<br>
of warnings.<br>
<br>
We propose to align JNI and FFM as follows. Starting in JDK 22, the Java runtime<br>
will give warnings about the use of JNI, unless the user (as for FFM) enables<br>
unsafe native access on the command line. In a future release, using JNI will<br>
cause exceptions instead of warnings.<br>
<br>
In other words, our proposal is: In the future, code that uses JNI will run only<br>
if unsafe native access is enabled, and to prepare for that future, JDK 22<br>
should spotlight the use of JNI with warnings. We've published a draft JEP that<br>
explains why using JNI is unsafe and describes the warnings [3].<br>
<br>
We recognize that many applications use JNI and will be impacted by this<br>
proposal. It is bound to spark discussion that continues even after the<br>
preparatory warnings in JDK 22. Comments are welcome.<br>
<br>
— Ron<br>
<br>
[1]: <a href="https://openjdk.org/jeps/442" rel="noreferrer" target="_blank">https://openjdk.org/jeps/442</a><br>
[2]: <a href="https://openjdk.org/jeps/8305968" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8305968</a><br>
[3]: <a href="https://openjdk.org/jeps/8307341" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8307341</a><br>
<br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div>