[External] : Re: New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

[Alan Snyder]

> On May 14, 2023, at 6:07 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> You can continue using JNI, but the application on newer releases will need to allow it. But the way to target multiple releases in a general and elegant way is with multi-release JARs.

Multi-release JARs may be better than conditionals (if you are not supporting JDK 8, but I do), but that is not the issue.

The issue is that release-specific code may need to use deep reflection to fix bugs or compensate for limitations in a specific set of JDK releases.

As long as JNI reflection is not limited, I can make it work by telling clients of my library to enable JNI on the command line.
(But without build tool support, how will they know?)

But if JNI disappears in favor of direct access to C [is that not a long term goal?], then I will need some other way to perform “deep” reflection on the JDK. Unlike other uses of reflection that have been discussed, these uses could be statically declared. For example, I could declare that for some specified set of JDK releases, I need access to a particular field of a particular class, which might be used to prevent certain optimizations in an AOT build.

I guess you could call this a patch facility.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230514/63c8982a/attachment-0001.htm>