Contents: Building aspects Weaving and performance Performance considerations IDE integration Features comparison Around the corner The bottom line Conclusion Resources About the author Rate this article Related content: AOP tools comparison, Part 1 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

In this second half of his two-part AOP tools comparison, aspect-oriented programming expert Mik Kersten focuses on the tools' integration with the development environment and build process, including a point-by-point comparison of the tools' IDE features. To help you make your final decision, the author concludes with a look at what's to come for these rapidly evolving tools, and provides a summary of each one's strengths and weaknesses. Note that this article addresses the implications of the recently announced merger of the AspectJ and AspectWerkz projects.

In Part 1 of this two-part AOP tools comparison, I showed you how the four leading AOP tools (AspectJ, AspectWerkz, JBoss AOP, and Spring AOP) implement the core AOP mechanisms. While the tools have converged on the idea of a join point model, pointcuts, advice, and inter-type declarations, there are significant trade-offs inherent in each tool's handling of AOP syntax. As I showed in Part 1, syntactic decisions not only affect what it feels like to program with aspects -- verbose syntax vs. more direct, pointcuts as code vs. annotations, stored in the same source file as advice vs. localized with the aspect configuration in XML -- but also make a difference when it comes to semantics. Now I'll continue to explore the implications of the different approaches, but this time focus on how the above decisions affect the tool's integration into the overall development process and environment.

I'll start with a more in-depth look at the ramifications of AspectJ's extension of the Java™ language, with particular attention to the pros and cons of the code style in relation to how aspects are built and statically checked. I'll also discuss the tools' different approaches to weaving, using recent AWBench benchmark results to address their impact on performance.

Perhaps the most important topic discussed in this second part of the AOP tools comparison is IDE support. I'll give you a feature-by-feature comparison of the tools' IDE support and a visual comparison of two IDE plug-ins at work. I'll also show how each tool stacks up in terms of documentation and library support, which are important factors in selecting a new technology implementation.

I'll conclude with some speculation on the foreseeable future of the tools, and an overview of each one's core strengths and weaknesses. Table 1 summarizes the key facets of development environment integration discussed in detail throughout in the article.

Table 1. AOP tools comparison: development environment integration

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.

If you haven't read Part 1, you may want to do so now.

Building aspects
The first thing you'll notice when adopting an AOP tool, regardless of whether you're accessing the tool's IDE support or building via Ant and the command line, is how well it integrates with the build environment. The key difference among the AOP tools when it comes to build environment integration is whether the tool uses a language extension. While AspectJ offers a code style that is an extension of the Java language, the other three approaches use a combination of plain Java with XML and annotation-based aspect languages. From the integration point of view, AspectJ's extension of the Java language is beneficial in that aspect declarations have the same concise form and ease of editing as class declarations. On the downside, extending the Java language is a challenge because every tool that parses Java source files must be extended to understand aspects. The result is that, while there is currently a large suite of AspectJ tools (as discussed in the features comparison), the suite is not complete.

In relation to the build environment, the main difference between the approaches is that AspectJ has to provide its own compiler, whereas the other tools can rely on a standard Java compiler. The AspectJ compiler extends the Eclipse Java compiler, and can be run independently of Eclipse on the command line, or used with plug-ins to Eclipse and other IDEs. The AspectJ compiler builds AspectJ and Java code declared in ".java" or ".aj" files, and produces plain Java bytecode. While there are some downsides to requiring a new compiler, it also yields a critical benefit by providing static checking of pointcuts.

Static checking of pointcuts
Java programmers rely heavily on static checking when working with classes. It means never thinking twice about misspelling a method name because the compiler immediately indicates the error. Without static checking, such errors are not caught until run time. AspectJ has full static checking of all aspect declarations, so the AspectJ compiler will immediately indicate a misspelled reference in a pointcut. The other AOP tools check to varying degrees the well-formedness of aspect declarations, but they offer no static checking of pointcuts, whether declared using annotations or XML. For the typical Java developer, this can lead to lots of squinting at XML values and debugging errors at run time. Instead of showing up as an easily fixed compile error, a misplaced bracket in a pointcut will result in a stack trace at run time, which is much harder to read and debug.

