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

[Samuel Audet]

I don't feel this is something that should be set on a per-application 
basis. I really do mean something like an "environment", like an 
environment variable. Sure, we can ask users to set JAVA_TOOL_OPTIONS 
and what not, but that is not user friendly. It's not for end users. 
Those users should be able to tell the application whether it's OK to 
run that code or not. For example, in the case of Android, etc, we can 
assume the default to be "yes", but for some desktop application, the 
end users could be instructed to go set a checkbox somewhere in the 
settings of the JDK.

This, incidentally, would satisfy the needs of applications such as the 
one Glavo describes, no?

In any case, please explain why this kind of approach is not being 
considered!

Samuel

On 9/21/21 8:59 PM, 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> 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
>>
>