Contents: Thinning the crop It's all about join points Aspect comparison Syntactic differences Semantic similarities Language mechanics Conclusion Resources About the author Rate this article Related content: AOP tools comparison, Part 2 A look at aspect-oriented programming Aspect-oriented development with Eclipse and AJDT Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Mik Kersten (beatmik@cs.ubc.ca)
AOP tool builder and consultant, University of British Columbia
08 Feb 2005

AOP is a technology whose time has come, but how do you choose the right tool for your projects? In this first article in the new AOP@Work series, aspect-oriented programming expert Mik Kersten compares the four leading AOP tools (AspectJ, AspectWerkz, JBoss AOP, and Spring AOP) to help you decide which one is for you. In Part 1 of this two-part discussion, the author focuses on the tools' language mechanisms and the trade-offs imposed by the different approaches. Note that this article addresses the implications of the recently announced merger of the AspectJ and AspectWerkz projects.

Aspect-oriented programming (AOP) is becoming increasingly popular on the Java™ platform. As AOP press and conference buzz grows, more tools and implementations of the technology are emerging. While it is clear that AOP is a complementary addition to object-oriented programming, it's less clear how Java developers should evaluate the current crop of AOP tools, particularly given the trade-offs inherent in any new technology implementation.

In this two-part article, the first in a new developerWorks series devoted to AOP, I'll outline the state of the art in AOP tools and compare the most mature approaches to the technology -- AspectJ, AspectWerkz, JBoss AOP, and Spring AOP -- and contrast the adoption-related issues of each. I'll also address the implications of the recently announced merging of the AspectJ and AspectWerkz projects (see Resources).

This article is not intended as an introduction to AOP or a primer on any one particular AOP implementation. Rather, it serves as an overview of the most commonly used AOP technologies available today. In-depth discussion of the trade-offs inherent in each tool's language mechanisms and tool support will help you choose the approach best suited to your projects. The criteria defined here should also make it easier for you to evaluate upcoming releases of AOP tools and features. For a listing of recent developerWorks articles introducing AOP, please refer to Resources.

Note that this is a two-part article, with both parts published simultaneously for your convenience. Part 1 focuses on how each of the four leading tools handles the AOP language mechanisms. Topics include differences and similarities among the tools' aspect syntax and pointcut expressiveness, and the range of mechanisms for declaring aspects. Part 2 continues with a closer look at how the leading AOP implementations integrate with existing development environments, tools, and libraries. Topics include aspect weavers, IDE plug-ins, scalability, and upcoming directions for AOP tools, including a focus on the recent merging of the AspectJ and AspectWerkz projects.

Thinning the crop
AOP is a new technology, and, as such, not all of the current crop of tools are mature enough for commercial development. One of the chief factors in determining maturity is user adoption. Before a new programming technology can be considered for commercial use, it must be hardened by feedback from an active user community. Table 1 shows the currently available AOP tools as listed on aosd.net (see Resources). The number of user-list posts for each tool gives us an idea of its user base. (The actual number of posts is omitted as statistics for a single month could be misleading.)

Table 1. Number of posts to AOP tools user lists in November 2004

About this series 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 (for background on AOP, see Resources). As with most developerWorks articles, the series is highly practical: You can expect to come away from every article with new knowledge that you can put immediately to use. 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. Please contact the authors individually with comments or questions about their articles. To comment on the series as a whole, you may contact series lead Nicholas Lesiecki. About the article This article is not intended to showcase a single tool, but to highlight the strengths and weaknesses of each in a critical and unbiased way. Although the author is a contributor to the AspectJ project, other AOP tool project leaders have been consulted in the writing to ensure fair presentation of the technologies discussed.

Note that the AOP portion of the Spring framework does not constitute a separate download or user community, so a percentage of the user base is likely posting about topics other than Spring AOP. Four additional tools are listed on aosd.net, but they either lack a user discussion forum or showed no posts in November.

While the AOP tools that do not appear among the top four in the table may be technologically sophisticated, the lack of a strong user base suggests that they have not yet withstood the test of adoption. Although not suitable for commercial development at this writing, these tools are worth watching in the future. The table also indicates that non-Java platform AOP tools are less mature than Java platform ones, but it should be noted that the user communities for .NET and C++ tools are growing.

