Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Rony G. Flatscher]

On 30.08.2023 10:36, Andrew Dinn wrote:
> On 29/08/2023 18:24, Peter Tribble wrote:
>> And that's what I see as the problem here. There are no possible actions
>> that will improve the ecosystem or the software. There is no better path
>> that developers/users get guided towards. The only possible course of
>> action is to --enable-native-access and carry on.
> Actually, no. The other possible course of action is not to use the application. You actually said 
> the same in the paragraph preceding the one I quoted.
>
> That *is* a real choice. Users who are especially conscious of, say, security concerns, or data 
> integrity concerns, might very well regards the need to pass --enable-native-access as a red flag 
> and not run any such application.

Such users then would stop using operating systems because they are "especially conscious of, say, 
security concerns, or data integrity concerns"? (As if they were able to assess all potential risks?)

And if so, being "a real choice" this means that the Java ecosystem loses a "user" when picking 
therefore the choice to leave Java seeking alternatives. Is that really a goal here?

... cut ...

The road to hell is paved with good intentions ...

A few minor thoughts:

  * Java needs JNI itself: so how can the "user" be warned from using Java as this is considered to
    be potentially dangerous by the Java developers themselves?
    (And what can be done to warn a "user" from using operating system features? Should Java warn
    the "user" that potentially dangerous native code gets employed by Java whenever the operating
    system gets accessed for one reason or another?)

  * Possible dangerous or fatal errors in native code do not mean that these errors exist in reality
    at all, i.e. in deployed JNI modules that get tested and deployed.
    This is a bit along the line that a knife can be dangerous as it can be used to kill a person,
    yet, knives in the world do not get used to kill people: the good intent is to make the world
    safer, so we prohibit knives or only allow their use, if the user keys in the flag
    "--knives-can-kill-persons" and then the storage box opens to release the knife such that one
    can finally cut the steak.
    (Just because something can be used dangerously does not mean that it will be used that way and
    do harm; any acknowledgement of potential danger does not make the danger go away nor does the
    warning help to circumvent the potential danger.)

  * Just pointing out that erroneously implemented JNI modules can be harmful is enough and has been
    evident since JNI exists, so what has changed all of a sudden?

  * Deployment of Java: there seems to be the wrong assumption among some developers that Java is
    not being used as a JRE (non-JRE bubble?) which is simply wrong. What should applications do in
    a scenario in which the JVM gets dynamically loaded via JNI to then interact with the JRE? Is
    that considered to be dangerous such that it needs to be made seen by the "user" each time this
    demand loading of the JVM happens as otherwise the "user" does not realize that theoretically a
    potential danger exists (and if so for whom)?

  * Who is really the "user" who gets addressed here? (How stupid is this particular "user" regarded
    to be?)

  * Why is it not enough to simply record the fact that JNI gets employed explicitly in module-info?
    As has been mentioned a few times this would allow for appropriate analysis, if need be? (It
    also might suffice the intentions of the JEP in that the warnings get issued only if the fact
    that JNI gets employed in a module is not reported in its module-info.)

---rony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230830/79da5be8/attachment.htm>