JEP draft: Prepare to Restrict The Use of JNI

[Alex Buckley]

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
>