JEP draft: Prepare to Restrict The Use of JNI

[Remi Forax]

----- Original Message -----
> From: "Alex Buckley" <alex.buckley at oracle.com>
> To: "jdk-dev" <jdk-dev at openjdk.org>
> Sent: Thursday, August 24, 2023 5:04:55 PM
> Subject: Re: JEP draft: Prepare to Restrict The Use of JNI

> The entire point is to make the end user aware of the need for native
> access by something (probably six dependency levels deep) in their
> application.
> 
> The majority of applications do not need native access, but where native
> access is needed, it is fundamentally uncheckable and unsafe (as
> described in the JEP), hence the desire to have the user acknowledge it.
> Yes, we are asking the user to acknowledge an implementation detail of a
> library they've never heard of. This keeps the community's attention
> focused on the small number of libraries which, unlike those which use
> only standard supported Java APIs, are likely to be the cause of
> breakage on newer JDK releases.

I disagree.
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.
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.  

Let's take an example, Netty [1], the server and all it's protocol/transport supports are using JNI.
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.

Why Java SE should consider the JDK code is more safe than the Netty code, given that both are using JNI ?

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 ?

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.

> 
> Alex

Rémi

[1] https://github.com/netty
[2] https://github.com/postgresql-async/postgresql-async


> 
> On 8/24/2023 7:50 AM, Glavo wrote:
>> We need a way for modules that are enabled native access to pass this
>> permission,
>> otherwise this will force the library to have to expose the
>> implementation details to the user.
>> 
>> Just for now, I think the --enable-native-access option is really weird.
>> It works with JPMS, but we can't describe it through module info.
>> I wish I could describe these things in module info instead of command
>> line arguments,
>> --enable-native-access should just be an escape hatch like
>> --add-exports/--add-opens.
>> 
>> Glavo
>> 
>> 
>> 
>> On Thu, Aug 24, 2023 at 10:03 PM Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com <mailto:maurizio.cimadamore at oracle.com>>
>> wrote:
>> 
>> 
>>     On 24/08/2023 14:47, Volker Simonis wrote:
>>      > I think the changes we are talking about here are much to fundamental
>>      > for the Java platform to hide them in the API documentation of a
>>      > package.
>> 
>>     I think I've already explained how the plan is to move restricted
>>     methods out of the FFM package javadoc.
>> 
>>     As to the modifier idea - I think whatever arguments you make for
>>     restricted methods also holds for preview API methods. We have been
>>     previewing APIs for a number of years, and we have developed several
>>     concepts that we can reuse here. In what way are restricted methods
>>     more
>>     attention-deserving than preview API methods?
>> 
>>     (And, no, I don't think we should add _two_ modifiers :-) )
>> 
>>     Maurizio