JEP draft: Prepare to Restrict The Use of JNI

[Volker Simonis]

On Mon, Aug 21, 2023 at 5:42 AM 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
>

I have two more questions regarding this proposal:

First, will this be a restriction enforced by the Java SE
specification? I.e. will the specification require that every Java SE
compliant implementation has to restrict JNI by default or will it be
up to the vendors to set `--enable-native-access` more liberal in
their implementation?

Second, the JEP doesn't mention system and JDK classes. I expect that
system classes will be allowed to do JNI by default (e.g. users won't
have to grant them native access just because they want to do file I/O
or use AWT). But what about platform classes or modules bundled with a
JDK distribution which require native access? E.g. vendors bundle a
library like OpenJFX (as Oracle did up to JDK 8) or ship some custom
security providers (like OracleUcrypto) with their JDK, will it be
easily possible and allowed by the Java SE specification, to grant
these libraries native access by default? I think some clarifications
on this topic in the JEP would be helpful.

Thank you and best regards,
Volker