Based on Table 1, you can see that AspectJ, AspectWerkz, JBoss AOP, and Spring AOP are the leading tools in terms of user adoption. All of these tools are open source projects suitable for use in commercial development. They are listed here in alphabetical order, along with V1.0 release dates:

• AspectJ -- Released in 2001 from the AOP team at Xerox PARC. Currently hosted on eclipse.org and backed by IBM. Version reviewed is 1.2.1.
  
  
• AspectWerkz -- Released in 2002 and backed by BEA Systems. Version reviewed is 2.0RC2.
  
  
• JBoss AOP -- Released in 2004 as an addition to the JBoss application server framework. Version reviewed is 1.0.
  
  
• Spring AOP -- Released in 2004 as an addition to the Spring framework. Version reviewed is 1.1.3.
  
  

It's all about join points
Each of the AOP tools reviewed in this article employs a join point model and mechanisms for explicitly declaring a program's crosscutting structure. While there is much similarity in how the tools implement this framework, it's important to understand the underlying mechanisms in order to appreciate the trade-offs of each approach. In this section, I'll review the AOP join point model and the language mechanisms that leverage it.

Enabling mechanisms
AOP tools are designed to modularize crosscutting concerns, such as authentication and transaction management. When implemented with object-oriented programming alone, the code for these concerns becomes scattered across the system. Such scattering makes crosscutting structure needlessly hard to manage and evolve. Just as objects provide a language mechanism to cleanly capture inheritance structures, AOP enables the same benefits of good modularity for crosscutting concerns. At the heart of each of the AOP tools is a join point model, which provides a means of identifying where the crosscutting is happening.

A join point is where the main program and the aspects meet. Static join points allow aspects to define new members on a class. Dynamic join points are where aspect execution meets the execution of the program. For example, plain Java programs execute join points such as method calls and field sets. Consider, for example, the concern of monitoring activity that alters the state of an Account, as discussed in Ramnivas Laddad's book AspectJ in Action (see Resources). The sequence diagram in Figure 1 highlights a few of the dynamic join points that result from operations on an Account.

Figure 1. UML sequence diagram with selected dynamic join points highlighted

Numbers below correspond to those in the figure:

1. Method execution join points correspond to the life cycle of a method until it returns.
   
   
2. Control flows capture the various join points that occur within a control flow sequence; in this case, the sequence below the debit() method call describes all the join points that occur within the debit() call.
   
   
3. Field access join points correspond to reads and writes of fields; in this case, an assignment of the name field that is made on the Account class.

AspectJ and AspectWerkz projects merge AOP technology is moving forward at a fast pace, and upcoming release plans for the leading AOP tools are highlighted in Part 2 of this article. A topic of particular interest to forward-thinking readers will be the recent merging of the AspectJ and AspectWerkz projects, which will result in a significant change to the AOP tools landscape down the road. The combined effort of developers on these projects will yield AspectJ 5, a single tool fluent in the AspectJ and AspectWerkz syntaxes reviewed here. It's important to note that AspectWerkz is not going away. It will become an alternate way of writing AspectJ programs and be renamed to the @AspectJ style. As you'll learn here, syntax is one of the primary differentiating factors between the AOP implementations, whereas the core AOP mechanisms are often very similar. The similarity of AspectWerkz and AspectJ has allowed the two technologies to join forces. The merge will offer greater flexibility in choosing an aspect syntax while preserving key benefits, such as static typing and mature tool support. Details on the merge and related documentation are available in Resources. While this article focuses on tools you can start using today, the outlined criteria and trade-offs also apply to future releases, such as AspectJ 5.

Pointcuts, advice, and inter-type declarations
AOP tools provide a mechanism for identifying sets of join points, called a pointcut. The advice mechanism specifies what action to take when a pointcut is matched in the execution of the program. In addition, inter-type declarations (also known as open classes or mixins) provide a means of declaring additional members on existing types. Together, pointcuts, advice, and inter-type declarations allow AOP languages to express crosscutting concerns explicitly. An aspect declaration can contain these three kinds of members in addition to the regular Java fields and methods. An aspect represents a unit of well-modularized crosscutting structure. As you will see below, the implementation of these mechanisms varies among the various AOP approaches. At the core of each approach, however, is the mechanism for accessing, composing, naming, and abstracting join points.

