<div dir="ltr"><div>Hi,</div><div><br></div>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.<div><br></div><div>So, I believe this requirement must make into the module-info in two ways:</div><div><br></div><div>`uses native;` (maybe something else to avoid possible conflicts with the SPI)</div><div><br></div><div>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.</div><div><br></div><div>An additional thing that should be allowed in module-info is something like this:</div><div><br></div><div>`allow native io.netty.internal.tcnative;`</div><div><br></div><div>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".</div><div><br></div><div>Attila</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> ezt írta (időpont: 2023. aug. 21., H, 14:42):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi.<br>
<br>
JNI has been part of the Java Platform since JDK 1.1, but it is inherently<br>
unsafe, so we are proposing to restrict the use of JNI in line with the use of<br>
restricted methods in the Foreign Function & Memory (FFM) API [1].<br>
<br>
The FFM API, expected to become permanent in JDK 22, has methods for interacting<br>
with native code that are inherently unsafe. To protect the integrity of the<br>
Java Platform [2], use of these methods is restricted. This means that calling<br>
them causes warnings, unless the user enables unsafe native access on the<br>
command line. In a future release, calling them will cause exceptions instead<br>
of warnings.<br>
<br>
We propose to align JNI and FFM as follows. Starting in JDK 22, the Java runtime<br>
will give warnings about the use of JNI, unless the user (as for FFM) enables<br>
unsafe native access on the command line. In a future release, using JNI will<br>
cause exceptions instead of warnings.<br>
<br>
In other words, our proposal is: In the future, code that uses JNI will run only<br>
if unsafe native access is enabled, and to prepare for that future, JDK 22<br>
should spotlight the use of JNI with warnings. We've published a draft JEP that<br>
explains why using JNI is unsafe and describes the warnings [3].<br>
<br>
We recognize that many applications use JNI and will be impacted by this<br>
proposal. It is bound to spark discussion that continues even after the<br>
preparatory warnings in JDK 22. Comments are welcome.<br>
<br>
— Ron<br>
<br>
[1]: <a href="https://openjdk.org/jeps/442" rel="noreferrer" target="_blank">https://openjdk.org/jeps/442</a><br>
[2]: <a href="https://openjdk.org/jeps/8305968" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8305968</a><br>
[3]: <a href="https://openjdk.org/jeps/8307341" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8307341</a><br>
<br>
</blockquote></div>