[External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Spam mail]

Then make a flag to disable those superpowers, if they're not desired or wanted. Or, better yet: make them declarable in a module definition, so libraries using those superpowers can easily be found and searched through, and can still enjoy those superpowers if they need them.

Am Mo., 28. Aug. 2023 um 22:29 Uhr schrieb Alex Buckley <alex.buckley at oracle.com>:
> On 8/28/2023 12:51 PM, Glavo wrote:
> > A deep dive into every library isn't necessary for everyone.
> > If lib1 trusts lib2 it depends on, then most users who trust lib1 don't
> > need to investigate lib2.
> > We shouldn't make the majority of people pay for a very small number of
> > needs.
>
>  From this JEP about restricting the use of JNI, and from the JEP about
> restricting the dynamic attachment of agents, I think a lot of people
> have become aware of the "superpowers" which some libraries have
> silently enjoyed. Superpowers that allow private methods in the JDK to
> be redefined at any time. Superpowers that allow native code to be
> invoked and then call back into Java with zero access control.
>
> I think a lot of people were unpleasantly surprised to discover that the
> implementation of low-level libraries was a huge factor in preventing
> upgrades from JDK 8 to 17 -- and would like to see the balance shift
> away from library developers being able to silently get superpowers, and
> towards users having the final say over those superpowers.
>
> Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230828/0ff9166e/attachment.htm>