RFR: 8200559: Java agents doing instrumentation need a means to define auxilary classes

[Rafael Winterhalter]

On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

The ticket was created as a reaction to a [write-up I made in January 2018](http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000405.html). I certainly did not intend to limit the scope to same-package class definitions for instrumented classes, and even for those I do not think a package-restricted API would be sufficient as I outlined in the comments to [JDK-8200559](https://bugs.openjdk.java.net/browse/JDK-8200559).

I will try to make my case on the mailing list. I hoped this could get resolved within the release of Java 17 as this would make it possible to write agents without use of Unsafe API to support Java 17 and later. Since agents often are supplementary to a broad range of Java applications, the LTS release will likely be an important support boundary for years and years to come.

You surely mean JEP 411 when mentioning `ProtectionDomain`? The JEP mentions

> We will not deprecate some classes in the java.security package that are related to the Security Manager, for varying reasons: [...] ProtectionDomain — Several significant APIs depend on ProtectionDomain, e.g., ClassLoader::defineClass and Class::getProtectionDomain. ProtectionDomain also has value independent of the Security Manager since it contains the CodeSource of a class.

Also, since this is still a proposal, I would believe that APIs that are implemented before JEP 411 is realized should support `ProtectionDomain` for users still supporting the security manager in the transition time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546