I'm
really glad you sent this message. This reply is about a general point,
I'll tackle the specific points later today.
The
flurry of alternative AOP frameworks is clearly a good thing. It shows that
AOP has moved from the invention phase to the first innovation phase. More
people are looking at the technology, in a solution oriented approach, to see
what it can do for them.This will be an exciting time.
But
while I think lots of innovation is great, I worry that these systems may
cause people who are just starting to learn about AOP to reach some false
conclusions. Specifically:
- because these systems have no IDE support, they run the risk of
stoking the false argument that AO programs are hard to understand or debug.
With AspectJ, a simple ajdt demo is enough to show that these problems are
solved.
- because these systems are dynamically typed, they run
the risk of convincing people that AOP is inefficient and also that debugging
will be more difficult with AOP.
- because these systems don't necessarily have orthogonal join
point models, they may seem simpler, but run the risk of making larger AOP
programs more complex to write and/or understand.
- because most of these systems are a subset of AOP, they run the
risk of causing people outside the community to complain that "the AOP people
are talking a lot about a very little". For example, many people look at these
systems and conclude that AOP is just interception -- they miss the whole
point about how pointcuts allow building up crosscutting
structure.
- because of the claims people make about these systems, they run
the risk of causing people to believe that no one is doing any commercial AOP
yet, and that AspectJ doesn't work. Many AOP developers would be better
served, IMHO, to use AspectJ with its much higher degree of engineering,
documentation and support.
Don't get me wrong, I strongly believe this round of innovation should
continue, it is a great thing. I am personally enjoying discussions
with some of the authors of these new systems as to elements of their
design.
But
I wish the voice of AspectJ experience was more represented in this round of
debate about using AOP in practice. For example this idea that AspectJ
is too powerful needs some debunking. Its trivial to subset AspectJ and still
end up with an orthogonal, type-safe, efficient, system that has 5 years of
user experience with it. If size is the issue, that is probably a better way
to go.
So...
I'd really like to encourage AspectJ users who have
running code and experience to speak up more on the many blogs that are
hosting most of this round of AOP discussion. Please speak up! (Its sort of frustrating that all this happens in
individual blogs rather than discuss@xxxxxxxx, but that's a whole other
issue!)
Having just got back from TheServerSide Symposium
in Boston, I can report that AOP was definitely the talk of the conference.
What was surprising to me, however, was the lack of focus on AspectJ. Most
comments were of the form "it's too powerful for most developers" or that
the special compiler makes it difficult to sell in most organizations.
Instead, most of the talks focused on newer "pure Java" AOP
frameworks.
I personally find AspectJ to be a well designed
implementation of AOP concepts. On my weblog (http://www.freeroller.net/page/mschinc), I've been documenting my own exploration of the capabilities that
AspectJ provides. Looking closer at "pure Java" approaches like AspectWerkz
(http://aspectwerkz.codehaus.org/) something has been bothering me, but I haven't been able
to put my finger on it. I'd like to put a couple of questions out to the
list and see where your thoughts are on the subject.
1) Can Aspects themselves be broken down into
smaller sub-components?
Most of the Java AOP frameworks break out aspects
into a number of different pieces. For example, you implement your advice as
one Java class, your introductions as another and then define (usually using
XML) the pointcuts and the relationships between the components. So one
Aspect could actually require many files to implement and define. Does the
complexity of this approach interfere with the AOP philosophy? My fear is
that when the implementation requirements are complex, from a language point
of view, you start to lose track of the problem you are actually trying to
solve.
As an aside, I think the AspectWerkz design for
advice is broken. Because each type of advice is a class (pre, post and
around) and each advice class extends a pre-existing class, you can't share
any information between different types of advice on the same
pointcut.
2) Can pointcuts be modeled separately from
advice?
This follows on the above point, but it's one
that I find a little odd. Most (all?) of the pure Java approaches define
their pointcuts in one file and their advice in another. Presumably this
means that advice can be reused across multiple different aspect
definitions. From a philosophical point of view, can advice be modeled truly
independently from pointcuts? I would think that certain types of advice,
particularly when dealing with cflow and other advanced join points, really
require the pointcut definition to be present in order to make
sense.
3) What role, if any, should metadata play in
AOP?
I know Gregor has commented on the use of
metadata a couple of times, but the JBoss group is charging ahead with their
"AOP" product which encourages developers to use class metadata to load
library aspects. This strikes me as wrong in many ways, but the message that
is reaching the development community is that interceptors and metadata are
all you need to do AOP. Is this just a function of what's easy to implement,
or are people really having trouble grasping the concepts?
I'm looking forward to hearing your
thoughts.
Cheers,
Merrick