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

[Maurizio Cimadamore]

On 20/09/2021 18:17, Glavo wrote:
> I thought for a long time and summed up the main reasons for
> my dissatisfaction: It deprives me of my ability to take responsibility.
I think this is getting closer to it (as noted in the response I've just 
sent)
>
> 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.
I believe this is where the friction is
>   * Program developer: They develop programs for execution.
>     The program depends on the library and are distributed to users.
The friction here is just imagined. When you package up an application 
(e.g. think of an IDE) you know what your dependencies are - and which 
command line options to pass. Doing this using e.g. `jpackage` is trivial.
>   * Users: People who use programs may not understand development.
This category is ill specified. Who is an user? An user is either 
(recursively) a library developer (as library A can depend on library 
B). In such case a library doesn't have to concern about giving 
permissions. A user can also be a program developer, e.g. a program 
using library A - in which case the user needs to decide whether to 
grant A access or not.
> Now, this restriction makes developers unable to be responsible for 
> themselves:
No, this restriction makes _library developers_ unable to *cheat* on 
program developers. If a program developer grants native access to only 
3 modules, and another one pops up and starts using native access out of 
nowhere, it is a legitimate question, from the perspective of that 
program developer, as to whether that other module has been updated in a 
way that is consistent with the program/application. Maybe this will 
result in an extra command line option - or maybe this will result in 
the extra dependency being eliminated. It is ultimately a choice up to 
the application developer.
>
> 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.

Isn't this the case even for a library that wants to use functionalities 
that are closed off by the module system? (e.g. access to JDK internals)

Note that I'm not entirely oblivious to the problem that we might need, 
at some point, a better way to "reify" native dependencies between 
modules. E.g. say that module A is a native module, and uses native 
modules B and C. This would open up ability to grant access only to A, 
which will then be propagated to B and C, so you would be back in a 
world where users are shielded from the internals of your module.

These things are in the range of things we'd like to explore at some 
point, which might (or might not!) relieve some of the (real of 
perceived) friction.

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

Yes, see above.

Cheers
Maurizio

>
> (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.)

It's readable enough - don't worry :-)

>
> Glavo <zjx001202 at gmail.com <mailto: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
>     <mailto: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?
>