#ReflectiveAccessByInstrumentationAgents

[Peter Levart]

On 05/06/2016 08:29 AM, Alan Bateman wrote:
> On 05/05/2016 23:26, Peter Levart wrote:
>>
>> What about adding an all-powers addModuleExports(module, pn, other) 
>> method to java.lang.instrument.Instrumentation (like it was done with 
>> addModuleReads) to simplify the agent's task? An agent could be 
>> considered trusted code, couldn't it?
> It was looked into but has the potential to break encapsulation in 
> arbitrary ways. I think we have to see how far we can get with 
> injecting code into the target module to export the packages to the 
> agent or other module that the agent is arranging to access the internals.
>
> -Alan

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.

Regards, Peter