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
