#ReflectiveAccessByInstrumentationAgents

[Alan Bateman]

On 06/05/2016 08:32, Peter Levart wrote:
> :
>
> The easiest thing for agent to do then is to observe class loading and 
> when 1st class of a particular module located in an exported package 
> is about to be loaded, instruments it and adds a static method to it - 
> a trampoline that invokes Module.addExports(pn, other). The added 
> method can then be invoked via reflection.
>
> But what if agent needs to augment exports of some module before the 
> 1st exported class of the module comes around? Suppose that classes in 
> concealed packages are loaded 1st and that they already start 
> executing code in them before the 1st exported class is loaded. Agent 
> would have to piggy-back the exports augmentation code on the 
> instrumented methods themselves to ensure exports are added soon 
> enough. What if instrumentation has the goal to introduce as little 
> overhead as possible? Adding redundant Module.addExports() invocations 
> all over the place on hot paths would not help to achieve that goal.
>
> I think that not giving the agent such API just makes life for agent 
> writers harder but does not prevent them to break encapsulation in 
> arbitrary ways anyway. 

We've been over this a few times, it's on the issues list, but we want 
to see how far we can get without adding this method.

On injecting helpers then if the agent can inject an initializer + 
helper method into any public class in the module then it has full 
control. It doesn't matter if it's a concealed package because the 
initializer (which the agent can trigger to execute without access) just 
needs to export the package to the agent.

-Alan