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

[Samuel Audet]

What I have in mind is not a blanket approach like "sudo" for 
everything, it is more in fact like granting permissions to applications 
on mobile platforms. If it turns out that we don't want to grant native 
access to applications by default, then we could have it that whenever 
users install such an app, they would get prompted to grant that 
permission, or not.

In fact, this is exactly how "sudo" on Windows works: You get asked with 
a nice user-friendly prompt if you're sure that you want to grant 
administrator permissions to that application you're trying to run. It 
doesn't ask you to go figure how to launch it from the command line!

Actually, Android, iOS, Mac, Windows, even GNOME on Linux does it like 
that these days, and it's been working fine for over a decade now on 
every single platform that I am aware of. Please explain why this would 
be the wrong way to go for Java. I can hope that you're working on 
something revolutionary, but I'm quite disillusioned by OpenJDK in 
general these days, so I don't think that's what is happening here, but 
I'll give you the benefit of the doubt.

I think your main point is that the "application packager has no way to 
be notified when _something_ changes in the dependencies of his/her 
application", which sounds reasonable, but I don't see when that would 
be a problem. Could you elaborate on this scenario? In my book, 
"application packagers" are also programmers, so they already do things 
like test applications in multiple environments anyway (with and without 
sudo-like permissions), so I think that any changes in the dependencies 
would easily show up at that stage. Do you have a counterexample in mind?

Samuel

On 9/22/21 6:18 PM, Maurizio Cimadamore wrote:
> 
> 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
>>>>
>>>
>>