[External] : Re: New candidate JEP: 454: Foreign Function & Memory API

[Rony G. Flatscher]

Hi Ron,

the problem in a nutshell:

  * the warning is addressed to "application users/authors", i.e. users who create an application
    and a runtime to go with that application;
    the intent, if understood correctly, is to make sure that an application user/author does not
    inadvertently use modules that use FFM, hence the idea of that warning that goes away if the
    application user/author supplies an appropriate switch;
    the problem: it is likely that that warning bypasses the application user/authors and instead
    gets presented to the (end) user, the user of the Java application;
    the reason why this is possible lies in the fact that the Java runtime that gets used is not
    necessarily controllable by the application author;
    the (end) user is not to be expected to know necessarily Java or have the expert knowledge
    necessary to assess what the warning is really about, such that the effect will be to frighten
    the (end) user and to create the impression that it has become dangerous to use Java all of a
    sudden;
    it is likely that the (end) users will not have the necessary knowledge or means (if the Java
    programs and Java applications run under a globally installed JRE without any specific
    launchers) to stop these messages

  * authors of plain-vanilla jars cannot inhibit that warning (confined currently to executable jars
    only)

  * authors of modules cannot inhibit that warning

  * and in JRE deployment scenarios not even the authors can inhibit that warning if they do not
    control the configuring of the JVM

Please also realize that using the term "Java/JDK runtime environment (JRE)" is just a generic 
technical term that denotes a deployment in which any Java/JDK got installed globally on a computer 
such that any Java program and any Java application will use in any process the currently installed 
JRE.

"JRE" therefore describes the environment in which the warning may appear once Java/JDK gets updated 
to 22 replacing the old with a new JRE without anyone expecting such a warning who uses a Java 
program and Java application. Worse, the warning has the potential to scare those users, which has 
the potential of destroying the good reputation of Java, as these Java programs and Java 
applications all of a sudden turned dangerous.

There is no good side-effect for "application users/authors" in this scenario ("ha, the (end) users 
will ultimately force those stubborn 'application authors' to supply that harmless switch!") as 
mostly the (end) users cannot do anything about it. But the negative effect that Java warns users 
from using Java has materialized. In social environments like companies, departments one is not able 
to remedy that situation once the trust got broken. Rather it is a good reason to start leaving Java 
and change to other environments.

It is about two totally different domains (this expert group and the users of Java software) where 
the effects will be totally different. The fear (from experience) is that that warning will cause 
significant and hardly reparable damage to Java.

The problem solution is in principle rather easy: do not show that warning to users of Java programs 
and Java applications, show it only to the application authors for whom it got invented for.

---

As there has been quite a lot of communication so far, it should have become clear that there are 
Java savvy people who see a real and serious problem and urge to make sure that that warning is not 
shown to (end) users.

Trying to help understand the deployment scenarios for people who are focused exclusively on 
applications that go only with their own runtime (and for which the warning can easily be fixed by 
the application authors), I will try to come up with a few very short samples with deployment 
scenarios where this is not the case, where the currently installed JRE gets employed.

Maybe you can look at these few scenarios (stripped down) and assess the problem in these scenarios?

---rony




On 15.09.2023 18:51, Ron Pressler wrote:
>
>> On 15 Sep 2023, at 15:46, Rony G. Flatscher<Rony.Flatscher at wu.ac.at>  wrote:
>>
>> Hi Ron,
>> first thank you very much for your interesting answer!
>> There seem to be a few problems that make the communication delude at times therefore trying to pointing them out upfront:
>>      • one is the term JRE which is supposed to identify the use case of a Java/JDK runtime installed in a system that gets used by any Java and non-Java application in each process
> Right. You’re referring to a shared runtime. The client JRE was similar in some ways but different in other important ways (e.g. it supported automatic updates for both the runtime and the applications running on it) and in any event — no longer exists.
>
>> ; what you seem to be focusing on is only the "CRE" (customized - "embedded" - runtime environment) use case where an application developer determines/controls the configuration of the CRE s/he uses for her/his Java application,
>>
>>      • another is the error message and who gets addressed by it introduced with FFM: the target use is the "application user" i.e. the application developer.
> The target is whoever needs to put the application and its runtime together, because that’s the person who needs to be aware the two may not be compatible. Because the recommendation is that the application author picks the runtime, it can certainly be the application author. But if for some reason or another the application author chooses not to pick the runtime and to place that responsibility on the user, then the user must be warned that the runtime they’ve picked is not right for the application.
>
> You, the application author, can choose what your users are exposed to.
>
>> As various posters have pointed out the proposed warning these (end) users get will be frightening (it will appear out of the blue for them once the JRE gets updated to the version that issues that warning) and they will most likely be afraid and not know what to do to remedy this unexpected, all of the sudden "dangerous" situation,
> Indeed, if the application author chooses to place that responsibility on their users, the users will (and should) be “frightened”. The solution we’ve offered since JDK 9 is for the application author not to place that burden on the users.
>
>>      • another is about the control over which runtime environment gets used, the JRE or the CRE, and who loads up the JVM: it seems that the expectation is that the "application author" is in full control over the JVM loading and that the only relevant use case is the CRE one, not the JRE one; as has been pointed out one of the biggest values of Java/JDK is its "compile once, run anywhere" supplying an incredible wealth of functionality in its JRE to whomever is able to exploit it: non-Java programs, non-Java tools got JNI by any of the Java JDKs in the past decades. The JRE deployment scenarios are manyfold, e.g. commands, utilities may be employed in a pipe using whatever runtime environment is present of which they may not know who started it in the first place. As such it is not possible to make sure that the warning does not get shown to the (end) user when there are different JRE's in use (even different JRE versions available on the same machine),
> For better or worse, the JRE was retired some years ago. You can try to mimic much its functionality with a custom non-embedded runtime (which is what you’re using for versions of Java past 8), but the experience is not quite the same as in the days where there was a JRE. The form in which Java offers write-once-run-anywhere changed some years ago, when we retired the JRE. On the negative side you may no longer be able to deploy the same file for all platforms; on the positive side, you don’t need to ask your users to install a Java runtime and deal with incompatibilities (that experience has become even more difficult since the JRE was retired because neither the runtime nor the application are now self-updating).
>
> The fact is that Java’s recommended deployment model changed some years ago. I think that in most ways it’s now much better than it’s ever been, and in some small ways it’s worse. But trying to recreate the old experience with newer JDKs is sure to result in an experience that’s worse than either one offers.
>
>>      • another one is "what is easy for whom" where the knowledge of this group seems to be the reference, but the knowledge of the Java application users/developers out in the field cannot be on par if they did not follow the project's discussions closely; add to that users who have no deep Java (language) knowledge at all and really constitute end users, people who work in departments on a computer and use their acquired programming skills to ease their business processes by taking advantage of them (like the PDFBox example).
> That is where jlink can solve your problem, but not if you choose not to use it.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230918/62449128/attachment-0001.htm>