On 21/04/2016 08:31, Andrew Dinn wrote:
:
Having to explicitly manage module dependencies to retain compatibiity
with previous behaviour is at the very least a /nuisance/ because it now
means I -- and, no doubt, others in the agent business -- will have to
implement a dual-source agent, one for JDK9(+) and another to continue
to operate in JDK8/7/6 (yes, people can and do still use the latest
Byteman release in all those JDK releases). A solution internal to the
JVM which preserved existing behaviour and so did not require the
insertion of JDK-specific jumps through JDK-specific hoops would be much
preferred. Still, I suppose the releavant implementors are a relatively
small crowd and ought to know what we are doing and how to fix it.
In the JVM TI and java.lang.instrument docs then you'll see that the VM
is required to arrange for the module of instrumented code to read the
unnamed module of both the application and boot class loaders. This is
how we get many existing agents doing instrumentation, profilers and the
like, to instrument code in modules without any knowledge of modules.
We know of course that this isn't sufficient for all use-cases. In the
discussion here then Byteman finds itself in a new world where it
injects code into module A to access a type in module B that is not
accessible to A. The only way that I can see this working is where
Byteman adds supports for modules and in the example, it injects and
executes code in module B to export the package to module A.
-Alan
