<div dir="ltr"><div>I don't think this change should be made.</div><div><br></div><div>JNI is a fundamental part of the java ecosystem, and it shouldn't be restricted in a manner like this. It's a powerful, useful tool, and should be treated like that. Developers should have that option freely available.</div><div><br></div><div>But even just beyond this proposal, you've demonstrated in the past, that you like to restrict useful tools to "protect the integrity of the Java platform". This has gone on to such an extent that I doubt the legitimacy of your proclaimed reason for those changes. Take JEP 451 as an example, the proposal for that JEP didn't have much in common with protecting the integrity of the Java platform either.</div><div><br></div><div>While I do understand *some* of the motivation behind these proposed changes, I don't think they should be implemented. The negatives this will bring to the java platform far outweigh the positives, and there are still a million other ways to do more harm to the integrity than using JNI.</div><div><br></div><div>Constantin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am So., 27. Aug. 2023 um 13:41 Uhr schrieb Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">----- Original Message -----<br>
> From: "Alex Buckley" <<a href="mailto:alex.buckley@oracle.com" target="_blank">alex.buckley@oracle.com</a>><br>
> To: "jdk-dev" <<a href="mailto:jdk-dev@openjdk.org" target="_blank">jdk-dev@openjdk.org</a>><br>
> Sent: Thursday, August 24, 2023 5:04:55 PM<br>
> Subject: Re: JEP draft: Prepare to Restrict The Use of JNI<br>
<br>
> The entire point is to make the end user aware of the need for native<br>
> access by something (probably six dependency levels deep) in their<br>
> application.<br>
> <br>
> The majority of applications do not need native access, but where native<br>
> access is needed, it is fundamentally uncheckable and unsafe (as<br>
> described in the JEP), hence the desire to have the user acknowledge it.<br>
> Yes, we are asking the user to acknowledge an implementation detail of a<br>
> library they've never heard of. This keeps the community's attention<br>
> focused on the small number of libraries which, unlike those which use<br>
> only standard supported Java APIs, are likely to be the cause of<br>
> breakage on newer JDK releases.<br>
<br>
I disagree.<br>
I do not like the fact that you are promoting the idea that the JDK code is not superior to other libraries of the ecosystem.<br>
Also the Java ecosystem is massive so even if it is true that the majority of applications do not do native call apart the JNI calls of the JDK, there are a lot of middleware libraries that do native access, so there are a lot of applications built on top of those middlewares that do native access. Those applications are not unsafe.  <br>
<br>
Let's take an example, Netty [1], the server and all it's protocol/transport supports are using JNI.<br>
Netty acts as a middleware, encapsulating unsafe JNI calls in a safe way. For example, you can use OpenSSL for HTTPv2, something the JDK does not do.<br>
<br>
Why Java SE should consider the JDK code is more safe than the Netty code, given that both are using JNI ?<br>
<br>
Why the user of one Netty libraries or one of the libraries that is using Netty libraries (for example, a JDBC driver [2]) need to be aware that Netty is using JNI ?<br>
<br>
If you think that Java has an integrity problem, I would prefer a solution including the Java ecosystem than a strawman solution where the JDK is good and everything else is bad. And don't get me wrong, I have no problem with having more protection to the JDK code (note JDK) but, this is not what we are discussing here.<br>
<br>
> <br>
> Alex<br>
<br>
Rémi<br>
<br>
[1] <a href="https://github.com/netty" rel="noreferrer" target="_blank">https://github.com/netty</a><br>
[2] <a href="https://github.com/postgresql-async/postgresql-async" rel="noreferrer" target="_blank">https://github.com/postgresql-async/postgresql-async</a><br>
<br>
<br>
> <br>
> On 8/24/2023 7:50 AM, Glavo wrote:<br>
>> We need a way for modules that are enabled native access to pass this<br>
>> permission,<br>
>> otherwise this will force the library to have to expose the<br>
>> implementation details to the user.<br>
>> <br>
>> Just for now, I think the --enable-native-access option is really weird.<br>
>> It works with JPMS, but we can't describe it through module info.<br>
>> I wish I could describe these things in module info instead of command<br>
>> line arguments,<br>
>> --enable-native-access should just be an escape hatch like<br>
>> --add-exports/--add-opens.<br>
>> <br>
>> Glavo<br>
>> <br>
>> <br>
>> <br>
>> On Thu, Aug 24, 2023 at 10:03 PM Maurizio Cimadamore<br>
>> <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a> <mailto:<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>>><br>
>> wrote:<br>
>> <br>
>> <br>
>>     On 24/08/2023 14:47, Volker Simonis wrote:<br>
>>      > I think the changes we are talking about here are much to fundamental<br>
>>      > for the Java platform to hide them in the API documentation of a<br>
>>      > package.<br>
>> <br>
>>     I think I've already explained how the plan is to move restricted<br>
>>     methods out of the FFM package javadoc.<br>
>> <br>
>>     As to the modifier idea - I think whatever arguments you make for<br>
>>     restricted methods also holds for preview API methods. We have been<br>
>>     previewing APIs for a number of years, and we have developed several<br>
>>     concepts that we can reuse here. In what way are restricted methods<br>
>>     more<br>
>>     attention-deserving than preview API methods?<br>
>> <br>
>>     (And, no, I don't think we should add _two_ modifiers :-) )<br>
>> <br>
>>     Maurizio<br>
</blockquote></div>