[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] Philosophical Questions
|
Title: Message
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