With the AspectJ compiler, you get all the benefits of static checking that you expect from Java code, but applied to aspect code. Without it, you must be very careful when typing pointcut expressions and become accustomed to executing the application to identify errors, which can be problematic, given the sophisticated syntax of pointcut expressions.

In Figure 1, you can see the difference in how two tools handle the error of a missing right parenthesis in a pointcut. The top of the figure shows how the error appears in AspectJ, while the bottom shows how it appears in AspectWerkz.

Figure 1. Locating a syntax error in AspectJ vs. in AspectWerkz

AspectJ's compiler eagerly parses aspect code as you type, spotting the parenthesis error immediately. With AspectWerkz, the error won't be detected until run time. As you can see, this sort of syntax error takes much longer to debug in the tools that don't have static checking of pointcuts. But an even more common and time-consuming problem arises from mistakes such as a misspelled type name in a pointcut. Without static checking, the AOP framework silently fails by not invoking any advice. Figuring out what went wrong, especially when first coming up to speed on AOP and pointcuts, can be extremely time-consuming. With static checking, AspectJ's compiler issues a warning noting that the type name or signature could not be resolved. As discussed later, we can expect improvements to static checking support in upcoming tool releases.

Further build environment considerations
The conciseness of a tool's aspect declarations should help determine the benefits of static checking for that tool. For example, Spring AOP demands considerable XML wiring to create advice. The more manual wiring a tool requires, the more time you'll likely spend writing and debugging that wiring, especially if many aspects are present. On the upside, this problem can be resolved by automatically generating the XML wiring. Later, I'll discuss the JBoss AOP Eclipse plug-in's ability to do this.

If AspectJ is your AOP tool of choice, you must move to its compiler on all Java projects for which you want to enable the use of aspects. This may be problematic on some projects (for example, in cases where the compiler used for production builds is centrally specified). On the upside, the AspectJ compiler is intended to be a drop-in replacement for the Java compiler. Another related consideration is the compilation overhead incurred by adding support for aspects, which differs for each tool. I'll discuss this in detail in the next section. Finally, you should keep in mind that AspectJ's language extension approach requires all build-related tools used on a project be extended to AspectJ. This means that many off-the-shelf tools that parse Java code won't work for AspectJ code (metrics and reporting tools, dependency and style checkers, and diff tools used for version control, for example).

What are the build integration trade-offs of language extension?

In this section, I've outlined the main trade-offs of AspectJ's language extension approach from the perspective of build integration:

- Tools that expect plain Java source must be extended to work on aspect code.

- Requires using a different compiler.

+ Extended Java compiler provides full static checking of all aspect code.

+ Writing and debugging pointcuts is much easier.

Although the negatives are inherent in the language extension approach, some of the positives could apply to both the annotation and XML styles in the future. Providing these benefits for the annotation style is key motivation behind the combined @AspectJ effort of the AspectJ and AspectWerkz teams, and will demonstrate that static checking can also work for the annotation style if an underling AOP compiler is used. At this time, the AspectJ compiler is the only commercial-quality AOP compiler, although other research-quality compilers exist. Note that many of the concerns regarding the necessity of a different compiler are inherent to all of the tools. Problems that could stem from compiling new bytecodes also apply to changing those bytecodes at build time, load time, or run time. As discussed in the next section, this weaving process is fundamental to all AOP tools since it enables the modular implementation of crosscutting concerns.

Weaving and performance
Just as OOP programs can be compiled and executed by different mechanisms (for example, interpreted or compiled to bytecode or object code), AOP tools offer different facilities for building and executing aspects. An aspect weaver provides the wiring that causes advice to be automatically invoked as specified by the pointcuts in an aspect. Weavers can take as input AOP code in source or binary form. Aspect weaving has implications for performance and scalability, based in large part on where weaving occurs in the application life cycle. Aspect weaving can happen at the following times:

• Build time -- Part of the standard compile if the OOP compiler has been extended to AOP, or as a post-compile step.
  
  
• Load time -- Identical to the compile-time weaving of aspect bytecodes, but done when classes are loaded.
  
  
• Run time -- Interception and proxy-based mechanisms provide a means for matching pointcuts to determine when advice should be invoked.

