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

[Ron Pressler]

> 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