Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Rony G. Flatscher]

On 05.09.2023 11:49, Chris Hegarty wrote:
>
> Hi,
>
> I've read all the messages in this thread, and want to offer a somewhat different perspective. I'm 
> biased since I spend quite a bit of my time working on Elasticsearch these days, which is an 
> application, so I'm technically "the user". We experimented with and provided feedback on the FFM 
> API several times over the years. As part of that, we evaluated and have a positive view of the 
> restrictions on native access.
>
> Elasticsearch directly and indirectly leverages natives; directly from JNA, and indirectly as we 
> use Netty. Our plan and previous experiments have been to replace our use of JNA with the FFM API. 
> Given our particular usage, we're not overly concerned with performance (though our experiments 
> showed that the FFM API way outperforms JNA), but rather the benefits of the native access 
> restrictions. The core of the Elasticsearch platform is modularized, and as such we'll limit 
> native access to just the modules that need it. Additionally, we'll use 
> `ModuleLayer.Controller.enableNativeAccess` to grant access to JNI from Netty, as we load Netty in 
> a child layer of the boot layer.
>
> FWIW, I like the alignment JNI and the FFM API, in this respect. Both old and new are treated in a 
> similar way.
>
Employing the FFM API may be something that an application author may not realize unless he is made 
aware of it one way or another.

Employing JNI is different, the application author needs to be aware of it if assembling the 
application for different platforms and architectures where you need different precompiled native 
libraries.

To make sure that the application author is aware of native access, these warnings could be issued 
by the compiler and/or jlink, unless the flag is supplied.

---rony