RE: [aspectj-dev] AspectJ implementation question: Additional De penden

[Jim.Hugunin@xxxxxxxx]

Martin Lippert wrote:
> > Can you say what you mean by "direct dependency"?
> Oh, sure. I think of a "direct dependency" if a class/interface is
> mentioned somewhere in the code of another class/interface. Because I am
>   especially interested in the woven code we talk about the woven
> bytecode of a class and the compiled code of an aspect.
> 
>  From my unterstanding the weaving part of the AspectJ compiler inserts
> code into classes that are affetced by an aspect. So the question is: Do
> the pieces of code that got inserted into a class contain only
> references to the aspect? Or is it possible to write an aspect in a way
> that the AspectJ compiler inserts parts of the aspect code (I wrote) in
> the affected class directly?

The AspectJ compiler almost always leaves code in the unit in which it is written.  The bodies of advice are compiled into methods on the aspect's classfile and calls are inserted into any affected classes.  The same is true for introductions which become methods in the compiled aspect and hooks in the affected classes.  The one major exception to this is the bodies of around advice.  By default, these bodies are in-lined at each potentially matching join point shadow.  If this is not done, then a potentially expensive closure object must be created every time the around advice executes.  If you pass ajc the '-XnoInline' flag, then this optimization will not be performed.

However, even though code you write in the aspect isn't inserted into any target classes (at least in -XnoInline mode), there are still many ways that dependencies can be introduced.  A simple example is after throwing advice, i.e.

  after() throwing (MyException me): ptc() { ... }

This will insert a reference to the MyException type in every class that has join point shadows which could match ptc().  Without the direct reference to this type, the exception handling would be a lot less efficient.  There are many other examples of this kind of behavior where code is generated for matching purposes that contains references to types that might only be known to the aspect.

Until Erik and I get around to writing a paper on the bytecode weaving design in AspectJ-1.1, my best recommendation is that you look at the generated bytecode for some simple examples.

-Jim