New candidate JEP: 454: Foreign Function & Memory API

[Pedro Lamarão]

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

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.

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230915/7df81687/attachment-0001.htm>