Pointcuts can describe sets of join points by means of explicit enumeration. An example would be specifying the three method calls of interest on the Account shown in Figure 1. While enumeration can be useful, it is often more convenient to express join points by means of structural properties. Such property-based pointcuts can express a set of join points that matches "every call to a subtype of an Account" without forcing the programmer to enumerate those subtypes. Doing so ensures that when a new class that extends Account is added to the system, it will automatically be matched by the pointcut.

Pointcut support for composition allows you to combine simple pointcuts into more complicated ones. For example, you can limit the pointcut of all Account calls to those made from a particular class or control flow. A mechanism for naming pointcuts facilitates readability and composition. Support for abstraction and concretization makes it easier to create generic libraries that can be defined independently of the application-specific pointcuts to which they will be applied. Finally, support for exposing join point state in pointcuts allows advice to access things like executing objects and method parameters. In the next section, we will see these mechanisms at work in each of the four tools.

Aspect comparison
As previously mentioned, the underlying mechanism of all the AOP tools is the join point model and the concept of pointcuts, advice, and inter-type declarations. The major difference you'll notice among the tools is how aspect declarations are written and applied to the system. The tools approach aspect declaration in one of three ways: using Java-like code, annotations, or XML. For some developers, the familiarity of aspects written in the Java programming language will outweigh the trade-offs of a language extension approach, which are discussed in the next section. For others, the integration benefits of the annotation and XML approaches will outweigh the pain of working with pointcuts as strings.

In this section, I'll use a common example to point out the differences in each tool's approach to aspect declaration. Consider the example of an authentication policy for the Account class shown in Figure 1. In an object-oriented implementation, you would most likely see calls to authentication scattered across methods in the Account class, as well as any other classes that required authentication. In an AOP implementation, you could capture this behavior explicitly with a single aspect and no modification to the code manipulating the accounts. Regardless of the tool used to declare it, this aspect would need the following characteristics:

• A pointcut capturing the execution of all public methods on the banking.Account class
  
  
• A means of referring to the Account being authenticated
  
  
• Advice invoking authentication for the Account at the join points specified by the pointcut

Now, let's see how each of the leading AOP tools would handle this aspect.

AspectJ
Aspect declarations in AspectJ parallel class declaration in the Java language, as shown in Figure 2. Since AspectJ is an extension to the Java language syntax and semantics, it provides its own set of keywords for working with aspects. In addition to containing fields and methods, AspectJ's aspect declaration contains pointcut and advice members. The pointcut in the example uses a modifier and wildcard pattern to express "all public methods." Access to the account is provided by a pointcut parameter. The advice uses this parameter, and the pointcut binds it using this(account). This has the effect of capturing the Account object on which the method is executing. Otherwise, the body of an advice is similar to the body of a method. The advice can contain the authentication code or, as in this case, it can invoke another method.

Figure 2. Aspect in AspectJ

Building an AspectJ program is similar to building a Java program. It involves invoking the AspectJ incremental compiler, which builds all the project sources, including the plain Java sources. Running an AspectJ program is also identical to running a Java program, noting that the small aspectjrt.jar library needs to be appended to the classpath. To configure which aspects apply to the system, you must add or remove them from an inclusion list that is passed to the compiler, via the IDE support or a ".lst" inclusion file if you're working in the Ant environment or on the command line. Note that in Part 2, I'll discuss the details of building AOP programs, as well as the concept of weaving aspects.

AspectWerkz
The key difference between AspectWerkz and AspectJ is that Authentication is now a plain Java class, not an aspect. AspectWerkz, JBoss AOP, and Spring AOP add aspect semantics without changing the Java language syntax. AspectWerkz provides two ways to make AOP declarations. The most commonly used are annotations, which can take the Java V5.0 style visible in Figure 3, or a Javadoc style for compatibility with J2SE V1.4. AspectWerkz also supports an alternate XML-based aspect declaration style. The XML style is similar to that of JBoss AOP described below and places the aspect declarations in a separate XML file.

