On 09/05/2017 18:19, Stephan Herrmann wrote:
:
Let's assume a language using Instrumentation & ClassFileTransformer for
weaving an aspect into its base.
Lets assume the aspect statically declares a dependence on that base.
Now the weaver needs to make the aspect accessible for base-to-aspect
calls,
i.e., insert a dependency inverse to the existing one.
Has anybody tested, whether Instrumentation.redefineModule() works for
this kind of use case? Are there any caveats? Better approaches?
If the byte code weaving is done at class load time or dynamically
(retransformClasses/redefineClasses) then you should be able to get this
to work, assuming the readability and visibility supports it.
I can't quite tell if "base" means "java.base". Assuming it is, then you
should be able to instrument code in java.base with references to
classes that you have on the boot class path. As part of the
compatibility support to keep existing agents working, the VM will
update java.base to read the unnamed module of the boot loader when you
modify a class in java.base. Classes in java.base are defined to the
boot loader, as is code on the boot class path, so visibility is not an
issue either. More on this in the "Instrumenting code in modules" and
"Visibility" sections of the java.lang.instrument docs [1].
If you doing super advanced stuff then you may need to use
redefineModule to provide additionally readability but you shouldn't
have any issues there. More likely, visibility will the change when you
have cycles but if you have that working now then it should continue to
work.
Is it right that a strategy using compile-time weaving
(rather than load time weaving and reflection)
will not work in a modular application (due to #CyclicDependences)?
Can you expand a bit on this? Is the user code and aspect compiled to
different modules with static references to each other?
-Alan
[1]
http://download.java.net/java/jigsaw/docs/api/java/lang/instrument/package-summary.html
