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

[Maurizio Cimadamore]

Summarizing, you have what we could call an "application".

You have a launcher for it in some platforms, and on other platforms you 
don't.

Of course, where there's a launcher it is trivial (albeit maybe tedious) 
to add the required options depending on the java version.

Without the launcher you are constrained by what can be expressed in the 
manifest of the jarfile - which at the moment is "not a lot" :-)

<digression>
With respect to bundling JRE, I think modularization has helped a lot 
there. You can create an image (using jlink) that only contains the 
modules you want - and then, use jpackage to generate a small executable 
out of that. We tried this approach to create a standalone jextract 
tool, and I have to say it worked really well - the size is very compact 
(as most of the JDK modules are dropped), to the point that the size of 
the standalone app tracks closely that of the native library it depends 
on (libclang). I hope many more projects decide to do things this way, 
because, IMHO, it just a much saner way to package up things and 
dependencies.
</digression>

I really do think that modules are the right boundaries to enforce 
restrictions.

I concede that, given the current situation, if the option was called 
--enable-restricted-access instead of --enable-native-access that might 
be perceived as less of a "lie".

Maurizio



On 21/09/2021 17:09, Glavo wrote:
>
>     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 
> <mailto: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
>
>