RE: [aspectj-users] Philosophical Questions

["Gregor Kiczales" <gregor@xxxxxxxxx>]

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!)

-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Merrick Schincariol
Sent: Saturday, July 05, 2003 8:03 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Philosophical Questions

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