JEP draft: Prepare to Restrict The Use of JNI

[Glavo]

Why? Is it important for users to include actual native access in
`org.glavo.mylib` or `org.glavo.mylib.linux`?
In order to facilitate debugging? But wouldn't it be better to describe
these details in module info?

As the application developer, I'm the programmer at the end, please allow
me
to enable native access for other modules via module info. End users are
probably not programmers, so why let them know these details?
I think the developer of the main module has the right to decide.

As the library developer,  please allow me to enable native access for
other
modules via module info. Why do I have to expose my implementation details
to
all users through other channels?
You've forced some implementation details to be public behavior that needs
to ensure compatibility,
but why? Security and transparency are just excuses to lie to yourself.
Under such coercion, I only want to copy all the libraries I rely on into
my own modules,
so that they become implementation details again. Does your coercion make
any sense?
I don't see any point in it, I think its only function is to force
developers away.

I am very opposed to such a design that breaks the package. Therefore, I am
against promoting such a semi-finished product to mature functions.

Glavo

On Thu, Aug 24, 2023 at 11:05 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> 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.
>
> Alex
>
> 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/20230827/dc29984c/attachment-0001.htm>