Note that the advice is a plain method declaration. By convention, it is considered to be a different kind of method declaration, since it should not be invoked explicitly, but instead run automatically when a particular pointcut matches. Pointcut declarations in AspectWerkz are string values attached to pointcut "methods," or stand-alone in XML. As a result, there is no import mechanism for pointcuts, and all type references must be fully qualified. Access to the executing Account object is identical to AspectJ's. Note that the planned @AspectJ syntax will look very similar to the AspectWerkz annotation syntax.

Figure 3. Aspect in AspectWerkz

Building an AspectWerkz program involves a standard Java build, followed by post-processing. To run the AspectWerkz program, you must place AspectWerkz libraries on your classpath. The aop.xml file configures the inclusion of aspects in the system, in the event that unpluggable aspects are used.

JBoss AOP
JBoss AOP's XML-based aspect declaration style is visible in Figure 4. JBoss also supports an annotation style similar to the one in Figure 3. In the XML style, aspect, pointcut, and advice declarations are made in XML. Advice is implemented using plain Java methods that are invoked by the JBoss AOP framework. Both pointcuts and their bindings to advice are declared in the aspects using XML annotations. Rather than binding the Account parameter explicitly, JBoss provides reflective access to currently executing objects, requiring a cast to the corresponding type. Note that an upcoming release of JBoss will provide some static typing of pointcut parameters to address this issue.

Figure 4. Aspect in JBoss AOP

Building an aspect in JBoss involves only a plain Java build. JBoss AOP's run-time interception framework manages pointcut matching and advice invocation. Some configuration of the launch and classpath is required, but JBoss AOP's IDE plugin makes this transparent to the user. Aspects are configured in the jboss-aop.xml file.

Spring AOP
Looking at the Spring AOP example in Figure 5, you'll notice that there's more XML at work than in the previous one. Similar to JBoss AOP, Spring's advice implementation is a Java method with special parameters that will be invoked by the Spring framework. The XML declares the accountBean, which gives the Spring framework access to Account objects, including the interceptor used for the advice, the advisor and its matching pattern, and the before advice to apply to that pattern.

Figure 5. Aspect in Spring AOP

Although it presents more fine-grained configuration and wiring, Spring AOP's approach resembles that of JBoss AOP when used with XML. The process for building, running, and configuring Spring AOP aspects is the same as that of JBoss AOP, but relies on the convenient and minimal run-time configuration of the Spring framework, and does not require a separate launcher. Note that when used with JDK proxies, only objects retrieved from the proxies can be advised and the use of an interface is required. If the CGLIB proxy support is used an interface is not required.

Syntactic differences
As shown by the figures above, one of the key differences among the AOP tools is how each one approaches aspect declaration. AspectJ is an extension of the Java language that lets you declare aspects entirely in code. AspectWerkz and JBoss AOP have you annotate your Java code with aspect metadata or declare the aspects in a separate XML file. In Spring AOP, you declare aspects entirely in XML. As a result, programming with aspects can feel quite different in each of the three approaches. Aspect and pointcut declarations in AspectJ's code style will feel just like Java code. In the annotation style of JBoss AOP or AspectWerkz, they'll feel like additional tags made on existing Java elements. And in Spring AOP, as well as the XML style of AspectWerkz and JBoss AOP, they'll feel like using a separate declarative XML language.

Each approach has its advantages, and it's up to you to decide which will better suit your needs, so in this section, I'll briefly discuss some of the fine points that could help you make your decision.

What's your style?
Regardless of which AOP tool you choose, working with advice bodies simply involves working with Java code. The differences become apparent when it's time to modify a pointcut. When working in the XML style, as in Spring AOP, changing a pointcut involves navigating from the advice to the corresponding pointcut declaration in the XML file. On the plus side, this approach localizes all of your pointcuts and aspect configurations, but it can become tedious if you find yourself frequently editing many advice and pointcuts, and repeatedly flipping back and forth between the Java and the XML files.

If you go with the annotation style offered by AspectWerkz or JBoss AOP, you'll have the option of moving the pointcut expression value from XML to an annotation on a Java member. This makes it much easier to work on the advice body and the pointcut concurrently. If you choose the code style of AspectJ, you'll find that working with a pointcut feels like working with code, rather than an unstructured string value. Everything you expect from Java code (such as "import" statements) will also work for pointcuts. By contrast, you'll always need to qualify the type references in pointcuts when using the XML and annotation styles of AspectWerkz, JBoss AOP, and Spring AOP.

