#ReflectiveAccessByInstrumentationAgents

[Peter Levart]

Hi,


On 05/06/2016 10:07 AM, Andrew Dinn wrote:
>> >Have you looked at injecting code in the victim module that invokes
>> >Module addExports to export the packages to the Byteman modules (modules
>> >plural because it sounds like the code is split between the unnamed
>> >module of the app class loader and the unnamed modulie of the boot loader).
> Not yet but I will do. n.b. for all practical purposes there is only one
> Byteman module although which one it is depends upon whether the agent
> jar is hoisted into the bootstrap or remains in the system loader. In
> the former case the code is split but only in that the Main class gets
> left in the system loader  while all others sit in bootstrap. Since Main
> merely acts as a trampoline it does not require any special module linkage.
> regards,
>
>
> Andrew Dinn

So if Main agent class is always loaded by bootstrap loader / unnamed 
module, what about an API point in Instrumentation like:

void addModuleExportsToBootstrapUnnamed(Module module, String pn);

This would only allow adding exports from arbitrary module / package to 
bootstrap unnamed module, which would contain (part of) agent. This part 
of agent could also contain trampolines with regulated access from 
instrumented / tested classes. Every call to such exposed code would 
have to be done by invocation through Byteman layer then which could 
regulate access by any means including but not limited to exporting the 
Byteman code package to selected set of modules.

Such limited addExports API would not allow to break encapsulation in 
arbitrary ways.

Regards, Peter