AspectJ and AspectWerkz both support build-time and load-time weaving, although AspectJ has focused more on the former and AspectWerkz on the latter. JBoss AOP and Spring AOP focus on the run time, using dynamic proxies and interceptors to invoke aspects. Note that the Java VM technology could also be extended to support weaving at run time, though it is still in the research phase. A key benefit of using a run-time interception framework is that it naturally extends to the hot deployment of aspects. This means that the advice that apply can be enabled and disabled at run time.

Hot deployment is a core feature of JBoss AOP, which provides an application server management console for enabling and disabling aspects. It is also available in Spring AOP. Similar extensions to the AspectWerkz build- and load-time weaving model support hot deployment. In AspectJ, enabling and disabling aspects in this way needs to be done with an "if" test in the advice or with the "if" pointcut. The term "dynamic AOP" is sometimes used to describe hot deployment, but note that this term can be misleading since all of the AOP tools support dynamic join point models. Also worth noting is the fact that Spring AOP is entirely based on a proxy mechanism. This makes the tool suitable for coarse-grained crosscutting, but pure proxy-based AOP cannot be used to advise finer-grained join points, such as method calls or field sets. On the other hand, Spring AOP's proxies can be used without any build-time or load-time weaving, which can be useful for some application sever deployments.

Performance considerations
The key thing to note in any discussion of AOP and performance is that the arguments against the performance of AOP implementations are similar to the ones made against objects years ago. In general, code with aspects performs similarly to that of a purely object-oriented solution, where the crosscutting code is scattered throughout the system. In most enterprise applications where execution time is dominated by remote and database calls, there is typically no need to worry about the overhead of using any AOP tool.

That said, it is valuable to consider the recently released AWBench benchmarks for AOP tools (see Resources). To understand those benchmarks, we need to consider how the tools' different approaches to aspect weaving and compilation affect performance.

AspectJ incurs compilation overhead in terms of memory usage and time, since it performs most advice planning at compile time. This can be noticeable and potentially problematic on large projects, especially since the crosscutting nature of aspect-oriented dependencies often means that a large part of the system needs to be recompiled when a pointcut changes. But it also means that little additional work for matching pointcuts needs to be done at run time. Another run-time performance benefit results from static typing of join point parameters in AspectJ and AspectWerkz. This yields a performance boost since join point context doesn't need to be accessed reflectively. In contrast, the interception-based approaches of JBoss AOP and Spring AOP have more work to do at run time. As a result, you will notice a trend in the AWBench benchmarks ranking AspectJ's advice invocation as fastest, then AspectWerkz, JBoss AOP, and, finally, Spring AOP. By contrast, AspectJ incurs the most build-time overhead, AspectWerkz less, JBoss AOP even less, and Spring AOP none.

Performance trade-offs of interception

What are the main performance trade-offs of the interception and proxy-based AOP implementations of JBoss AOP and Spring AOP?

+ Negligible memory and time overhead when building

- Advice invocation overhead at run time, needed to determine pointcut matching

As with any performance metrics, these guidelines should be taken with a big grain of salt, and should not considered independently of applications and usage. For example, the typical coarse-grained aspects used with Spring AOP are unlikely to result in any noticeable overhead. None of the tools reviewed have prohibitively bad results. The older AspectJ and AspectWerkz tools have had more optimizations, and the others are catching up. AOP compilers are also a relatively new invention, and we're seeing an increasing rate of optimizations flow from the research community into implementations such as AspectJ. As this happens, we can expect to see build times continue to improve.

IDE integration
The goal of IDE integration is to make it easy to write and build aspect-oriented programs in your favorite IDE. For this to happen, you must be able to invoke an AOP compiler or weaver within your IDE. Another key responsibility of IDE support is to make the system's crosscutting structure easy to navigate and understand.

When editing pointcuts, being forced to run the system and inspect the results to find affected join points is very time-consuming. A parallel issue is one developers often raise when first learning about AOP: "How will I know what effect the aspects have on my system? What if someone else checked in some aspects that affect something I'm working on?" Tool support answers these questions by indicating when a join point is affected by advice. This means that when working on a method, you see all of the advice that affects the method. Conversely, when you write an aspect, you immediately see what join points it affects. Consider how modern Java IDEs provide a convenient means of navigating from a method to all the methods that override it. Such object-oriented tool support makes the inheritance structure of a system explicit. AOP IDE support makes the effects of the crosscutting structure explicit, which makes working with aspects as easy as it is to work with objects.

