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.
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
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.
- AspectJ -- Released in 2001 from the AOP team at Xerox PARC.
Currently hosted on eclipse.org and backed by IBM. Version reviewed is
- 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.
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.
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
Figure 1. UML sequence diagram with selected dynamic join points highlighted
Numbers below correspond to those in the figure:
- Method execution join points correspond to the life cycle of a method
until it returns.
- 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
- Field access join points correspond to reads and writes of fields; in this case, an assignment of the
namefield that is made on the
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
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.
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
- A means of referring to the
- Advice invoking authentication for the
Accountat the join points specified by the pointcut
Now, let's see how each of the leading AOP tools would handle this aspect.
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
has the effect of capturing the
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
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.
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'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
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.
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.
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.
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.
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
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.
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.
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
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
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
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.
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
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.
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.
- AOP@Work is a year-long series dedicated to helping you
incorporate AOP into your day-to-day Java programming. Don't miss a
single article in the series. See the complete series listing.
- 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).
Accountexample 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
- Browse for books on these and other technical topics.
- Also see the Java technology zone for a complete listing of free Java-focused tutorials from developerWorks.
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