Servlet with broker pattern.
This is the first of a couple of message I hope to write on AOP in Java.
The purpose of the messages is to compare some of the newer proposals,
like Rickard's, JBoss, Jadvise and AspectWerkz to "good old fashioned"
AspectJ.
My goal is not to champion AspectJ over the other proposals. I assume
there are very good reasons (the "XML issue") for there to be AOP systems for Java other
than AspectJ.
Instead my goal is to identify some of the key features of AspectJ that
I believe other AOP systems should also have, and start a discussion
about whether the other proposals have those properties, could have
those properties, and whether it would be a good idea.
This initial message just enumerates and describes some key properties
of AspectJ. The message is primarily focused on the pointcuts and
advice part of AspectJ.
-elements of the join point model are orthogonal-
Perhaps the most important property of the AspectJ design is that
the elements of the join point model are orthogonal. That is, the
join points, the pointcuts, and the advice are orthogonal -- they
can be used in any combination. This was one of the hardest things
to achieve in the design, but it is very important, and it is at
the core of what leads to several of the other nice properties below.
-pointcut language is compositional-
The pointcut language is compositional. This means that you
can take pointcuts and compose them to form other pointcuts.
This means that you can build up crosscutting structure in
a similar manner to what we know about building up procedural
structure or class structure.
-pointcut language supports named abstractions-
The pointcut language supports named abstractions. The user
can define a pointcut like the well-known move pointcut:
pointcut move(): call(void FigureElement+.set*(..));
And then use it elsewhere by name. For example in an advice
like:
after() returning: move() {
Display.update();
}
If you aren't familiar with this example, see the tutorial
at http://www.parc.com/groups/csl/projects/aspectj/
This is just like the naming we know how to do in procedures
and methods. The name defines an abstraction, elsewhere we
can use the abstraction by name.
The combination of supporting named abstraction and being
compositional means we can say nice things like:
after() returning: move() && !cflowbelow(move()) {
Display.update();
}
and easily understand what that means.
-static typing-
Pointcut and advice declarations in AspectJ are statically
typed. This supports separate compilation and it means that
that actual weaving becomes typesafe. Which means the
weaving can happen later than compile time, like load time
or even in the VM.
For the programmer this means I can be confident, when I see
an advice like:
after(FigureElement fe) returning: move(fe) {
Display.update(fe);
}
That this advice will never result in a runtime type error, no
matter what classes it is woven against.
Its critical to have type safety, or else we are asking people
to take a step back in order to take a step forward.
The combination of the above means that named pointcuts are
really very solid abstractions of logical events. This means
we can easily change things on either the defining or the use
side of a named pointcut.
For example, I can change the definition of move() to:
pointcut move(): call(void FigureElement+.set*(..))
&& initialization(FigureElement);
without having to first go and look at all the advice that
directly or indirectly depends on move. Or I can add some
new advice without having to look at the exact definition
of move().
Note that when I say "without having to go and look" I mean
it in exactly the sense as we can change a procedure body
without having to go and look at all the callers, or add a
new call to a procedure without having to go and look at
the body of the procedure. By this I mean that the name
of the procedure, the result type and the argument types
define an interface, and many changes are possible that
stay within the bounds of the interface. So what this
really means is that we OFTEN don't have to go look. Of
course sometimes we do, for procedures or pointcuts.
The guarantee we get is just like with statically typed
procedures. If we keep the pointcut interface the same
we can change either side and know that the program will
still compile and weave.
--extensible--
The combination of the above properties, and in particular the
orthogonality of the join point model makes AspectJ feel fairly
extensible. For example, when we added advice execution join
points we just had to add the join points and a new pointcut.
They just dropped into the language with no other problems. We
can't be sure of course about future extensions, but we have
some optimism about this based on our experience so far.
--other properties--
There are a number of other critical properties that AspectJ
has that any AOP for Java should also have. Because this message
is already long, I will just list them:
- static advice (declare warning, error, soften)
- intertype declarations
- code structure model (support IDE and other browser tools)
- Open Source open standard
The next step is to address to what extent the other proposals
have these properties, in particular to what extent Bill's new
design does. I'd appreciate the help, since I don't know the
details of Bill's new design.