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

[Maurizio Cimadamore]

Without diving into the specifics of Android etc. I believe the 
"environment" concept kicks the can down the road. What is an 
environment? It's probably a Java runtime with certain properties set. 
How do you set these properties? This is, fundamentally, the same 
problem we're tackling with --enable-native-access. In a way you can 
think of these options as a way to define an execution "environment" 
that is tailored for your application's needs (e.g. a client can even 
define its own JDK image using jlink, and inject all required 
--enable-native-access options into the resulting image - which is 
probably the closest concept we have in OpenJDK of your "environment").

So, I think we're tackling the problem at the right level (at least for 
OpenJDK) - but there are questions Glavo raises on whether the 
simplistic mechanism we provide now is enough for real world use; more 
specifically:

* lack of a way to mark native modules in the source code
* lack of a way to propagate native access between dependent modules
* lack of a way to dynamically grant native access to module in a layer

All these things contribute, I think, to make the command-line somewhat 
unstable - e.g. whenever the internals of some module change (e.g. 
module B depends on module C which starts to use Panama), the 
application command line will have to change to reflect that. There is a 
precedent for this, which is "--add-opens" - the question is as to 
whether that precedent is a good one for Panama or not.

Maurizio


On 21/09/2021 12:59, Samuel Audet wrote:
> FWIW, I think the core issue comes from the fact that the Java 
> platform is unable to take responsibility for any of the native code, 
> so what about a way to define some sort of "environment", for the lack 
> of a better word. For example, when the code gets loaded on Android, 
> iOS, or WebAssembly, we already know that the native code is going to 
> run in a sandbox, so we shouldn't have to specify any flags because 
> executing any native code is already considered as "safe" by the 
> native platform. Maybe not as "safe" as Java code, but that's not the 
> point, the point is that maybe the decision should be deferred to the 
> underlying platform? Thoughts?
>
> Samuel
>
> On Tue, Sep 21, 2021, 19:20 Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     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
>
>