JEP draft: Prepare to Restrict The Use of JNI

[Constantin Christoph]

I am very aware of what is being changed here; I know that JNI will still
be around, and be usable. However, the restrictions that are going to be
imposed on using it won't exactly make it easier to use, and require even
more boilerplate setup for an end user to set up an app or library. I know
that launchers exist, and I know that the manifest can also permit the
usage of JNI, but if it would solve the issue, I wouldn't be here talking
about it. The issue at hand is that the usage of JNI in the future will
require the end user of a library to either make a startup script (which is
not always the default procedure for smaller applications), or to add
another entry to their manifest, both options often require a bit of
rethinking about how they should build their project. It's not an easy
solution, and it certainly makes things more annoying if a library just
wants to use some more advanced features.

Am Mo., 28. Aug. 2023 um 18:39 Uhr schrieb Brian Goetz <
brian.goetz at oracle.com>:

> I think you have a serious misunderstanding of what is being proposed
> here.  Nobody is taking away JNI.  What is being taken away is the
> ability to bury the use of JNI in a library where the user is unaware of
> it.  By "user" here, I mean the person putting together a Java
> application from a group of modules and JARs -- sometimes called the
> "application assembler."  This user has a right to know what their
> application is doing.
>
> When we started to enforce the accessibility model in Java 9, we didn't
> take away the ability to do deep reflection, we took away the ability to
> do so _without the user knowing_.  The reason that the various
> `--add-opens` are specified on the command line is so that the user has
> a chance to consent to relaxed integrity.  JNI is the same; we're not
> taking it away, but we're helping the user be aware of when a library is
> putting the integrity of the application at risk, so that they have the
> ability to make a judgement call on whether they are willing to trust
> that library.
>
>
> On 8/28/2023 11:37 AM, Constantin Christoph wrote:
> >
> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230828/6e2c48f1/attachment-0001.htm>