<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Overall I strongly support
aligning the behavior of Panama and JNI in this way. I have
some presentational comments on the JEP. <br>
<br>
The "money quote" from this JEP is, IMO:<br>
<br>
> According to the policy of integrity by default, all JDK
features that are capable of <br>
> breaking integrity must obtain explicit approval from the
end user or the application <br>
> assembler.<br>
<br>
But this is buried at the very end of the Motivation. In
reading through the Summary, Goals, and Non-Goals, I see a lot
about mechanics (warnings, flags, etc) and a little about
alignment, but nothing about integrity. I realize we have a
whole JEP about that ([2]), but readers of this JEP are likely
to be asking "Why" (some out of mere curiosity, but some with a
sense of offense) as they wade through the "What". <br>
<br>
The Summary can be reworded as "Support the goal of
integrity-by-default by issuing warnings when ...", bringing the
broader policy choice front-and-center. <br>
<br>
Example #3 (bypassing access control) should be framed as a bug
(native code can subvert the normal path of things), but the
current framing could be seen as a feature (native code can do
... interesting thing). <br>
<br>
I would bring the mention of integrity-by-default higher up in
the motivation, prior to the list of examples. <br>
<br>
The connection to FFM is a little fuzzy, and leaves readers
unsure of what parity can be achieved between FFM and JNI.
Instead, we can say that FFM has proactively dealt with these
risks, by labeling FFM behavior that could violate integrity as
restricted methods, and requiring a similar opt-in. We should
make it clear that FFM has set a higher bar for integrity and
what we're doing here is starting down the road towards matching
that; as written, it seems like the two might be taking slightly
different roads.<br>
<br>
<br>
<br>
<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 8/21/2023 8:41 AM, Ron Pressler
wrote:<br>
</div>
<blockquote type="cite" cite="mid:68BB8C8E-9B94-46B5-B93F-06A116CA5A9C@oracle.com">
<pre class="moz-quote-pre" wrap="">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]: <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/442">https://openjdk.org/jeps/442</a>
[2]: <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8305968">https://openjdk.org/jeps/8305968</a>
[3]: <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8307341">https://openjdk.org/jeps/8307341</a>
</pre>
</blockquote>
<br>
</body>
</html>