bidirectional dependencies in AOP-like languages?

Alan Bateman Alan.Bateman at
Wed May 10 07:24:41 UTC 2017

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 

> 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?



More information about the jigsaw-dev mailing list