#ReflectiveAccessByInstrumentationAgents

[Alan Bateman]

On 24/05/2016 16:51, Andrew Dinn wrote:
> :
>
> Given the impending guillotine for completion of JDK I intend to raise a
> JIRA to mark the #ReflectiveAccessByInstrumentationAgents requirement as
> still needing a fix and suggesting a modification to Instrumenatation as
> the way to achieve it. If you have any other alternatives to the ones I
> have described for how to provide agents with java.base privileges I'd
> be very pleased to hear them and consider them as alternative
> implementations. Meanwhile I'll look at providing a webrev which
> implements what would be needed to provide the necessary capability via
> Instrumenatation.
>
Adding an API to make it easy to break encapsulation has concerns so 
this is why it was not included in the API updates to 
java.lang.instrument and JVM TI. For now, the issue is on the JSR issues 
list pending discussion/agreement on the right way to proceed.

In general then we haven't seen problems with instrumentation for 
use-cases that instrument code to call into supporting classes 
(profilers for example). It just works for cases where the agent 
supporting classes are on the class path or boot class append path. It 
also works, via the API, for agent supporting classes in named module too.

The use-cases that aren't directly supported at this time is where the 
agent want to access types in non-exported packages or where an agent 
instruments code that needs to access non-exported packages of other 
modules. Some of potential usages may fall out of the wash with 
#ReflectiveAccessToNonExportedTypes [1] but we'll have to see. The other 
approach that I mentioned is where the agent does load time 
instrumentation, in which case it it can add an initalizer to any 
non-interface class in the module (doesn't have to public, doesn't have 
to be in an exported package). The agent can trigger the initializer to 
run and export the module internals to the agent or other modules. This 
doesn't help the late binding agent case of course but we are down to a 
much small part of the problem space at that point.

So no need to panic, it is on the issue list, and there will be 
tinkering of the design, implementation and API for a few months yet.

-Alan.

[1] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes