[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-dev] Question about aspectj weaver
- From: Jim Hugunin <lists@xxxxxxxxxxx>
- Date: Fri, 08 Aug 2003 14:30:36 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Ivica Aracic wrote:
I have a question about the aspectj weaver:
What does the weaver take as input?
How does it know where to insert the advices?
This question deserves a paper to answer it. For now, you'll have to
settle for the following short answer.
Each piece of advice in an aspect is associated with a pointcut. This
pointcut is stored in an attribute on the methods corresponding to each
piece of advice. Before weaving, all of these pieces of advice are
gathered into one large list.
Each .class file is woven independently. A .class file is woven by the
1. Collect all of the joinpoint shadows in the .class file. For every
dynamic joinpoint in the AspectJ language model, there is a
corresponding static shadow of that joinpoint in the bytecode. For
example, every method call joinpoint has an INVOKE bytecode as its
static shadow. Some joinpoints (such as initialization) have much more
complicated static shadows.
2. Each piece of advice is matched to each static shadow. There are
three results possible from this match.
a. Never matches -- in which case nothing is done to the shadow
b. Always matches -- in which case the advice is woven into this
c. Sometimes matches -- in which case the advice is woven into the
shadow along with the minimal dynamic tests to determine if any
particular joinpoint in the actual running program matches the advice.
The simplest example of sometimes matches is when the pointcut uses
3. If any advice matched any static shadows in the .class file, then the
transformed .class file is written out, otherwise it is left unchanged.
See org.aspectj.weaver.bcel.BcelClassWeaver and BcelShadow for the two
primary classes involved in this process.
Note: This explanation ignores the implementations of inter-type
declarations completely. It also ignores performance optimizations such
as fast-match that speed up the weaving process.