Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-users] Philosophical Questions

Title: 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


Back to the top