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

[Glavo]

I thought for a long time and summed up the main reasons for
my dissatisfaction: It deprives me of my ability to take responsibility.

First, it should not be confused that there are now three levels of
personnel:

  * Library developer: They develop modules that are dependent on
    other libraries or programs, and may also dependent on other modules.
  * Program developer: They develop programs for execution.
    The program depends on the library and are distributed to users.
  * Users: People who use programs may not understand development.

Now, this restriction makes developers unable to be responsible for
themselves:

First, the library developers cannot be responsible for his own library.
Even if they know exactly what they need and completely encapsulate unsafe
operations inside the module, he still needs to inform its users (program
developer or other library developer)
that it is unsafe.

Second, library developers cannot be responsible for their dependent
libraries.
Even if his own library module has --enable-native-access, and he knows
that all his dependent libraries are safely, he still has to inform all
those
who depend on his library of the library he depends on.

Finally, there is no way for program developers to be directly responsible
for their own programs. If he does not use third-party solutions (such as
bash script),
he must notify the user of all modules requiring native access, even if the
user
does not understand what this means.

The first one may be acceptable, and the third one may be solved by
improving JPMS,
but the second issue is very troublesome. If you think these restrictions
are necessary, I think this needs to be solved. For example, add support
for
declarations such as `require native` in module-info.java, to allow the
--enable-native-access of a module to be passed to the module it depends on.

(I don't know if the content of e-mail after machine translation is
difficult
to understand. If it's really difficult to understand, I will ask my friend
to translate again.)

Glavo <zjx001202 at gmail.com> 于2021年9月20日周一 下午9:07写道：

> 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?
>>
>