JEP draft: Prepare to Restrict The Use of JNI

[Glavo]

>
> 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.
>

I agree that some control should be given to the user, but definitely not
the way it is now.

When I enable native access for a module, it can actually have native
access in any way it wants.
If it wants to use JNA without the user knowing, it just needs to copy JNA
into its module.
This is an implementation detail of it, and forcing the library to expose
these details does
nothing positive and will only drive more users away from JPMS.

Whether as a library developer or as an application developer (your
so-called "user"),
I hope to make "enable native access" more deeply integrated with the JPMS.

Here's what I want:

1. Allows a module to declare that it wants native access:

```java

module org.glavo.mylib {
    requires native; // Check for permissions when loading

    // or
    requires static native;  // Check for permission when calling a
restricted method

}

2. Allows a module with native access enabled to grant permissions to other
modules:

```java

module org.glavo.myapp {
    requires native;
    requires org.glavo.mylib;

    opens native to org.glavo.mylib;

}


3. If the main module requires native access, it is allowed without the
--enable-native-access.

4. Allows users to declare restricted methods.
    This will prevent code from masking its true intent through low-level
libraries like JNA/JNR.

Glavo

On Tue, Aug 29, 2023 at 12:39 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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/3d5eca70/attachment.htm>