Concise or verbose?
Aspect declaration style has a broad impact on what it feels like to work with aspects in each tool. For example, the tools that support declaring aspects in XML also allow you to configure how aspects apply to the system in the same XML file. In the previous section, I showed only pointcut and aspect declarations, but inter-type declarations are similarly affected by the choice of style. In AspectJ, an inter-type method declaration looks almost identical to a normal method declaration and is referred to in the same way. In the other approaches, new methods are added via annotations or XML by specifying that a class extends an additional mixin class and inherits those additional members. Note that at this time, AspectJ is the only tool that provides a static enforcement mechanism that employs pointcuts. Table 2 compares the tools' handling of the key elements of AOP syntax.

Table 2. Comparing syntax among the leading AOP tools

It's clear from the aspect declarations in figures 2-5 that the code style is the most concise approach to working with AOP declarations. It doesn't require naming advice, as advice isn't intended to be invoked explicitly. The code style doesn't require explicitly binding advice to pointcuts, as found in the XML styles, or the return statement required in AspectWerkz's pointcut "method." AspectJ's syntactic extensions to the Java language also let you directly express the verbose wiring you can see in the XML of Figure 3 and Figure 4. Writing aspects in AspectJ feels more like writing Java code, avoids redundant typing, and results in less potential for error. On the downside, Java syntax extension comes at a big price, and the annotation and XML styles yield their own unique benefits. Most notably, the XML styles let you control the binding of pointcuts and advice. This can be beneficial to extending and configuring aspects, which I'll discuss in the next section, along with other trade-offs that result from the various styles.

Code style vs. annotations and XML

So, should you go with the code style, or declare aspects using annotations or XML? Here's a summary of the trade-offs of AspectJ's Java code-based approach:

+ Concise syntax leverages familiarity with Java code and results in less typing and fewer errors.

+ Pointcuts are first-class entities, which makes them much easier to work with.

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

- Advice to pointcut bindings cannot be controlled by the developer.

If this summary doesn't narrow down your decision, don't worry. There's a lot more to be considered than what it feels like to write aspects in each style. Syntactic decisions will come up again when we take a look at semantics in the next section, and also affect tool support, which I'll discuss in Part 2.

Semantic similarities
While there are major syntactic differences among the tools' aspect declaration style, the core AOP semantics are similar. Each tool has the exact same notion of a join point model, treating join points as principled points in a Java program, pointcuts as a mechanism for matching join points, and advice as a mechanism for specifying what to execute when a pointcut is matched.

Table 3 and Table 4 summarize the semantics of each approach. You'll note numerous small differences and slight variations in the naming conventions, but the approaches have converged on the same core concepts. This convergence is a huge benefit because it means that the learning curve is easily transferred from one AOP approach to another. What's left to consider is the trade-offs imposed by the differences in each approach.

Back to join points
The expressiveness of an AOP tool's join point model determines the granularity of the join points available, and how those join points are matched. Each AOP tool offers a number of primitive pointcuts for matching join points. Some primitive pointcuts match only join points of a specific kind (for example, method executions). Other pointcuts can match any kind of join point, based on a common property of those points (for example, all join points in a certain control flow). The kinds of join points, and their specific pointcuts, can be grouped as follows:

• Invocation -- Points when methods and other code elements are called or executed
  
  
• Initialization -- Points in the initialization of classes and objects
  
  
• Access -- Points when fields are read or written
  
  
• Exception handling -- Points when exceptions and errors are thrown and handled
  
  

In addition, the following categories of kindless pointcuts are supported:

• Control flow -- Join points within certain program control flows
  
  
• Containment -- Join points that correspond to places in the code contained within certain classes or methods
  
  
• Conditional -- Join points at which a specified predicate is true

As Table 3 indicates, each of the tools has a slightly different implementation of the join point model and the primitive pointcuts used to match join points. Note that in some cases (indicated in parentheses) join points are not identified with pointcuts.

Table 3. Join points and the primitive pointcuts used to match them

