JEP draft: Prepare to Restrict The Use of JNI

[Volker Simonis]

Hi,

Could the warning be changed to include a stack trace (at least
optional)? I think that can be helpful for bigger applications in
order to identify the reason for why a JNI library was loaded.

Thank you and best regards,
Volker

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
>