Will we need to use the --enable-native-access option to enable JNI in the future?

[Glavo]

Honestly, as the author of the library, I am extremely disappointed
with this answer. I will choose to give up my expectation of Panama
until 2031 (Java 8 and 17 are out of support).

I think that under the current situation, it is extremely stupid to
restrict Panama by default. Its only significance at present is to
recommend users to use JNI/JNA/JNR instead of Panama.

At present, --enable-native-access option has nothing to do with
safety at all: Because of the existence of JNI, a module can do
anything without it. Since it can't provide any safety guarantee
at all, and at the same time it brings some additional usability
issues, it will only limit the promotion of Panama.

The usability issues brought about by this option have been complained
by other people a long time ago, and I have not seen anyone around
me who are satisfied with this option. I don't want to repeat all these
questions here, because I believe you have heard them many times.
And I think some of these issues  can be alleviated by improving other
features of the OpenJDK, e.g. adding an alternative to MANIFEST.MF
for modular programs, allow options such as --add-opens and
--enable-native-access to be written into it.

Now what I want to emphasize here is that as a more restricted alternative
to existing features, there is a lot of resistance to migrating to Panama.
Before restricting JNI, the so-called safety is just a fig leaf,
it’s just self-deception. This meaningless constraint will not restrict
the user's behavior at all, but will only hinder the user from choosing
this road - because there is an unobstructed road nearby.

I would like to give a proposal here, which I think will minimize the
obstacles to the promotion of Panama:

  While providing the --enable-native-access option, it also provides
  a --illegal-native-access=(*silent*|*warn*|*deny*) option.

  At first, the default value is *silent*, and there are no restrictions on
  the use of Panama.

  When you are ready to limit JNI, apply this option to JNI at the same
time,
  and adjust the default value to *warn *to warn the use of JNI and Panama,
  and use --enable-native-access to eliminate the warning for a module.

  After several versions, adjust it to *deny *by default to prevent
unauthorized
  native operations, and completely remove this option in a later version.


I like the work of Panama very much, but I am very disappointed by
the current restrictions. For the last time, I want to emphasize that
restricting Panama alone will only refuse users to use it.
If you insist on this choice, I will tell you:

  Thank you for your contributions to the Java 8 ecosystem.
  And I sincerely thank you, because my library users don't have to
  ask me why they need to upgrade to Java 21.

(This email is written by Google translation. Please forgive me for the
syntax error)

Maurizio Cimadamore <maurizio.cimadamore at oracle.com> 于2021年9月20日周一 下午6:17写道：

> Hi,
> While we do not any plan to require so now, many of the reasons as to
> why the flag is added for the foreign Panama API hold true for JNI code.
> As such, It would be not unreasonable, some day, to use the same
> mechanism to restricted access to both (since, after all, there is no
> way for the static compiler, or the JVM, to prove that a program using
> JNI is sound). If we go down this path, it is very likely that it won't
> be a flag-day, where, say, JDK 30 does not require the flag, but JDK 31
> does. It is more likely that we will go through a number of intermediate
> releases where the lack of a flag will result in a runtime warning (not
> unlike to what has been done with illegal reflective access violation
> for modules).
>
> Maurizio
>
>
> On 19/09/2021 12:11, Glavo wrote:
> > At present, it seems that JNI will not be restricted. Will the state be
> > modified in the future?
>