JEP draft: Prepare to Restrict The Use of JNI

[-]

I think the point here is that native access IS still available, via FFI.
It's just that you have to define safe native APIs for jextract/FFI, and
your native code won't be provided JVM objects that can meddle with the JVM
itself like in JNI, right?

Chen Liang

On Mon, Aug 28, 2023, 11:37 PM Constantin Christoph <4evnyuij at gmail.com>
wrote:

> 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/20230829/857b7478/attachment-0001.htm>