AOP tool builder and consultant, University of British Columbia
08 Feb 2005
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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.
and AspectWerkz both support build-time and load-time
weaving, although AspectJ has focused more on the former and
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.
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
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
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
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
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
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
aspects as easy as it is to work with objects.
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:
- 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).
- 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.
- 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.
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:
- In the Package Explorer, advice shows up as a regular Java member.
- 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.
- An additional context menu on Java elements allows them to be
selected for inclusion in a pointcut without requiring any editing the
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
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 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
- 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
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
- 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
+ Crosscutting becomes explicit, easy to reason about and change.
- 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.
- Less concise aspect and pointcut declarations.
- Lack of static checking for pointcuts.
- Lack of libraries.
+ Similar mechanisms as AspectJ without the
+ Support for hot deployment of aspects.
- 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.
- Only objects instantiated via the framework's proxy mechanisms can be
- 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.
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."
- 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).
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.
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
- Visit the Developer
Bookstore for a comprehensive Listing of technical books,
including hundreds of
- Also see the Java technology zone for a complete listing of free Java-focused tutorials from developerWorks.
|About the author|
Mik Kersten is a leading aspect-oriented programming expert and a
committer on the AspectJ and AJDT eclipse.org projects. As a research
scientist at Xerox PARC, he built the IDE support for AspectJ. He is
completing his Ph.D. at the University of British Columbia, where he is
working on making IDEs more aspect-oriented. He also consults for
companies that build development tools to help them leverage and
support aspect-oriented programming technology.