[External] : Re: JEP draft: Prepare to Restrict The Use of JNI
Holo The Sage Wolf
holo3146 at gmail.com
Tue Aug 29 10:53:30 UTC 2023
> Users have always had the right to know what they're doing if they want
to.
How, today, can a user know if they use JNI?
The point is to make it impossible for a user to be unaware of any JNI uses
which *at the very minimum* requires you to declare it in the command line.
Although *I absolutely* agree that it should also be added to the
module-info, so instead of having to specify every module that uses JNI in
the flag, you could only specify the Main module, and in there it's
module-info will open the JNI usage for every module.
But i don't think there is a way to make sure the users are aware of JNI
usage without at least 1 flag
On Tue, Aug 29, 2023, 00:34 Glavo <zjx001202 at gmail.com> wrote:
> But as Brian said, "This user has a right to know what their application
>> is doing."
>>
>
> Users have always had the right to know what they're doing if they want to.
>
> You don't give users any new powers, you just impose obligations on
> everyone, so that users have to know more details,
> and library maintainers have to make more implementation details a public
> behavior that must maintain compatibility.
>
> Glavo
>
> On Tue, Aug 29, 2023 at 5:17 AM Alex Buckley <alex.buckley at oracle.com>
> wrote:
>
>> On 8/28/2023 12:31 PM, Glavo wrote:
>> > All the ideas about enabling native access *from inside the
>> program* --
>> > typically in a module declaration -- are missing the point. The
>> point is
>> > to acknowledge risk *from outside the program*. Why? Because if a
>> module
>> > could silently enable native access, then it will (just as it would
>> if
>> > it could silently perform an --add-opens), and users will be
>> unaware of
>> > the risks posed to the application they are using.
>> >
>> > I totally disagree.
>> >
>> > --enable-native-access and --add-opens are doing the opposite:
>> > --add-opens protects implementation details, but --enable-native-access
>> > exposes implementation details.
>> >
>> > Since we have opens, --add-opens is just an escape hatch;
>> > but --enable-native-access is the only way to enable native access.
>>
>> Correct. The common thread -- hence a command line option in both cases
>> -- is when a library's behavior presents a risk to the user: using JDK
>> internals that can change from release to release without any warning,
>> and invoking native code that can undermine the JVM. There is no risk
>> from libraries that use only public java.* APIs (including the
>> java.lang.foreign classes for off-heap memory management) and do not
>> invoke native code.
>>
>> > I agree that we should make application assemblers aware of some things,
>> > but I absolutely disagree that this should break encapsulation.
>>
>> By "break encapsulation", I think you mean "expose users to the
>> implementation detail that a library, which is used by a dependency of a
>> dependency of a dependency of the application, invokes native code."
>>
>> But as Brian said, "This user has a right to know what their application
>> is doing."
>>
>> Alex
>>
>> > Also, I'm very much against some things that can only be achieved by
>> > adding JVM options.
>> > We have Add-Opens and Enable-Native-Access in the MANIFEST.MF,
>> > so why are we not allowed to declare them in the main module?
>> > From what I've seen, some developers have given up on using JPMS in
>> > their programs because of this.
>> > I can't understand any benefit of it.
>> >
>> > Glavo
>> >
>> > On Tue, Aug 29, 2023 at 3:02 AM Alex Buckley <alex.buckley at oracle.com
>> > <mailto:alex.buckley at oracle.com>> wrote:
>> >
>> > Usage of JNI *or the foreign-function parts of the FFM API* will
>> > require
>> > the end user of a library to acknowledge that native code is going
>> > to be
>> > invoked.
>> >
>> > (The *foreign-memory parts of the FFM API* are not involved in this
>> > discussion, and their ability to manage off-heap memory will
>> supersede
>> > many traditional uses of JNI and --enable-native-access.)
>> >
>> > Who is the end user of a library? It's an *application* which, in
>> the
>> > vast majority of cases, already has a startup script. What does the
>> > startup script do today?
>> >
>> > - Choose a GC and (sometimes) set GC tuning parameters
>> > - Set system properties to configure security protocols
>> > - Use --add-opens/exports to acknowledge that third, fourth, fifth
>> > party dependencies may try to use setAccessible to access
>> > non-standard JDK internals which can change at any time --
>> > that is, acknowledge risk from libraries which can prevent the
>> > application being run on newer JDKs.
>> >
>> > To this list, we're proposing to add:
>> >
>> > - Use --enable-native-access to acknowledge that third, fourth,
>> > fifth party dependencies may use JNI or parts of the FFM
>> > API which, despite being standard features of the Java Platform,
>> > are inherently dangerous -- that is, acknowledge risk from
>> libraries
>> > which can prevent the application running correctly.
>> >
>> > The risk from libraries using setAccessible on JDK internals is bad:
>> > exceptions are thrown when the internals change, and applications
>> which
>> > ran on JDK 8 don't run on JDK 17. But the risk from libraries
>> invoking
>> > native code are potentially catastrophic: undefined behavior, silent
>> > data corruption, JVM crashes. That's why we propose that the end
>> user
>> > (application assembler) must be aware of the risks.
>> >
>> > All the ideas about enabling native access *from inside the
>> program* --
>> > typically in a module declaration -- are missing the point. The
>> > point is
>> > to acknowledge risk *from outside the program*. Why? Because if a
>> > module
>> > could silently enable native access, then it will (just as it would
>> if
>> > it could silently perform an --add-opens), and users will be
>> unaware of
>> > the risks posed to the application they are using.
>> >
>> > Alex
>> >
>> > On 8/28/2023 10:01 AM, Constantin Christoph wrote:
>> > > 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 <mailto:brian.goetz at oracle.com>
>> > <mailto:brian.goetz at oracle.com <mailto: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/20230829/1df55c66/attachment-0001.htm>
More information about the jdk-dev
mailing list