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

[Ron Pressler]

> On 14 May 2023, at 21:28, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> 
>> 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.

MR-JARs work with JDK 8.

> 
> 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.

But mucking about with JDK internals requires the application’s approval as it threatens integrity. 

> 
> 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.
> 

FFM is recommended over JNI, but JNI will not go away any time soon. But you can perform deep reflection on JDK internals even without it. In that case the application will need to allow that with --add-opens on those releases where it’s needed.

— Ron