Comparing plug-ins
Each of the tools offers varying degrees of IDE support, which can be important in helping you select the right one for your project. A quick look at the AspectJ and JBoss AOP IDE plug-ins in action will give you an idea of the range of features supported. In the next section, I'll take a closer look at the tools' IDE plug-ins.

Figure 2 demonstrates how the AspectJ Development Tools (AJDT) plug-in for Eclipse exposes crosscutting structure in the editor, along with views that have been extended to show aspect declarations and their effects. For a detailed description of these features and more screenshots, please refer to the AJDT article in Resources.

Figure 2. AspectJ Development Tools (AJDT) plug-in for Eclipse V1.2.0

Some highlights of the AJDT plug-in follow; list numbers correspond to labels in the figure:

1. The Package Explorer shows aspects and aspect declarations. Pointcuts and advice appear with their own icons, which indicate the kind of the advice (for example, before, after).
   
   
2. Editor support shows structure annotations that allow navigation from an aspect to advised members. The content assist pop-up shows all the join point context available within the advice body.
   
   
3. The Document Outline presents the crosscutting structure for the active editor, indicating the advice and inter-type declarations that affect the corresponding join points. The Aspect Visualiser, just barely visible below the Outline in this compressed screenshot, shows the global effects of the crosscutting across a package or project and highlights source lines affected by advice.
   
   
4. Methods affected by advice show gutter annotations that can be used to navigate to the corresponding aspect declaration. All other affected join points show the same structure (for example, types affected by inter-type declarations and call sites affected by advice).

Like the AJDT plug-in, the JBoss AOP plug-in lets you navigate crosscutting structure using views. In Figure 3, you can see that the JBoss AOP plug-in for Eclipse offers some of the same functionality as the AJDT plug-in. It also has two notable additional features: the Aspect Manager view, which can be used to inspect pointcut bindings, and a GUI for creating enumeration-based pointcuts. Table 2 offers a full comparison of the plug-in features.

Figure 3. JBoss Eclipse plug-in V1.0.1

Some highlights of the JBoss AOP plug-in follow; list item numbers correspond to the labels in Figure 3:

1. In the Package Explorer, advice shows up as a regular Java member.
   
   
2. The Aspect Manager is a graphical view of the jboss-aop.xml file that reduces the problems associated with lack of static checking, such as the need to manually edit XML. It also provides a convenient whole-system view of the program's crosscutting structure.
   
   
3. An additional context menu on Java elements allows them to be selected for inclusion in a pointcut without requiring any editing the pointcut expression.

Features comparison
Table 2 summarizes the current state of the four tools' IDE features. It also provides a summary of the extent to which libraries and documentation are available for each. A detailed discussion follows.

Table 2. IDE support, libraries, and documentation

The following notes address the key features of each tool's IDE support:

• AspectJ -- AspectJ's primary IDE support is for Eclipse. Oracle JDeveloper, Borland JBuilder and Sun NetBeans plug-ins also provide varying degrees of AspectJ support. However, the JBuilder and NetBeans versions are not currently under active development, and as such have lagged behind the AspectJ language releases. An important tool provided with AspectJ is ajdoc, which generates Javadoc-style documentation for AspectJ programs. ajdoc allows the same crosscutting structure that can be navigated in the Document Outline visible in Figure 3 to be navigable as links in the HTML documentation. Content assist in the editor is a recent feature that is helpful for writing aspects, particularly for those not yet familiar with the language and the various primitive pointcuts.
  
  
• AspectWerkz -- AspectWerkz provides a rudimentary Eclipse plug-in. The plug-in's maturity lags behind that of the core AspectWerkz implementation, and real IDE support is not expected from AspectWerkz, although it is an anticipated benefit of the joint @AspectJ effort.
  
  
• JBoss AOP -- JBoss AOP also focuses on Eclipse support. JBoss AOP's plug-in provides the Aspect Manager, which facilitates editing XML configuration files. The Advised Members view makes it possible to navigate crosscutting. JBoss also has a novel dynamic aspect deployment UI, which provides JBoss AOP with run-time facilities for modifying which advice apply. Note that the JBoss AOP plug-in is a recent release. Its maturity is not yet up to par with the rest of the JBoss AOP framework.
  
  
• Spring AOP -- Spring's Eclipse plug-in can be helpful when editing the aspect specification in the XML file, but it does not provide any AOP-specific functionality.

