JEP draft: Prepare to Restrict The Use of JNI

[Attila Kelemen]

Hi,

The problem I'm predicting with this is that this change will disincentive
people from using the module system even more. Because consider that there
are not so involved developers (the vast majority), and they will learn
that their application might crash, if one of their millions of
dependencies attempts to do a native call. People will not want to risk
this, so they will just want to specify that everything can use native for
all they care. And the easiest to do this is if they put everyhing on the
classpath and allow it for the unnamed module.

So, I believe this requirement must make into the module-info in two ways:

`uses native;` (maybe something else to avoid possible conflicts with the
SPI)

The lack of this would cause compilation failures if unsafe native API is
used. Maybe you could add some counterpart to the manifest as well, but I
would not be mad if you would require a proper module-info for applications
requiring native access (but it certainly would be a hassle for some
libraries, if they want to be compatible with versions not supporting this
statement). In this case, the JVM might even refuse to start an application
(but at least issue a warning on startup) that there is the possibility of
a crash, if you didn't allow for native access for this module.

An additional thing that should be allowed in module-info is something like
this:

`allow native io.netty.internal.tcnative;`

The JVM would only care about this statement for the main module, and if it
is present, then you don't need to pass this as a command line argument.
The benefit of this is that then there is one place where you can specify
the native access requirement. Since it is not uncommon that people have
lots of "java" calls scattered around in various shell scripts calling a
lot of things, and if you don't allow a convenient common location, then -
in my experience - people will take the easy way out and will pass the
enable native argument everywhere "just in case".

Attila

Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2023. aug. 21.,
H, 14:42):

> 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/20230828/ab3359df/attachment.htm>