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

[Vladimir Petko]

Hi,

 I apologise if the reasons were covered multiple times, but have the
build-time warning/compile error been considered as an alternative?

We have merged[1] to keep Java 17 compatible with JNI programs
compiled for Java 8[2], so in the same line of thought would it be
possible to consider that older JNI programs will still run, but it
would not be possible to compile them on modern Java without making
some changes?

With the runtime warning approach it will be hard to detect the issue
during migration to the next stable release of Java whereas build
warning will flag the offending packages.

Best Regards,
 Vladimir.

[1] https://github.com/openjdk/jdk/commit/e36620d80ed837b50cb37e1cf0b66a5eb36e4d46
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031521

On Tue, Oct 10, 2023 at 6:54 AM Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> 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
>
>
>