JEP draft: Prepare to Restrict The Use of JNI
Brian Goetz
brian.goetz at oracle.com
Mon Aug 21 16:32:49 UTC 2023
Overall I strongly support aligning the behavior of Panama and JNI in
this way. I have some presentational comments on the JEP.
The "money quote" from this JEP is, IMO:
> According to the policy of integrity by default, all JDK features
that are capable of
> breaking integrity must obtain explicit approval from the end user or
the application
> assembler.
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".
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.
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).
I would bring the mention of integrity-by-default higher up in the
motivation, prior to the list of examples.
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.
On 8/21/2023 8:41 AM, Ron Pressler 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230821/04ed1583/attachment-0001.htm>
More information about the jdk-dev
mailing list