Expressive or simple?
The main trade-off here is in expressiveness vs. simplicity. A more complete and fine-grained set of pointcuts allows more of the interesting points of program execution to be accessible to aspects. For example, an aspect related to persistence might need access to an object's initialization join points. But such completeness brings with it additional complexity and a steeper learning curve. Many Java programmers do not distinguish between calls and execution, and even fewer need to understand the subtleties of initialization. Also, many commonly used aspects are termed auxiliary, in that they are not tightly coupled to the application functionality. Common auxiliary aspects, such as monitoring and logging, typically make use of only coarse-grained pointcuts like method executions. On the flipside, a broader set of pointcuts does have a pay-as-you-go property, as pointcuts can be learned as needed. And attempting to make do without pointcuts can result in forced refactoring of the object-oriented code, for example to expose class initialization in the form of init() methods.

The join point models of AspectJ and AspectWerkz have converged almost completely, and this has been one of the key enablers of the recent merger. The JBoss AOP model is nearly as expressive and only omits some of the less commonly used join points for the benefit of simplicity. One notable difference is that control flows cannot be expressed as "all of the join points under the execution of this pointcut" in JBoss AOP. Instead, the programmer needs to manually list each call in the call stack of interest.

Spring AOP takes a different approach and purposely limits the expressiveness of its join point model. This makes it particularly easy to adopt and useful for coarse-grained crosscutting. An upcoming release will integrate with AspectJ to provide interoperability with fine-grained crosscutting mechanisms.

Join point model expressiveness vs. simplicity

Will your project benefit from a more expressive join point model like the ones offered by AspectWerkz, AspectJ, and JBoss AOP, or would you be better off going with the coarse-grained expedience of Spring AOP? Here's a summary of the trade-offs inherent in the more expressive models, to help you think it over:

- More to learn.

- Only a few pointcuts are required for coarse-grained crosscutting and auxiliary aspects.

+ Many aspects cannot be expressed without fine-grained pointcuts.

+ The learning curve for using new pointcuts is pay as you go.

Language mechanics
I'll close the discussion in this first part of the AOP tools comparison with a more detailed contrast of each approach's language mechanisms. Table 4 is an overview of the AOP semantics of the four tools. The most notable differences are discussed below.

Table 4. Semantics overview of the leading AOP tools

Pointcut matching and composition: AspectJ, AspectWerkz, and JBoss AOP offer similar support for type patterns. All three allow matching on signatures, which for the Java 5 application includes annotations and generics. AspectJ and AspectWerkz offer a concise way of referring to multiple types (for example, Account+ indicates all subtypes of an account). All of the tools support wildcard matching. Spring AOP also offers support for regular expressions. While this may seem like a powerful advantage, it should be noted that the other approaches have chosen to forgo regular expressions in order to discourage pointcuts that are hard to read and potentially brittle. The pointcut composition operators are almost identical across the board. Spring AOP does not provide negation, which is typically used in conjunction with containment join points that are not exposed in the Spring AOP join point model.

Advice forms: AspectJ supports more forms of advice than the other approaches, and, conversely, JBoss AOP only supports one. Each form of advice can be expressed as around advice, so JBoss' approach is not limiting, and it does offer added simplicity. The downside is loss of conciseness, as can be seen from the additional call to proceed with the original method invocation visible in Figure 4, which would not be necessary with a before advice. Also note that forcing advice to adhere to plain Java rules, as the annotation and XML styles do, is problematic in a few cases, since those rules were designed for methods. AspectJ's ability to "soften" exceptions for advised methods can be useful, and does not adhere to the standard method exception-checking semantics.

Join point context: In AspectJ and AspectWerkz, dynamic join point state is accessed by specifying and binding pointcut parameters, similar to how method parameters are declared in the Java language (see Figure 2 and Figure 3). This gives the benefit of static typing for join point context. JBoss AOP and Spring AOP access join point state reflectively, which removes the complexity of parameter binding from pointcut expressions, but at the cost of static typing of the parameters. Java programmers are accustomed to the benefits of static typing for method parameters and get the same benefits from static typing of pointcut parameters. As a result, there are plans to provide statically typed "args" in an upcoming release of JBoss AOP.

