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

[Glavo]

>
> I think this is the real important point here. I'd like to understand
> more about this use case. Do you have an executable AND multi-release
> JAR? Is it an application that you are developing? Do you want that
> application to be just executed using `java -jar foo.jar`? Does your
> application have a launcher to trigger the `java -jar` command?
>

Yes, even more than one of my programs are looking forward to introducing
Panama to improve some corner features, even if they don't use native
methods at present: Although using native access can improve the user
experience, it is not necessary. If JNI is introduced, the build and
testing process will be extremely complex, and it is difficult to support
some niche platforms (e.g. Linux MIPS64el). JNA or JNR will significantly
expand the size of small programs. I expect to use Panama as an alternative
to JNA to implement some optional functions, enable it on Java 21, and
gracefully fallback in earlier versions.


Using a more specific example, there is a JavaFX GUI application that
I am involved in developing. It's a popular program. We have more than
*one hundred thousand users*. This is a program for ordinary users. Most
of them are not developers.

It is always distributed as a fatJar (~3.6MB) and is expected to be
out of the box except (Only need Java environment). In order to make it
out of the box, it will automatically download OpenJFX at runtime and
put it into module path by dirty way (Use BuiltinClassLoader::loadModule).

It has a launcher, but not always available. We splice an exe in front
of the contents of the jar file (It is still a JAR, which is allowed
by the ZIP format). The launcher will look for java.exe in several
places and start the program with CreateProcess. However, our program
is cross platform, and there are many users who do not use Windows,
and our launcher is only effective on the Windows platform.
On other platforms, we simply distribute the fatJar. Fortunately, it
works well because the double-click action of jar on the Mac OS is
open it with java -jar. For Linux users, the most common usage is to
start it with java -jar. Moreover, many of our windows users will use
jar instead of exe version, because the double-click action of jar will
also be associated when installing JRE, so they often do not need to
rely on launcher.

We have no plans to provide launchers on platforms other than windows,
We won't give up Java 8 for a long time (maybe before 2031, but maybe
later). Bundling JRE and distributing it is absolutely unacceptable.
It will expand our application distribution by more than seven times,
and expand the volume after decompression by more than 20 times!
It is acceptable for us to recommend users to install Java by themselves,
because the program is related to minecraft, and users always need a
JRE. We want to keep the form of distributing a single jar. Being clean
and portable software is one of its selling points.

For the record, I don't despise all code at all -
> but I also think that the position of "must be run with a clean `java
> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
> Most of the real world Java application I've seen all need to drop in
> some extra command line option (e.g. -Xmx), but I think your problem
> here is more specific than "just add a command line option" - the
> problem is adding an option that is only supported on _some_ JDKs (see
> below).
>

I don't think this is unrealistic. Java's default options are good
enough for most small programs, and I have noticed that Java has been
improving out of box availability. I believe that Java's default options
will be good enough for most client applications in the future.

Please walk me through your use case a bit, and please let's keep the
> conversation focussed - arguing over general safety principles is not
> very helpful, when the real problem is, I suspect, driven by something
> much more concrete.
>

I know you have your point of view, and I don't want to keep pestering
on it. But I want to remind you one last time: This option is currently
very confusing to users, at least the name is problematic. At present,
it cannot restrict native access, but it implies that it has this
ability. This is a security risk. I insist that for the time being,
Panama should not force the check of native access execution by default.
It needs to prepare the security mechanism and remind the user to use
it, but it should not start to execute by default until it is ready
to restrict JNI (and deprecated sun.misc.Unsafe).

Of course, real-world safety problems often come from dynamically
loaded code, but it also reduces the value of this option. I hope that
Panama will pay more attention to dynamic safety management rather
than static safety.


Here I would like to add another question:
Is it too coarse-grained to always manage native access permissions
based on modules? This seems appropriate for a binding library or a
library that often uses foreign memory. However, for some modules with
only a few methods that require native access, can't I grant temporary
permissions? Just like:

  doWithNativeAccess(() -> {
      someUnsafeMethod(); // ok
  });
  someUnsafeMethod(); // IllegalCallerException

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

> I'll zoom in on this issue, because I think it's the one we need to
> understand the most. For the record, I don't despise all code at all -
> but I also think that the position of "must be run with a clean `java
> -jar`, no extra arguments" is (while a good goal) a bit unrealistic.
> Most of the real world Java application I've seen all need to drop in
> some extra command line option (e.g. -Xmx), but I think your problem
> here is more specific than "just add a command line option" - the
> problem is adding an option that is only supported on _some_ JDKs (see
> below).
>
> On 21/09/2021 03:51, Glavo wrote:
> > In my original plan, I would convert it into a multi-release jar.
> > On the Java platform available to Panama, I will use Panama to call
> > the system API. This will allow me to adapt to more platforms (e.g.
> > mips64el).
> > Panama's restrictions made me abandon this scheme. Because
> > I can't execute it on any version of Java platform with a
> unified command.
>
> I think this is the real important point here. I'd like to understand
> more about this use case. Do you have an executable AND multi-release
> JAR? Is it an application that you are developing? Do you want that
> application to be just executed using `java -jar foo.jar`? Does your
> application have a launcher to trigger the `java -jar` command?
>
> Please walk me through your use case a bit, and please let's keep the
> conversation focussed - arguing over general safety principles is not
> very helpful, when the real problem is, I suspect, driven by something
> much more concrete.
>
> Thanks
> Maurizio
>
>
>