JEP draft: Prepare to Restrict The Use of JNI

[Glavo]

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> 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/20230824/087a3b43/attachment-0001.htm>