Second-generation aspect-oriented programming

Apply advice dynamically with the new crop of AOP frameworks

Modularization makes programming possible. Throughout the history of computing, a parade of organizational devices—the high-level language, the subroutine, the object—has allowed us to write increasingly more expressive and powerful code. But, just as with computer hardware, when our abilities improve, we raise the bar again, and here in the twenty-first century, we still struggle to quickly and cheaply produce large programs. What is the next step, the new way to structure our programs that will take our abilities to the next level?

Aspect-oriented programming (AOP) is one attempt at an answer. Conceived at Xerox PARC (an auspicious pedigree!) in the late 1990s, AOP intends to modularize cross-cutting concerns: lines of code that would have to be repeated throughout an ordinary program. AOP gathers all of these cross-cutting concerns into a single place, an AOP construct similar to a class, known as advice.

AspectJ, also originally from Xerox PARC and now developed by the Eclipse Foundation, is an implementation of AOP for the Java platform. It is a mature and solid framework that has gone through several significant releases and is even supported by some third-party tools. Recently, however, application server designers have realized that while—just as AOP proponents have been saying for years—AOP seems a natural way to implement many kinds of application server functionality such as remoting, persistence, and transactions, AOP would be much easier to use in the dynamic environment of the Java platform if its implementation were equally dynamic.

For a thorough introduction to AOP concepts and the AspectJ implementation, see Ramnivas Laddad's three-part JavaWorld series, "I Want My AOP!". For this discussion, I assume you're up to speed on AOP basics and briefly present classic AOP examples so we can get on to the new stuff.

Old-school AOP with AspectJ

Here's an example of how aspect-oriented programming might be used in a middleware framework: Imagine that in our framework, a client accesses services via proxies. The services might be in another VM and might be reached by any remoting technology; hiding these things from the client is the framework's reason for being. One of our framework's features is its ability to propagate any context that a developer wishes from the client to the services it calls transparently to the client. For example, an application might log a user into a security service and put an authentication token in the context. From then on, any services called by that application would be able to retrieve the authentication token from the context—on the server side—and use it to control the functionality to which the client has access.

First, let's write a simple test to show that context is propagated:

