On 05/05/16 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?
Well, that was actually something I also thought of and it is a /very/
neat solution. Indeed the thought behind your rhetorical question is
what motivated me to raise #ReflectiveAccessByInstrumentationAgents as a
missing requirement. An agent really should be considered trusted code,
shouldn't it.
Much as I think this would be the best general solution it doesn't quite
work for me, for practical rather than technical reasons. The downside
of using an API extension is that it requires compiling the agent as
JDK9 code. I need my agent to run on 1.6+ and currently build it using
target 1.6.
I could finesse this issue by releasing both a JDK8- agent and a JDK9+
agent. That path is unattractive because it requires me to maintain dual
source & product. That requires users to reconfigure their build and
runtime paths when they switch between JDK8 and JDK9. This doesn't sound
like much but you would be astonished how many users fail at configuring
this sort of thing (no, /really/).
Anyway, if it came to a beauty contest I'd definitely vote for extending
Instrumentation with yet another God-like power i.e. its own
setAccessible API without any module checks. Of course, I'd prefer that
we adopt this on its merits rather than by resort to mob rule^H^H^H^H
democracy.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
