JEP draft: Prepare to Restrict The Use of JNI

[Volker Simonis]

On Thu, Aug 24, 2023 at 5:16 AM Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> Hi Volker.
>
> On 24/08/2023 13:05, Volker Simonis wrote:
> > I think it is a little unfortunate that the specification of
> > "Restricted Methods" is buried in the documentation of the
> > java.lang.foreign package [1] which is "only" a preview feature. Apart
> > from there it is mentioned neither in the Java Language Specification
> > nor in the JVM specification (as far as I can see).
> There is no change to the Java language, nor any change to the JVM
> behavior. This is why restricted methods aren't (and shouldn't) covered
> there.

That's kind of questionable. Restricted methods change the semantics
of a method "under the hood". Until now a user can write a native
method and can be sure it is usable if he provides a native
implementation for that method. In the future this will change because
all the methods which make the native implementation available (i.e.
"load it") will be restricted. So what "Restricted Methods" actually
do is the equivalent of introducing a "restricted" method modifier
(like "stricfp") but without explicitly exposing it to the user. That
saves you from changing the JLS/JVMS but I'm not sure it is the right
thing to do.

Maybe it would be wiser to rethink the concept of "Restricted Methods"
and introduce them with a wider scope? Already now there's a slight
mismatch between the concept of a "Restricted Method" (which is very
generally defined as methods which can negatively impact the integrity
of the JVM) and "native access" which is a much narrower concept.
Instead we could introduce a general "restricted" method modifier
which could be applied equally well to native methods but also to
agent loading or sun.misc.Unsafe methods. Even user code might be able
to benefit from such a modifier. This might be just a crazy idea, but
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.

> >
> > If "Restricted Methods" will be used more broadly and enforced by the
> > SE specification it think it makes sense to introduce a new,
> > @Documented annotation (e.g. @Restricted) to make the restricted
> > nature of specific methods more explicit. This would also make it
> > possible for tools like compilers/IDEs to flag this methods at
> > development/build time (similar to @Deprecated). Just mentioning that
> > a method is restricted somewhere down in their API documentation ( see
> > e.g. java.lang.foreign.Linker.nativeLinker()) doesn't seem to reflect
> > the impact of this attribute.
>
> I agree, this is something we have considered. Unfortunately there is
> the usual dilemma here: if the annotation is public, then you can add it
> to your 3rd party methods, which is a moral hazard (after all,
> restricted methods are a JDK concept).
>
> That said, an internal annotation like `@PreviewFeature` could be enough
> to provide javac support along the lines you describe.
>
> As to the fact that restricted methods are for now described in the
> java.lang.foreign package, I agree it's a bit suboptimal (especially
> moving forward) - even though, for now, you only really care about
> restricted methods if you use the FFM API, really.
>
> Once restricted methods start to show up elsewhere, we could perhaps
> pull up the definition of restricted methods in a separate page,
> similarly to what was done for value based:
>
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/doc-files/ValueBased.html
>
> And link to that same page across the JDK API, rather than have the
> section embedded in the java.lang.foreign package description.
>
> Maurizio
>
>
>