New candidate JEP: 454: Foreign Function & Memory API

[Rony G. Flatscher]

On 15.09.2023 16:59, Pedro Lamarão wrote:
> Em sex., 15 de set. de 2023 às 11:48, Rony G. Flatscher <Rony.Flatscher at wu.ac.at> escreveu:
>
>     Actually the code already is able to configure the JVM. However, this can be done only, if
>     BSF4ooRexx loads the JVM (and the environment variable BSF4Rexx_JavaStartupOptions is set). It
>     cannot be done if the JVM got already loaded by someone else and the BSF4ooRexx bridge gets
>     loaded into the process.
>
>
> Whoever sets up the JVM must maintain the JVM initialization flags.

No, there is no *must* as so far using Java/JDK as a JRE usually does not force any special 
initialization flags.

> 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.

> I cannot visualize what hypothetical situation is this in which whoever assembles the application 
> and sets up the JVM is somehow incompetent or incapable to apply this change.

Please read up the respective e-mail thread starting with Ron's e-mail from August 21st: 
<https://mail.openjdk.org/pipermail/jdk-dev/2023-August/008061.html>.

---rony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230915/4d957931/attachment.htm>