> On May 1, 2023, at 10:56 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> On 01/05/2023 10:57, Ron Pressler wrote:
>> :
>>> Do you really plan to make JNI an optional feature which will have to
>>> be manually enabled at startup?
>> Not optional at all, but an important, useful feature that is restricted;
>> JNI’s replacement, FFM will be restricted, too (in its use of native
>> libraries). The restriction of FFM is already mentioned in JEP 442. Another
>> JEP addressing JNI will be published soonish.
> Just to add that "Restricted methods" have been in the Java SE spec since
> Java 19. So far it has just been the restricted methods in the FFM API but
> it's hard to see how this would be extended to list Runtime.load/loadLibrary
> at some point.
In many different places that I am aware of, there are still people using
serial port connected devices. Because Sun stopped supporting their JNI based
access, there have been other versions of such things done. I have packed .dll
and .so libraries into jar files, and copied them to “temp” files and loaded
them from there to provide OS independent jars that could provide applications
that use serial ports, USB or otherwise connected. If
Runtime.load/loadLibrary are limited, a nice way to provide a description of
the details should be part of any implementation that prompts the user to
accept the use of JNI code. Realistically, I don’t know how you do this and
provide the users any guarantees of what OS functions are actually going to be
used. This is the number one reason for me, that I don’t understand why this
support was removed instead of being made a platform feature.
Runtime.load/loadLibrary are the way that the community supports the needs of
their users when the platform doesn’t extend to such functionality. Using it
as a safety “gateway” feature is a steep path…
Gregg Wonderly
