New candidate JEP: 454: Foreign Function & Memory API

[Rony G. Flatscher]

Hi Pedro,

On 15.09.2023 18:18, Pedro Lamarão wrote:
> Em sex., 15 de set. de 2023 às 12:34, Rony G. Flatscher <Rony.Flatscher at wu.ac.at> escreveu:
>
>>     This person must add whatever initialization flags are appropriate and/or required whenever
>>     they become appropriate and/or required.
>>     Suppose this person assembles an application including component XPTO, and this person
>>     desires to upgrade XPTO to new version 123 that adds a new feature that uses the new FFI:
>>     during this upgrade, this person also adds --enable-native-access to the initialization
>>     flags, and all is good. If this person is not aware of this need, it will become aware
>>     during testing, because the JVM will alert of this necessity.
>
>     This is about deployment scenarios where no new applications get created from scratch, but
>     there are Java applications and little Java utilitiy programs, but also native applications
>     and little native utilities that have been deployed with a JRE available, possibly for many
>     years. Take also into account that older versions may be deployed on newer JREs and the like.
>     This warning aimed at application authors should never be placed in front of (end) users.
>
>
> This hypothetical situation where warnings are shown to end users can only happen when the 
> application is upgraded to (1) use a new JVM, and (2) use (a new version of a component that uses) 
> the new restricted methods of the new FFI.

Unfortunately also those who have been using JNI for decades without any problems whatsoever.


> I have been reading the discussion on the new warnings and so far have not visualized a concrete 
> situation where these two upgrades would happen in such a way that it is severely inconvenient to 
> modify the application launcher to add new flags.

The problem are (end) users who do not have the expertise of this group and who have never had a 
need to configure the JVM as a normal "java someJavaClass" would have been sufficient to run a Java 
program.

Such users would get out of the blue (!) a serious warning that is actually only aimed at 
"application authors" who create full blown Java applications. Users who would not be aware of the 
rationale and the intention and users who are not able to fix that alarming situation on their own.


> I can only assume that the deployment scenarios being considered are all about dropping modified 
> JARs into preexisting CLASSPATHs of preinstalled applications with no other configuration action.
> But such "on the fly upgrades" requires a level of module compatibility justified only by "bugfix" 
> changes.
> Upgrading the native bindings of an application does not seem to me a change to be made "on the 
> fly" like this.
> Even if the module ABI is preserved, this would be too severe a change.

This another problem in this context: the assumptions and mind-sets that one might have regarding 
the execution of Java programs and Java applications.

Or with other words: it does not meet reality to assume that everyone who runs a Java program or a 
Java application does so by installing a specific individual Java program that comes with a specific 
JRE such that s/he (needs to) control/s the configuration of each individual JRE.

Rather it is a normal deployment scenario that a JRE gets installed globally on a machine that 
serves all Java programs and Java applications available/installed there. Then an update to a bug 
fix version or to a newer Java/JDK version will affect all those Java programs and Java applications 
immediately as their JRE got changed with a single, simple update.

It is in that scenario where the warning aimed at application authors will be - short of an 
application author - be presented to (end) users out of the blue, and a serious warning too! They 
will not be able to know why and what to do, but rather they will get the warning that something is 
serious wrong with their Java program or Java application causing even a warning by Java!

Please realize that the preoccupation is not about this group (expert Java developers with an 
incredible experience and knowledge in particular areas of Java) of people in the know. For you and 
others this does not pose a serious problem, especially as long as you do not realize that there are 
use cases where this "harmless" warning instead creates serious problems, rather quickly destroying 
the trust in Java if Java warns about using Java programs and Java applications suddenly.

As it is astonishingly difficult to communicate the problem at hand I will try to come up with a few 
very short samples that hopefully are able to make one aware about standard JRE deployments (no 
matter which version of Java) that are more than sufficient to run any normal Java program and 
normal Java application. In such deployments no configuration of the JVM is usually necessary and 
users may as a result no even be aware of them.

---rony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230918/3158aa1b/attachment.htm>