#ReflectiveAccessByInstrumentationAgents

[Alan Bateman]

On 21/04/2016 08:31, Andrew Dinn wrote:
> :
> Having to explicitly manage module dependencies to retain compatibiity
> with previous behaviour is at the very least a /nuisance/ because it now
> means I -- and, no doubt, others in the agent business -- will have to
> implement a dual-source agent, one for JDK9(+) and another to continue
> to operate in JDK8/7/6 (yes, people can and do still use the latest
> Byteman release in all those JDK releases). A solution internal to the
> JVM which preserved existing behaviour and so did not require the
> insertion of JDK-specific jumps through JDK-specific hoops would be much
> preferred. Still, I suppose the releavant implementors are a relatively
> small crowd and ought to know what we are doing and how to fix it.
In the JVM TI and java.lang.instrument docs then you'll see that the VM 
is required to arrange for the module of instrumented code to read the 
unnamed module of both the application and boot class loaders. This is 
how we get many existing agents doing instrumentation, profilers and the 
like, to instrument code in modules without any knowledge of modules.

We know of course that this isn't sufficient for all use-cases. In the 
discussion here then Byteman finds itself in a new world where it 
injects code into module A to access a type in module B that is not 
accessible to A. The only way that I can see this working is where 
Byteman adds supports for modules and in the example, it injects and 
executes code in module B to export the package to module A.

-Alan