For those of you who intend to take the AOP pill sooner or later, it is important to know that there are two main trends out there, namely solutions that achieve AOP by:

1. extending existing languages (AspectJ & Co)
2. combining existing technologies without extending them (AspectWerkz & Co)

When AOP adoption is at stake, choosing one or the other solution may not be as straightforward as it seems. In this blog, I will try to make an objective, yet non-exhaustive, comparison between the two of the biggest actors on the AOP scene, namely, AspectJ and AspectWerkz.

The AspectJ community has created a seamless extension to the Java language with a bunch (> 20) of new keywords (aspect, pointcut, etc) as well as a compiler that weaves aspect definitions into your application classes and spits out normal Java bytecode that can be executed on any JVM. AspectWerkz has favored a no-extension approach and uses XML and the conventional Java language syntax and semantics for bringing aspects into the Java language.

In AspectWerkz, aspects are Java classes (+ attribute @Aspect), advices are Java methods (+ attributes @Around, @Before, @After) and introductions are represented by static inner classes (+ attribute @Introduce) or normal Java fields (+ attribute @Implements). Pointcut definitions are either written in XML definition files or within the aspect class as fields (+ attribute @Expression). All these attributes will probably be replaced by metadata annotations when JDK 1.5 comes out. Both AspectJ and AspectWerkz use a very similar pattern language for picking out join points and they both support the same kinds of pointcut compositions (!, &&, ||) and definitions (call, execution, set, etc). However, it is worth noting that AspectJ provides a number of pointcuts that have no direct equivalent in AspectWerkz, such as within(), withincode(), initialization(), staticinitialization(), preinitialization(), adviceexecution(), cflowbelow(), etc.

If you decide to go with the first solution, you will need to integrate the AspectJ compiler into both your development environment and process. Moreover, you will have to learn the new syntax and semantics AspectJ adds to the Java language. While AspectJ provides several modules that you can plug into your favorite IDEs, it might not always be the best solution depending on how open your company is when it comes to adopting new tools and/or languages. In contrary, AspectWerkz allows one to define aspects using conventional Java syntax and semantics, i.e., all aspect-related code is declared using javadoc-like attributes written in class, field and method comments which might lower the learning curve necessary to get your first advanced HelloWorld running.

Now, I am going to discuss an example (shown in Figure 1 below) taken from the AspectJ Programming Guide that I have sort of re-implemented with AspectWerkz in order to provide a very basic comparison between both solutions. Of course, the example is pretty academic and not really complicated, but it's a good start... Also, note that the Screen class is not shown on the figure.

Figure 1. The PointObserving aspect in AspectJ and AspectWerkz
(Click on the image for the full view)

The first thing that comes to mind when seeing this figure is that the AspectJ code is more concise. For instance, there is a code overhead in AspectWerkz's afterChanges() method for retrieving the Point argument that is directly available in AspectJ. Also, the field introduction (observers Vector) has to be done with a Mixin class in AspectWerkz while AspectJ only requires a simple field declaration. The AspectWerkz code (counting the comments) is almost twice as long as the AspectJ code.

I don't mind the Mixin stuff for implementation introductions, but the supplementary line for retrieving the context variables in the advice do bother me actually. Why AspectWerkz does not consider letting one specify the pointcut context variables as parameters to the advice method? This would be quite equivalent to AspectJ: we would be able to keep the JoinPoint parameter (AspectJ's thisJoinPoint and thisJoinPointStaticPart) plus we would get direct access to the context variables as shown below.

  /**
   * @After changes
   */
  public void afterChanges(final JoinPoint jp, Point p) throws Throwable {
    Iterator iter = p.observers.iterator();
    while (iter.hasNext()) {
      updateObserver(p, (Screen) iter.next());
    }
  }
  

Another thing that kind of annoys me is that AspectWerkz has only a conceptual notion of abstract pointcuts. In AspectWerkz's example on Aspect inheritance, we can see that the abstract aspect AbstractLoggingAspect's metadata references "abstract" pointcuts (methodsToLog1, methodsToLog2, methodsToLog3, etc) that can actually only be declared in the concrete sub-aspect LoggingAspect since Java has no notion of abstract fields. This makes it a bit difficult to see all the pointcuts that have to be defined in the concrete aspects in one glance.

AspectJ also provides other inter-type declarations(declare warning, declare error, declare soft, declare parents, declare precedence) that facilitate development but that I haven't been able to find anywhere in AspectWerkz yet. If someone knows the techniques for implementing them in AspectWerkz, I'd be really happy to learn them. Thanks in advance :) On the other hand, AspectWerks allows one to define custom attributes (@@ custom attributes) which AspectJ doesn't. Again, I think that JDK 1.5 will provide the necessary support for getting rid of this difference.

I have been using AspectJ since the first beta versions and I have always been quite happy with it. However, even though AspectJ excels at type-based crosscutting, I still think that it lacks proper techniques for achieving *true* instance-based crosscutting. JBoss AOP and Spring (which I haven't talked about in this blog) are said to achieve this goal but I'm not completely satisfied with those solutions. I'm still looking into how AspectWerkz could provide a better solution to my problem. I'll probably write an update about this problematic in the near future.

As a conclusion I would like to stress that my goal was neither to promote one solution over the other nor to provide an exhaustive comparison between AspectJ and AspectWerkz. There are many other details about both technologies that I haven't talked about. I just wanted to highlight some differences and similarities that I have found between both solutions. Finally, if any information that I have stated in this blog is innacurate, please do let me know.