JEP draft: Prepare to Restrict The Use of JNI

[Constantin Christoph]

I don't think this change should be made.

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.

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.

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.

Constantin

Am So., 27. Aug. 2023 um 13:41 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:

> ----- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230828/a1643ba4/attachment.htm>