All of the tools rely on existing Java debuggers for launching and debugging. Debugging aspect programs works well in all of the tools, including those without mature IDE support (AspectWerkz and Spring AOP). This means that setting breakpoints in advice and single stepping feels the same as it does in plain Java classes.

Features you may miss
Refactoring support is currently lacking in all of the IDE plug-ins. As a result, if a method name changes, a pointcut that should continue matching that method could stop matching. This is one area where the downsides of language extension crop up. While AspectJ has to provide its own refactoring support for renames, to a small extent, the other approaches can piggyback on existing refactoring support. Because the annotation- and XML style-based tools must use fully qualified Java pointcuts as strings, they can also use refactoring tools capable of renaming fully qualified Java references embedded in XML files and annotations.

Support for UML views is becoming increasingly available in IDEs, despite the fact that the utility of such view is still up for debate. At this time, no UML viewer is compatible with AspectJ or any other AOP tool. If you use a UML viewer on an AspectJ program, it will probably break because it is expecting plain Java code. In contrast, the plain Java approaches will show you the aspects as plain Java classes. This is only marginally useful, since it will fail to show any of the interesting associations between advice and affected join points, or the additional members added by inter-type declarations.

Documentation and libraries
In addition to IDE support, a tool's documentation and library support are important factors in your evaluation. Each of the tools provides online documentation, although the Spring framework offers somewhat sparse and implementation-centric documentation of its AOP functionality. J2EE without EJB and other books about the Spring framework should fill this gap very soon. AspectJ is the most well documented of the AOP tools, with six books in print. Note that the state of the documentation available simply reflects how long each project has been around.

Spring AOP offers excellent library support. Integration with the Spring framework means that it leverages dependency-injecting aspects, provides a sophisticated transaction interceptor library, and supports some interesting third-party aspects, such as the Acegi Security Framework. Spring's AOP libraries also have the benefit of portability between application servers, and the pick-and-choose modularity of the framework makes it easy to adopt other parts of the framework that can leverage AOP support. JBoss AOP provides great integration with the rest of the JBoss framework and JEMS stack, and has the richest set of aspect libraries currently available. These include support for JBoss Cache, J2EE a la carte, JBoss remoting, asynchronous aspects, and the JMX aspect. Currently, AspectJ and AspectWerkz do not include any libraries, although some third-party libraries have been created using these tools. Future releases promise to ship with library support.

Around the corner
The final factor you'll want to consider when evaluating the AOP tools is what's next for them. All of the tools are maturing at a fast pace, and many of the trade-offs discussed here are being addressed by current implementation efforts. What is even more interesting is that the strengths of some approaches are percolating out to others. For example, the crosscutting views that were once particular to AspectJ are now offered by JBoss AOP and could soon be offered by the other tools, as well. The combined @AspectJ effort will filter many of AspectJ's tool support benefits into the AspectWerkz annotation style. It will offer interoperability between the language extension style and the annotation style, making the language syntax a choice for the developer.

Down the road, research on AOP refactoring will produce results usable by all of the approaches. UIs for graphical selection and manipulation of pointcuts will benefit from a common set of heuristics that can turn selections and search results into pointcuts. UML views will start showing AOP declarations and associations. Support for these new features across the board will be possible, thanks to the semantic convergence of the leading AOP tools.

In the long term, performance should become a nonissue. Just as developers do not worry about the overhead of a virtual method dispatch, they will not worry about the invocation overhead of advice. This is true to a large extent now, and will get even better as weavers improve and become more tightly integrated with JITs and VMs.

Two other trends are further out, but also likely. First, AOP's join point model and pointcut mechanisms have applicability beyond programming languages to other tools that can benefit from a concise language for describing run-time events. As the adoption of AOP tools increases, the use of pointcuts could become more common in tools such as debuggers and profilers. For example, a breakpoint could be set on a particular control flow. The other incoming trend relates to model-driven development (MDD). Since crosscutting concerns are so fundamental in systems, MDD tools will benefit from modeling crosscutting structure and generating aspects.

