JEP draft: Prepare to Restrict The Use of JNI

[Volker Simonis]

On Tue, Aug 22, 2023 at 8:18 AM Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> Hi Volker,
> note that the warning is generated once per module.
>
> I think what you want is some kind of "log" mode which, while slower, might be more helpful to identify all the places which are performing JNI calls.
>

Yes, exactly.

> That said, even the "log" mode might not detect everything (as it basically depends on the control flow in your application). So, a classfile analyzer might be more complete.
>
> If we want to enable different policies for --enable-native-access (similarly to what's done for -illegal-access=permit|deny|warn|debug), we need to split the current --enable-native-access flag in two:
>
> * a flag to select the list of modules that are allowed to perform native access
> * a flag to select what should happen when a native access from a non-allowed module is detected
>

Yes, I think handling it in a way similar to
--illegal-access/--add-opens makes a lot of sense, both from a
functionality point of view but also because users are already used to
it.

> Cheers
> Maurizio
>
> On 22/08/2023 14:39, Volker Simonis wrote:
>
> 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
>