Instantiation: In all of the tools, aspect instantiation is controlled by per clauses. As expected, Spring AOP's instantiation model is more simple. Support for additional instantiation mechanisms means that aspects can be written to apply only in a particular dynamic context without the need to write code that stores that context and tests whether the aspect should apply. The main differentiators are that AspectJ supports aspect instantiation per control flow, while AspectWerkz supports instantiation per thread, and JBoss per individual join point. Which is most useful depends on your needs.

Extensibility: Aspect extensibility enables the deployment of library aspects that can later be concretized for a particular application. For example, an aspect library could provide all the logic and infrastructure required for application monitoring. However, to adopt the library for a particular project, the pointcuts used by the library must be extended to the join points specific to the application. AspectJ supports extensibility with abstract aspects, which contain abstract pointcuts and concrete advice. Sub-aspects that extend these must concretize the pointcuts. AspectWerkz and JBoss AOP use a considerably different approach and do not employ the mechanism of abstract pointcuts. Extension is done by subclassing the aspect and defining a new advice binding in XML or via annotations. The explicit binding of pointcuts to advice give AspectWerkz and JBoss AOP the compelling benefit of allowing aspects to be easily extended to a new system without the need to subclass. More usage data from the aspect libraries becoming increasingly available will determine whether AspectJ's special AOP form of inheritance is better or worse than the other approaches' use of Java-style inheritance and pointcut bindings.

Each of the approaches offers a unique set of trade-offs when it comes to the handling of AOP language mechanisms. Summarizing these trade-offs in a simple list is not possible since the benefits of each will vary for different projects. However, the above information provides a guideline for selecting a tool, or for finding an alternative when you encounter a critical limitation.

Conclusion
The challenge of choosing an AOP tool for your project is in comparing the trade-offs of each approach without getting lost in them. This first part of the AOP tools comparison has highlighted the core mechanisms of the four leading AOP approaches, and contrasted their similarities and differences.

If this article were reporting on a new modularity technology 10 years ago, we could have stopped here, and you would be ready to begin writing an aspect in the style of your choice -- probably built on the command line using Emacs or another text editor. Today, however, you can't consider adopting a new technology without a close look at how it integrates with existing development environments and other tools.

So, the second half of this article will focus on how integration factors impact your choice of AOP tool. Among other things, I'll discuss how each tool handles aspect compilation and weaving, as well as how they all stack up in terms of IDE integration and tool support. I'll also compare the basic features of the tools and give you a glimpse of what's around the corner for them, including a further discussion of what you can expect from the merging of the AspectJ and AspectWerkz projects.

Resources

• See the AOP tools comparison, Part 2: Development environments (developerWorks, February 2005), where the author focuses on the tools' integration with the development environment and build process.
  
  
• Read Develop aspect-oriented development with Eclipse and AJDT (developerWorks, September 2004) to get a jump on Part 2, which examines IDE integration.
  
  
• Eclipse.org hosts the recent press release on AspectJ and AspectWerkz joining forces.
  
  
• See the Eclipse Projects to learn more about AspectJ.
  
  
• Codehaus hosts information about AspectWerkz.
  
  
• To learn more about JBoss AOP, visit JBoss.
  
  
• The Spring framework Web site includes information about Spring AOP.
  
  
• Want to learn more about the basics of AOP on the Java platform? Start with Nicholas Lesiecki's Improve modularity with aspect-oriented programming (developerWorks, January 2002).
  
  
• Gary Pollice uses a logging example to introduce the basic concepts of AOP in A look at aspect-oriented programming (The Rational Edge, January 2004).
  
  
• The Account example used in this article originally appeared in Ramnivas Laddad's AspectJ in Action (Manning, 2003).
  
  
• The user-base survey in Table 1 was based on information that originally appeared on aosd.net, home to the annual Aspect-Oriented Software Development conference.
  
  
• For more AOP articles, papers, and presentations by the author, visit his Web site.
  
  
• You'll find articles about every aspect of Java programming in the developerWorks Java technology zone.
  
  
• Visit the Developer Bookstore for a comprehensive Listing of technical books, including hundreds of Java technology-related titles.
  
  
• Also see the Java technology zone for a complete listing of free Java-focused tutorials from developerWorks.