Val's Blog
Lots of stuff for Web 2.0 freaks and Javaholics
Feeds RSS | Atom | RDF
 
 
Alan Kay: "90% of code written today is getting around other people's mistakes."
[ Login ]

June 2004
SunMonTueWedThuFriSat
   1  2  3  4  5 
 6  7  8  9  10  11  12 
 13  14  15  16  17  18  19 
 20  21  22  23  24  25  26 
 27  28  29  30    
May  |  Today  |  Jul
XML Feeds   Subscribe with Bloglines

Javaranch Sheriff   My LinkedIn Profile
Drop me a line or two   Bloglines Blogroll
JavaRSS   Referers
How cool are you?   My Reviews

Next trips...
JavaOne 2009 (Jun 2-5, 09)
Top 10 entries (#hits)
(As of Nov 30, 2007)


Top 10 entries (#hits/day)
Come Back (5.032)
(As of Nov 30, 2007)
Recent Blog Entries
Recent Blog Comments
Re: Review of "Marketing Management 12th"
i know marketing management by kotler is good book but the problem is that the management part of this book is totally missing as fare as i know managemet is complete different subject and it should not be mixed i am student of MBA i was looking at ass...

Re: Review of "Pro Spring"
Using simple POJOs + factories without Spring for "echo" and "counter" would be a lot more easier. No need to write those XML files... So, in this case using Spring makes me write a lot more code... (OK, you can generate everything with the help of And...

pls urgent
Hi I am trying to generate the word doc but i m not understanding wats happening any one pls figure it out /* * WordAPI.java * * Created on May 30, 2006, 10:50 AM * * To change this template, choose Tools | Template Manager * and open the te...
Archives (# entries)
Links
Other Blogs
Other Blogs

Reviewing
Reading
Locations of visitors to this page
What they once said...
 

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.


Update: Thanks to Jonas Bonér for spotting one mistake in the AspectWerkz code.


Thanks for a good comparison. But actually you would not write the AW advice the way you have written it. The Point is the target instance, right? So it is retrieved like this: Point p = (Point)jp.getTargetInstance(); A little bit better :-)
Thank you Jonas. My mistake. I have made the changes and updated the text accordingly.
I just wanted to add that you are absolutely correct in your critizism. This is something that we need to work on. I have planned to impl. support for args(), target() and this() in the summer. Thanks. /Jonas
At the time of the blog writting, it was indeed the case. Since AspectWerkz 1.0.RC2 we support the AspectJ "args(<your args, ..>)" syntax to gain direct access to the advised method/constructor/field set in the advice. Support for this(..) and target(..) as showned in the comparison is in our CVS since some days, and will thus be part of the next release. At that time it would be interesting to repost such an article :-) Alex


Add a comment

Title
Body
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Math Quiz 10 + 10 = (Helps stop blog spam)
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).

TrackBack to http://radio.javaranch.com/val/addTrackBack.action?entry=1086086742000

 
About this Blog