JEP proposed to target JDK 22: 454: Foreign Function & Memory API

[Maurizio Cimadamore]

On 09/10/2023 18:19, Alan Snyder wrote:
> But the proposed solution means there is no way for applications to 
> guarantee that they won’t crash at runtime because
> some nth level dependency tries to load native code.

If you mean, how do I make sure that code is not used my application, 
this can be done using, e.g.

--enable-native-access=java.base

(this will become the default mode at some point, when we have done some 
of the stuff I've described in my previous email)

>
> The concern is that there appears to be a strong temptation to make 
> this transitory solution permanent without solving the issue of
> "the lack of a mechanism to propagate the native access permissions 
> from a module to its dependencies”.

I think that the problem of lack of mechanism for propagating 
permissions from modules to dependencies is well known and we have been 
discussing it for a long time. The current warning buys us some time, 
allowing also to assess the extent of the problem (lack of propagation) 
in the real world.

But I believe our ultimate goal in this area is to get to some "reliable 
configuration" (in the spirit of the module system), as well as to "fail 
fast". The latter meaning: if your modular application is incorrectly 
configured, it should fail to start, rather than wait until the first 
restricted method is called.

So, these are the things we'd like to explore (how we get there is a 
different topic, and not for this thread), before we make the 
--enable-native-access mechanism "final" and "permanent".

Maurizio


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20231009/6a7af735/attachment-0001.htm>