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

[Alan Bateman]

On 16/04/2021 17:40, Rafael Winterhalter wrote:
> :
> 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.
>
"are supplementary to a board range of Java applications" is part of the 
concern with the proposal. If possible, it would be good if the write-up 
could separate the requirements for injection/instrumentation by 
frameworks at runtime from the requirements of tool agents. If the 
requirements cover testing time and mocking then it would useful to 
separate those too.

Just to add to Rémi's comment: For frameworks/libraries, the 
Lookup.defineClass and defineHiddenClass APIs are to define classes in 
the same run-time package as the Lookup class. There isn't any API for 
libraries/frameworks to define class in a "new run-time package". 
There's a chunky project there. Part of it is the Lookup API itself, 
part of is that there isn't an exposed way to extend the set of packages 
in a named module. Mandy has done some exploration on this topic and may 
be able to say a bit more about this.

On Java agents, then I think the discussion will eventually lead into 
putting at least some restrictions on agents loaded into a running VM. 
Agents started on the command line with -javaagent are all-powerful but 
maybe agents loaded into a target VM get a restricted Instrumentation 
object that cannot redefine modules or retransform classes in named 
modules. The narrower requirement for agents doing load time 
instrumentation to define auxiliary classes in the same package as the 
class being loaded fits with the intent of the original API and I don't 
think is controversial.

-Alan