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
