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

[Maurizio Cimadamore]

On 22/09/2021 04:19, Samuel Audet wrote:
> 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!

The reasons why this is not considered are similar to why we don't just 
have a single kill switch to enable _all_ native restricted methods in 
_any_ modules. We could do something like --enable-preview, a single 
flag which enable native access for everything. This would also make 
Glavo use case work (well, plus some trick to ignore unrecognized 
options for older versions, but we have 
-XX:+IgnoreUnrecognizedVMOptions). The problem with this (and other 
blanket approaches) is that the application packager has no way to be 
notified when _something_ changes in the dependencies of his/her 
application.

I think smartphones provide a good analogy: you grant permission on an 
application basis; e.g. when you install app X, you are asked whether 
you are ok with X accessing your storage and camera. What you are 
proposing is that, instead, we have a global setting in our devices 
which say "please give every app all the access they want and never 
bother me with this again". Such a model, while certainly minimizing 
friction, is surely bound to create issues in the long run.

I think there were many interesting point in Glavo's email - e.g. naming 
of the option could be misleading and over promising, the fact that if 
access is granted to module A and A depends on B, we also have to grant 
access to B as well, etc.

But having a global "sudo please let me do what I want" switch was never 
suggested, and is not a direction we'd like to take, sorry.

Maurizio


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