AOP Tools Comparison


News: AOP Tools Comparison

  1. AOP Tools Comparison (17 messages)

    IBM's developerWorks has just launched a new article series entitled AOP@Work. The AOP@Work series is intended for developers who have some background in aspect-oriented programming and want to expand or deepen what they know. Each of the authors contributing to the series has been selected for his leadership or expertise in aspect-oriented programming. Many of the authors are contributors to the projects or tools covered in the series. Each article is subjected to a peer review to ensure the fairness and accuracy of the views expressed.

    The series will cover a range of topics, from testing aspect-oriented programs to the intersection of AOP and metadata. Articles are planned once a month through early 2006. The presence of another article series from a major source signals a further move of AOP towards the mainstream.

    The first article in the series, "AOP tools Comparison" is currently headlining the developerWorks website. In the article aspect-oriented programming expert Mik Kersten compares the four leading AOP tools (AspectJ, AspectWerkz, JBoss AOP, and Spring AOP) to help readers evaluate the right tool for their project. You can read the article at:

    As series lead, I welcome commentary from the AOP community regarding individual articles and the series as a whole.

    Threaded Messages (17)

  2. annotations too[ Go to top ]

    JBoss AOP also has the same kind of annotation model as AspectWerkz. I personally prefer the XML approach mostly because I find the need to configure my aspects. I also prefer XML because your object model remains flat without a lot of inheritance all over the place. With JBoss Eclipse IDE, you don't need to deal with XML, so its really a non-issue.

    Also, JBoss AOP 1.1 supports precedence.
  3. XML more familiar than Java?[ Go to top ]

    For many developers, declarative programming in XML is more familiar than Java language extensions.

    I don't see how that is. Just because I've learned how to type brackets and slashes, I don't see how that makes someone's made-up XML more familiar to me than Java with a couple extensions.
  4. XML more familiar than Java?[ Go to top ]

    I don't see how that is. Just because I've learned how to type brackets and slashes, I don't see how that makes someone's made-up XML more familiar to me than Java with a couple extensions.

    Well, I agree. But over the years, many of us have gotten used to seeing magic behavior modification in XML files. (Think transaction or security attributes declared in old EJB deployment descriptors.) So some folks feel more comfortable with plain Java code and XML "enhancement". In the end, something as far-reaching as AOP deserves to be in a language, I feel.
  5. XML more familiar than Java?[ Go to top ]

    Don't know that AOP should always be in a language. I prefer it in most cases outside of core code. If it's in the language, then how can you modify aspects prior to deployment without a recompile? For example, changing logging or security for an application that may be deployed into multiple environments? Maybe it's because I haven't worked closely with the language extensions like AspectJ, but I can't see how that could be easily done without a recompile unless there's some sort of dynamic aspect lookup.
  6. great article[ Go to top ]

    Just wanted to add that this a great article. Mik worked with all AOP providers extensively to make sure that all the information was accurate.
  7. Spring AOP[ Go to top ]

    Two points worth mentioning regarding Spring AOP, correcting statements in the article to some degree:

    * Spring AOP can be used with full target classes too, using CGLIB proxies instead of JDK dynamic proxies. This will automatically kick if no interface was specified and can be enforced through "proxyTargetClass". So the use of an interface is recommended, but not required.

    * Spring AOP can not just be used with XML bean definitions in a Spring bean factory. There is an equally powerful programmatic ProxyFactory API which allows the creation of proxies and advices in plain Java code, completely outside a container and completely without a configuration file.

  8. thanks Mik Kersten[ Go to top ]

    great article.

    I have a fear that annotations has the potential to hurt re-use - why does no one care about this?

    On another note, I think spring has an opportunity to become an early leader in this space as it is not as intrusive (technically and politically) as the other alternatives.

    Longer term adoption of AOP will see changes to the language itself - presumably borrowing heavily from aspectj.

    Whilst aspectj looks awesome and static checking is hugely important, one must be cautious when adopting language extensions - you might encourage their growth. Otherwise we'll all be trying to manage the integration and dependancies of our n favourite language extensions... ;)

  9. I dig the series[ Go to top ]

    I really enjoyed the article. I look forward to learning more about AspectWorx and JBoss AOP.

    Regarding: "Note that with this approach, only objects retrieved from the Spring framework can be advised and that the use of an interface is required."

    As Jurgen stated... this statement is untrue.

    Also it seems like the author chose to pick just about the most verbose way to decorate the Account with the authenticationBeforeAdvice for the Spring example.

    There are others ways to do this that would be less verbose. The only reason I mention this is because the Spring version of the application of the Aspect looks much more verbose than the others.

    I think Spring will be a bit more verbose no matter, but the article makes it seem even more drastic.

    This is a small nit. I hope the series does well.
  10. On Table 4. Semantics overview of the leading AOP tools...

    Under Spring it only lists Regular Expression pointcut expressions. Spring does much more than this. In fact, you can write custom PointCuts. You can even write Dynamic PointCuts.

    Spring even ships with a Dyamic PointCut that works based on which client object is calling the decorated object (proxied object).

    It takes about 5 minutes to write a PointCut class that only allows Advice to be applied to objects that subclass a certain class or implement a certain interface.

    I think the table is a oversimplification, and is a tad inaccurate if I am reading it correctly.

    I need to spend some more time reading this artcle. I read it pretty quick. It is fairly dense with information.

    Sorry for picking out the nits.
  11. Nit Picking Welcome![ Go to top ]

    Hi Rick (and Juergen), Comments like this are always welcome because the article series aims to be accurate about the capabilities of the tools described. Unfortunately, it's hard to be an expert on all of the tools at once, and inaccuracies inevitably creep in. I'll take a look at what we can do to better vet our Spring AOP content in the future.

    Personally I'm very happy about Spring AOP's presence in the field. As one other commentator mentioned, it's less "intrusive" than other tools. While there are some significant qualifiers to that, there's no mistaking that Spring AOP provides a low-cost entry point to the world of AOP for many developers.
  12. Regarding the Spring AOP nits:

    * "with this approach, only objects retrieved from the Spring framework can be advised and that the use of an interface is required". This is simply a bug resulting from an edit, and a sentence about the example using JDK proxies instead of CGLIB proxies needs to be put back. It's confusing enough that make that addition--thanks for catching it Juergen!

    * Regarding Table 4, you bring up an interesting point Rick, as I purposely don't discuss how pointcuts can be extended in any of the approaches and instead focus on explicit language mechanisms. Both Spring AOP and JBoss AOP provide the ability to write custom dynamic pointcuts that will let you do all sorts of matching, e.g. by reflectively checking the type hierarchy at that point. AspectJ and AspectWerkz also provide that ability by letting users write "if" pointcuts, and you can do pretty much whatever dynamic tests you want with the reflective access to the join point context that each tool provides. But that's different than a language mechanism and so I avoided overcomplicating things with that discussion. A language mechanism means that all the developers using the tool on your project know exactly what the primitive pointcut, or "+" notation means. A custom pointcut means that they have to figure out the code that you wrote, and that you'll later change. Perhaps that's why we've seen so little use of "if" pointcuts by users of AspectJ. Extensibility of pointcuts is definitely important for advanced users and it's good that Spring AOP and JBoss AOP make it more easy to use, but the article focuses on the core language mechanisms that newcomers to AOP will have to wrap their heads around.

    * Verbosity of the Spring XML: the point here was to cover the configuration space of an aspect in each approach, and not to try to make the code of each most concise. For example the AspectJ example could use an anonymous pointcut and be reduced to 1/2 it's size, but that would have missed the idea that pointcuts can be separated. So with each approach I took all the declarations that could be separated out and did so. I was trying to show aspects as they would typically approach in each approach, and for this purpose looked through examples written by developers and not those in the tools' documentation. We know that if you give developers the power to configure something they'll use it, and they simply have more configuration available in Spring AOP. As discussed just below that section, this power gives you the ability to configure aspects without re-compiling, which as Drew pointed out above can be a very useful thing that AspectJ and AspectWerkz lack.

    Something that I hope came through clearly in the second article is that the verbosity of Spring AOP's XML is not a fundamental problem. JBoss AOP has provided an "Aspect Manager" view that writes the XML for you, and gives you a nice structure view for inspecting and editing the results. These sorts of designers will become more common, and will give the benefit of conciseness to the approaches that use XML under the hood.

    Thanks all for the feedback, and I'm looking forward to more. I'm particularly curious to hear about what people think of Hugh's point of the possible dangers of annotations overuse and re-use problems. It may be too early since programmers and tools are just now starting to rely on these, but I've seen some pretty messy looking C# code with longer annotation declarations than method bodies. Again, smarter editing facilities could help there too...
  13. Mike,

    According to your article, Spring AOP does not support annotation style.

    But on page 222 of Rod Johnson's "J2EE Development without EJB", he discussed about source-level metadata annotation and presented a Spring example.

    How does that related to the snnotation style in your article? Thanks.
  14. Hi George,

    Spring does not support the annotation style of *declaring aspects* and instead uses the XML style. So in Spring you declare your pointcuts in XML, and not in an annotation on a Java member that corresponds to a pointcut. That's not to say that it does not support other uses of annotations, which it does, and which the J2EE without EJB book discusses. It's also not to say that a tool which supports the annotation style is necessarily better. As the article discusses there are benefits to having all of your aspects configured in a single place.
  15. Spring supports Annotations as well (in the Java code). It has for a while.

    Nick, I expect there to be some small nits. Fundamentally, I am very excited about the article series.

  16. Spring supports Annotations as well (in the Java code). It has for a while.Nick, I expect there to be some small nits. Fundamentally, I am very excited about the article series.Kudos!

    I want to clarify what it means for an AOP tool to support annotations as there are two distinct concepts here, which may be leading to some confusion.

    1) Annotation style of declaring pointcuts and advice. AspectWerkz and JBoss AOP allow you to use an annotation to specify that a particular method is an advice, and to provide the pointcut for that advice as a string parameter to the annotation. This style of declaring aspects is different than AspectJ's code style, and also different than the AspectWerkz, JBoss AOP, and Spring XML styles. It allows the aspects declarations to be made entirely in annotations so that no XML file needs to be used, which is not the case for Spring AOP. Again, it's not necessarily better and the XML style has the benefit of localizing the aspect declarations. For code examples and a detailed discussion of the declaration style tradeoffs see the articles:

    2) Annotations on Java source that can be matched by pointcuts and advice. Annotations made on Java methods effectively extend the signature of those method (e.g. by adding @Transactional). This is great for AOP tools, since it means that you can write a robust pointcut that matches every method involved in transactions. But this is completely separate from whether or not the aspects, advice, and pointcuts are declared as annotations.

    The articles only discuss (1) above, and refer to this as the "annotation style" of declaring aspects. Support for (2) is a recent feature that has been added to all four AOP tools, including Spring, in order to leverage the use of annotations in Java 5 programs. The next article in our series will address (2). It's by Ramnivas Laddad, and tentatively called "Metadata and AOP: a perfect match".
  17. AOP Tools Comparison[ Go to top ]

    Comparing the different AOP frameworks is interesting, but I'd like to see a comparison of what developer tools they supply.

    As has been noted almost every time AOP comes up the extreme level of fragmentation of code (aka "modularization of cross-cutting concerns") can make it quite difficult to "see" what the code "actually" looks like. So, what tools does each framework provide in order to help developers "see"?

    In particular I'd like to know what frameworks have tools for:
    1) static visualization of the application structure
    2) dynamic visualization of what happens to an application when a pointcut is added/removed/changed

    What's the status on these kinds of tools for each framework?
  18. AOP Tools Comparison[ Go to top ]

    So, what tools does each framework provide in order to help developers "see"?In particular I'd like to know what frameworks have tools for:1) static visualization of the application structure2) dynamic visualization of what happens to an application when a pointcut is added/removed/changedWhat's the status on these kinds of tools for each framework?

    Hi Rickard,

    The goal of Part 2 of the article, called Development Tools, is exactly this--to discuss the issue that you outline and to contrast what each tool provides to address this. Table 2 provides a side-by-side comparison:

    To summarize, AspectJ and JBoss AOP have IDE plugins that do a good job of answering (1) above. Thanks to structure views and editor links you always know when a method has advice on it, and what methods are advised by an aspect. The problem is the same as not being able to "see" the inheritance structure of your system, i.e. without a tool you have no idea what methods override a particular methods. These plugins make it as easy to navigate and understand AOP structure as modern IDEs make navigating OOP structure.

    Regarding (2), this is a feature that's particular to approaches that provide "hot deployment" of aspects, where you can configure at runtime what advice apply. JBoss AOP has the only tool support for this, in the form of a server-based aspect management console. For documentation on any of these features you'll need to refer to the individual project's docs, but the article does provide a few screenshots of the tools in action and a comparison of the features.