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

[Maurizio Cimadamore]

Hi,
We have already added support for issuing warnings in javac:

https://github.com/openjdk/jdk/pull/15964

The compile-time warning can be enabled using the javac flag 
`-Xint:restricted`.

Maurizio


On 09/10/2023 20:41, Vladimir Petko wrote:
> 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://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/e36620d80ed837b50cb37e1cf0b66a5eb36e4d46__;!!ACWV5N9M2RV99hQ!PYY0qO4WUfLtzatLM77pPDk1djYxjh_miKiCXcUhHOzJL9Tn4fKiVxngDxr9du3LQmjV78GBQjfGJpop4_a0gfu1aT_lVDdUYJI$
> [2] https://urldefense.com/v3/__https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031521__;!!ACWV5N9M2RV99hQ!PYY0qO4WUfLtzatLM77pPDk1djYxjh_miKiCXcUhHOzJL9Tn4fKiVxngDxr9du3LQmjV78GBQjfGJpop4_a0gfu1aT_lrqDrH1k$
>
> 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
>>
>>
>>