Here's a list of concrete features to look for in upcoming releases of the tools:

• AspectJ and AspectWerkz -- AspectJ 5 will feature support for generics in pointcuts. The @AspectJ syntax will support the AspectWerkz annotation style.
  
  
• JBoss AOP -- Static typing for parameters, performance improvements, libraries, and more IDE support features.
  
  
• Spring AOP -- Performance improvements, interoperability with AspectJ's pointcuts, and packaging of some Spring AOP services as AspectJ aspects.

The bottom line
Given the benefits and trade-offs presented here, how do you decide which tool is right for a particular project? What are the main problems you're likely to encounter when adopting a given approach? Here's an overview of each tool's strengths and weaknesses to help you make your final decision. I'll start with a reminder of the pros and cons of hand-coding crosscutting concerns vs. working with an AOP tool.

All tools vs. hand-coded crosscutting

- Advanced IDE features such as refactoring are not yet supported.

+ Aspects are inherent in complex systems, and without an AOP tool an implementation can become brittle and hard to evolve.

+ Crosscutting becomes explicit, easy to reason about and change.

AspectJ

- Language extension requires the use of an extended compiler and related tools.

- Lack of libraries.

+ Concise aspect declarations and static checking for pointcuts.

+ Mature IDE integration.

+ Extensive documentation.

AspectWerkz

- Less concise aspect and pointcut declarations.

- Lack of static checking for pointcuts.

- Lack of libraries.

+ Similar mechanisms as AspectJ without the language extension.

+ Support for hot deployment of aspects.

JBoss AOP

- Lack of static checking for pointcuts.

- Lack of portability to other application servers.

+ Rich set of enterprise aspects libraries are available and integrated with rich JBoss and JEMS libraries.

+ IDE support lowers adoption and reduces need to hand-code XML

+ Support for dynamic deployment of aspects.

Spring AOP

- Only objects instantiated via the framework's proxy mechanisms can be advised.

- Not suitable for fine-grained aspects.

- Lack of IDE support for working with aspects.

+ Simple join point model is well suited to coarse-grained aspects and easier to learn.

+ Spring framework integration and ease of adoption for existing Spring users.

+ Portability of aspect libraries across application servers.

Conclusion
The current crop of AOP tools is exciting for its sheer breadth, and the four tools profiled here are of particular interest due to their current maturity, as well as anticipated future developments. All four of the tools chosen for comparison are mature enough to be suitable for commercial development, and well supported enough that they will be around for some time to come.

A careful analysis of the trade-offs discussed in this two-part AOP tools comparison will help you decide which one is best suited for your projects. I've pointed out the key differences in how the tools deal with aspect declaration, weaving and build integration; overviewed the key performance issues; and highlighted the benefits of IDE integration. I've also given an overview of the pros and cons of Java language extension, a topic of far-reaching importance for Java developers, and pointed out some future directions for AOP tools.

In reading this article, you may have been surprised to find that there are more similarities among the tools than there are differences. This means that whichever approach you choose, the learning curve from one AOP tool will be transferable to another. New developments in each of the tools will continue to cross-pollinate the others. The AOP tools landscape is evolving rapidly to meet the needs of a growing user community, and new releases are frequent. Whatever AOP tool you end up using, I encourage you to sign up for its user discussion list. Your feedback will help shape the future directions of this important technology.

Check back next month for the next installment in the AOP@Work series: Ramnivas Laddad's "Metadata and AOP: A perfect match."

Resources

• See AOP tools comparison, Part 1: Language mechanisms (developerWorks, February 2005) for an in-depth comparison of the tools' aspect declaration style, AOP syntax, and semantics.
  
  
• 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).
  
  
• See Aspect-oriented development with Eclipse and AJDT (developerWorks, September 2004) for a more in-depth look at the AJDT features profiled here.
  
  
• You'll find the current AWBench benchmarks on codehaus.org.
  
  
• The Account example used in Part 1 of this article originally appeared in Ramnivas Laddad's AspectJ in Action (Manning, 2003).
  
  
• The user-base survey in Table 1 (also in Part 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-related titles.
  
  
• Also see the Java technology zone for a complete listing of free Java-focused tutorials from developerWorks.