public class ContextPassingTest extends TestCase {
   public void test() {
      ClientSideContext.instance().put("userID", "dave");
      ContextRetriever proxy = (ContextRetriever)
      assertEquals("dave", proxy.get("userID"));

In our test, we first put an authentication token into the context. Next, we get a proxy to our service from a singleton ProxyFactory. (This is an example of the Service Locator pattern, in which a factory hides from the client the complexity of constructing a proxy to a remote service.) The service, an instance of ContextRetriever, simply returns the requested value from its context. In the test's last line, we ask for our authentication token back and test to see whether it has the value it should. That's it!

As with any nice compact example, a couple of comments are in order. First, note that while this test may seem rather pointless, in a real application, we would read from the context in a place different from where we would write to it and actually use context information on the server side instead of just sending it back.

Second, note that, although this example uses the Singleton pattern in several places because it is well known and succinct, if you ever find yourself writing a widely used framework, you should certainly not use the Singleton pattern in its API. Singleton requires the singleton instance to be a concrete class, whereas interesting classes should always be hidden behind interfaces to allow the implementations to be swapped without affecting clients. Furthermore, since the singleton reference is global, it proves difficult to make an object use a different instance when necessary, such as in testing. (See "Use Your Singletons Wisely" for more on this topic.) Having warned you about the Singleton pattern, I return to using it for brevity, but don't take it to heart.

Now let's look at the classes our test uses. ClientSideContext is simply a singleton wrapper around a HashMap, a place to store context until it's needed:

public class ClientSideContext {
   private static final ClientSideContext INSTANCE = new ClientSideContext();
   public static ClientSideContext instance() {
      return INSTANCE;
   private final Map mContext = new HashMap();
   public void put(Object key, Object value) {
      mContext.put(key, value);
   public Map getContext() {
      return mContext;

The ContextRetriever interface (not shown; see Resources for complete source code) has a single method, get(Object). In this simple example, ProxyFactory (also not shown) just creates and returns an instance of the following ContextRetriever implementation:

public class ContextRetrieverImpl implements ContextRetriever {
   public Object get(Object key) {
      return ServerSideContext.instance().get(key);

ContextRetrieverImpl delegates to a singleton instance of ServerSideContext, which is similar to ClientSideContext but is used on the server side:

public class ServerSideContext {
   private static final ServerSideContext INSTANCE = new ServerSideContext();
   public static ServerSideContext instance() {
      return INSTANCE;
   private final Map mContext = new HashMap();
   public void setContext(Map context) {
   public Object get(Object key) {
      return mContext.get(key);

So, how does the context get from client to server? With the following aspect:

aspect ContextPasser {
   before(): execution(* ContextRetrieverImpl.*(..)) {

This aspect contains a single piece of advice. The advice is before() advice, which runs before the method being advised. The execution() statement determines the methods before which the advice runs. In this case, the expression ContextRetrieverImpl.*(..), referred to as a pointcut, causes the advice to run before any method of the class ContextRetrieverImpl. In the advice's body, where the actual work is done, we finally see how our context is passed: the entire context is copied from ClientSideContext to ServerSideContext. In a real framework, of course, the server side might be in another VM and we'd have a bit more work to do, but our short version illustrates the point.

Writing our context-passing functionality in an aspect gives us some nice advantages over a conventional object-oriented design. It reduces the dependencies from the client and server sides to the context-related classes, without requiring the service to implement an interface (as an EJB (Enterprise JavaBean) component must do to receive a SessionContext). We've actually decoupled context passing from the rest of the framework; so, if for some reason we don't need context passing—perhaps, in some applications, we intend to use only services that don't need context—we can recompile the application without the ContextPasser aspect. The test above will fail, but everything will compile, and code that doesn't require context to be passed will work just fine without the overhead of passing unused context. This is exactly the sort of modularization that AOP was intended to provide. And we don't need to stop here: security enforcement code and even the proxying itself can be moved into aspects as well.

An AOP wish list

As powerful as the AspectJ implementation of AOP is, a demanding developer can always find something new to request. The most obvious is right in front of us: aspects aren't written in Java. That means learning not just a new design, but also new language syntax—and not only does the developer need to understand the AspectJ language, so do the tools that he or she uses. An all-Java way of writing aspects would be welcome.

The way AspectJ ties advice to methods—writing a pointcut expression that matches the names of the methods to be advised—changes the meaning of traditional Java programs in another way. In ordinary Java, a method name is simply an identifier. Far more important than any comment, a well-chosen name is the best way of making a method's purpose obvious to a reader. But in AspectJ, method names (and class, constructor, and field names—although I've given only an example of advising a method, AspectJ can also attach advice to other program constructs) have two purposes: as well as communicating, they must also serve as targets of matching expressions. Changing a method name in a program that includes aspects can cause the method to not be advised when it should be, or to be advised when it shouldn't. Adding and removing methods can cause unexpected effects with aspects as well. Some tools address these issues with AspectJ, but aspects aren't making our life as simple as we had hoped. And even if we manage to keep all of our pointcuts synchronized with our identifiers, we may be tempted to change our identifiers to match existing pointcuts or allow us to write shorter pointcuts, which might compromise our program's readability. Is there another way?

A different issue arises when considering more complex applications than our little example, particularly in distributed, multiuser systems. The advice shown in our example applies to every instance of ContextRetrieverImpl in the virtual machine. Instead, we might want to be able to have some instances of ContextRetrieverImpl that are advised and some that are not. For example, if advice attached to an object consumes significant memory or other resources, we probably don't want it attached to currently unused instances sitting in a cache. Advice with references to unserializable objects might prevent us from serializing an otherwise serializable object. AspectJ does not currently allow us to advise only some instances of a class. There are workarounds, but it would be nice to address the issue directly.

Finally, we might like another kind of flexibility: we might like to be able to add aspects to or subtract aspects from an already-compiled program, or to change the program constructs to which an aspect applies without recompiling. We can't with AspectJ because it weaves advice into advised classes at compile time. (Demonstrate this with the example by deleting the compiled aspect, ContextPasser.class, before running the test.) This behavior violates good object-oriented practices, which strive for designs whose behavior can be changed by configuration, without recompiling. The just-released AspectJ 1.2 does have limited support for weaving advice at load time rather than at compile time, but it addresses only some of the issues discussed here.

The recent trend in the enterprise software world towards lightweight, transparent middleware runs head-on into these issues. In the last year or so, numerous developer groups, looking for a way around the ever-increasing complexity of EJB, have poured their energy into new frameworks aiming to reduce the amount of boilerplate code and configuration that must be written (or generated) when creating a service. High-profile examples in the open source world include JBoss 4.0, Spring, PicoContainer, and HiveMind. Large application server vendors are interested as well, as evidenced, for example, by BEA's support of the Beehive project. Many Web services frameworks, both free and commercial, provide a simplified container as well as or instead of an EJB-based container. And finally, the trend reached a new level of importance in May when Sun's Linda DeMichiel revealed that EJB 3.0 will sweep away much of the old EJB API as well.

All of this activity has energized several interesting areas of investigation in application server design. The facet of interest to our AOP discussion is that middleware has finally been widely recognized as AOP's killer application. Much application-server functionality can be cleanly and logically expressed as aspects. Context-passing, remoting, security, and transactions can all be thought of as add-on functionality that happens "around" (before and/or after) a method call to an ordinary object. Aspect-oriented programming allows an application server designer to provide these features without requiring service developers to extend abstract classes or implement interfaces.

With the spotlight now on AOP in application server environments, AspectJ's restrictions that we discussed above have become important. Flexible, dynamic AOP has been seen as so important to future development that in the last year or so, several new AOP frameworks that address these restrictions have actually been developed. Let's look at our context-passing example reimplemented in one of the new AOP frameworks, JBoss AOP, to see how it stands up to the demands of complex, dynamic applications.

Dynamic AOP with JBoss AOP

JBoss AOP is an AOP implementation developed by JBoss. While it came out of the desire to use AOP in the JBoss application server, it is an independent framework like AspectJ that can be used in any Java program. To see how it compares to AspectJ, let's jump right in to the same example recoded for AspectJ. We'll use all of the same code we used with the AspectJ example with a few exceptions. Here's what advice looks like in JBoss AOP:

public class ContextPasser implements Interceptor {
   public String getName() {
      return getClass().getName();
   public Object invoke(Invocation invocation) throws Throwable {
      return invocation.invokeNext();

JBoss AOP advice is simply a Java class that implements the interface org.jboss.aop.Interceptor. This interface has one trivial method: getName(), which is used for display, and one interesting method, invoke(Invocation), which is where we put the same context-passing code we put in the AspectJ advice. The last line of invoke(Invocation) returns control to the framework. Here it's just a bit of boilerplate, but in a different situation, we could replace the value returned from the actual method call with something else.

That's it! Advice is just a Java class in JBoss AOP, so there is no new syntax to learn and all of your development tools work with it like any other Java code. That takes care of the first objection we raised above.

But where's the equivalent to AspectJ's pointcut expression, which binds the advice to a method call? JBoss AOP provides two different ways to do this. The first uses a configuration file, usually called jboss-aop.xml:

   <bind pointcut="execution(* *->@contextual(..))">
      <interceptor class="ContextPasser"/>

This file is usually read at class load time, so we can add and remove advice and change the methods to which advice applies without recompiling. If we wish, we can compile our aspects instead, just as we did with AspectJ; this file will then be interpreted at compile time rather than at load time.

The other way to attach our advice is even more flexible. We still need a pointcut in jboss-aop.xml to tell JBoss AOP what methods we might want to advise:

   <prepare expr="execution(* *->@contextual(..))"/>

But this doesn't actually advise any classes, only prepares classes to be advised. (The need to prepare classes proves somewhat annoying, and it may disappear in a future version of the Java VM that has better support for runtime class redefinition.) Having prepared our class, we can advise it in our own code at any time:

public class ProxyFactory {
   private static final ProxyFactory INSTANCE = new ProxyFactory();
   public static ProxyFactory instance() {
      return INSTANCE;
   public Object getProxy(String name) {
      Advised advised = (Advised) new ContextRetrieverImpl();
      advised._getInstanceAdvisor().insertInterceptor(new ContextPasser());
      return advised;

In the AspectJ example, we didn't show ProxyFactory because it only constructed and returned an instance of ContextRetrieverImpl. Here we actually instantiate the advice and attach it to the instance we want to advise. With this method, we're completely free to use our advised objects in any context we like. We can have one instance that is advised and another that isn't, or we can add or subtract advice from a single instance as necessary.

I have yet to say anything about how we can free AOP from the issues associated with attaching advice to objects using matching expressions. Careful readers will have noticed that the matching expression used in jboss-aop.xml doesn't actually mention a class or method name. JBoss AOP does allow definition of pointcuts that refer to specific classes, methods, etc., just like AspectJ, but in this example, we chose not to do that. Instead, we use the notation @contextual, which refers to an annotation we placed on the method we want to advise. Here it is in ContextRetrieverImpl:

public class ContextRetrieverImpl implements ContextRetriever {
   /** @@contextual */
   public Object get(Object key) {
      return ServerSideContext.instance().get(key);

A JBoss AOP annotation looks like a javadoc tag but with a double @ sign. JBoss AOP's AnnotationC tool parses Java source and compiles the annotations it finds into a file, usually called metadata-aop.xml. This gives us the most flexibility possible in attaching advice to our code: when AspectJ-style pointcuts do the job, we can use them, attaching our advice without editing the code being advised. If we need to advise a set of methods for which it's unreasonable to write a pointcut, we can either put annotations on the target methods as shown here, or (if modifying the code to be advised is not an option) we can write metadata-aop.xml ourselves.

If you've read about the features coming in J2SE 1.5 (aka Tiger), you might have noticed that JBoss AOP annotations behave much like J2SE 1.5 annotations (which are specified in JSR 175). In fact, JBoss AOP will support JSR 175 annotations when the final version of J2SE 1.5 becomes available, making its own annotation system unnecessary and removing the need for precompilation.

In software, as elsewhere, power and flexibility come at a price. The design tradeoffs that JBoss AOP makes are typical of those made in the new generation of AOP frameworks. Attaching advice at runtime breaks the separation between your code and the AOP framework. The clean separation of advice targeting from code semantics that annotation allows requires code changes, or the complexity of an additional layer of indirection, and so on. But the only good deal is the one that gets you what you need, and the intense effort that has been expended on the new frameworks makes it clear that these features are needed in the application server world.

The competition

JBoss AOP is given here as an example, but it isn't the only serious second-generation AOP framework out there. The following chart lists more AOP implementations for the Java platform and highlights their features.

AOP frameworks

Feature/issue AspectJ AspectWerkzJBoss AOP Springdynaaop
Weaving timeCompile/load-timeCompile/load-timeCompile/load/runRuntimeRuntime
Per-instance aspectsNoNoYesYesYes
Constructor, field, throw, and cflow interceptionAllAllSomeSomeNone
AOP AllianceNoNoNoYesYes

The frameworks are listed roughly in order of "heaviness," from AspectJ on the left—with its own language and supporting tools, rigid separation of aspects from Java code, and static compilation—to lighter-weight frameworks on the right, which do everything at runtime, albeit with more impact on client code. One can actually think of Java's dynamic proxies as a simple AOP framework; they'd be somewhere off to the right side of the table.

"Transparency" indicates whether a framework operates without requiring changes to client code ("transparent"), or whether it requires clients to obtain advised objects from factories ("factory"). JBoss AOP offers a choice of either technique. Frameworks with "per-instance aspects" can attach advice to selected instances of an advised class and not to others. This differs from the ability to associate a different set of aspect state with each advised instance, which AspectJ and AspectWerkz do offer. Note that using per-instance aspects requires using a factory.

"Constructor, field, throw and cflow interception" shows whether a framework can advise program constructs other than methods. Note that all of these frameworks also support introductions or mixins, an important AOP feature that I didn't demonstrate. Most AOP frameworks are standalone, even those associated with application servers. Only Spring's AOP framework is not, or at least is not available separately. The "AOP Alliance" is a common API for aspect-oriented programming implemented by some frameworks.

Finally, the table lists the application server vendors or developers with which most are associated. The IBM-founded Eclipse Foundation maintains AspectJ, and IBM is expected to add AspectJ support to WebSphere. The originally independent AspectWerkz project is now sponsored by BEA and supports BEA's proprietary JRockit virtual machine. JBoss AOP comes from JBoss and will be used extensively in JBoss 4.0.

This table isn't exhaustive. Many more AOP implementations and related projects are available, some going strong, some just announced, and some fading away. The Aspect-Oriented Software Development conference Website is one place to keep watch.

Where do we go from here?

With so many options for aspect-oriented programming, which one should you use? Different projects will find their best fits in different frameworks. More complex projects, especially those involving distributed, multiuser systems, will probably want the dynamic features of the newer frameworks. I hope that understanding the issues outlined in this article will make it easier for you to choose the right framework for your own projects.

Although most of these frameworks are really standalone, it seems likely that many organizations that come to AOP through application server development will choose the AOP framework allied with their application server. The future of AOP in the Java world may be the future of the application server market. It's too early to tell whether the AOP Alliance or some other standards effort will allow developers to move between frameworks with ease, but it seems unlikely given the diversity in approaches among the different frameworks.

And will AOP ever take hold outside of middleware? Most likely. Most developers will work on AOP-enabled middleware without ever worrying about AOP most of the time. But every project needs to open the hood every now and then, and, having seen what AOP can do in middleware, more and more of us are likely to use it elsewhere in our own software systems. The growing ubiquity of middleware just may be AOP's big break.

Dave Schweisguth has written software in the biotechnology industry since 1996 and has used Java since 1997. Presently he's a software architect at Applied Biosystems in Foster City, Calif., where he contributes to and evangelizes the company's next-generation service-oriented software architecture.

Learn more about this topic