JEP draft: Disallow the Dynamic Loading of Agents by Default

[Gregg Wonderly]

> On May 1, 2023, at 10:56 AM, Alan Bateman <Alan.Bateman at 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