The AOP Report Card

Software Development

As I discussed last month, to be widely adopted, programming paradigms must be expressive, efficient, intuitive, compatible, and have good tool support. How does the current state of aspect-oriented programming stack up to these criteria? Is this new paradigm destined for success? To find out, this month I examine three of the available AOP tools. (While I specifically mention only AspectJ, AspectWerkz and the JBoss AOP framework, my observations also apply to other AOP tools, such as AspectC++, JAC and Nanning.)

Expressiveness

A programming paradigm is expressive if it lets you write code that clearly indicates what you want it to do. Expressiveness comes from explicit support for good idioms of program structure. To enhance expressiveness, the new mechanisms should be compositional and support abstraction.

AOP mechanisms fare well on expressiveness. This stands out in numerous examples, including those I discussed in my first Crosscut column (“Testing the Waters,” Nov. 2003). Part two of Ramnivas Laddad’s AspectJ in Action (Manning, 2003) also has a nice collection of examples. In addition to capturing good elements of program structure, most AOP mechanisms support some degree of composition and abstraction. The critical new idea in AOP is the pointcut mechanism—pointcuts in AspectWerkz and AspectJ are compositional, and it’s possible to define them as named abstractions.

Advice is another key element of AOP tools (even if it isn’t new)—AspectWerkz and JBoss allow composition of advice. All three tools offer some form of composition and abstraction of introductions, and they also make it possible to handle aspects themselves as named abstractions.

The tools support different degrees of composition of aspects. The expressiveness of AOP mechanisms will no doubt improve, as exciting research is going on in this area. But existing AOP mechanisms already score well on expressiveness, which is the first criterion for a new paradigm to achieve widespread adoption.

Efficiency

Programmers won’t use a new paradigm unless it’s efficient. In general, new mechanisms must have efficiency comparable to hand code and should add overhead only when they’re used (pay as you go).

The efficiency of statically deployed AOP, as provided by AspectJ, is already quite good. It meets the pay-as-you-go criterion and is typically comparable to hand code.

The newer forms of dynamic AOP, as provided by AspectWerkz, JBoss AOP and other frameworks, are more difficult to optimize, but the dynamic tool developers are actively working to adapt the techniques for optimizing static AOP. There’s every indication that dynamic AOP will soon meet the comparable-to-hand-code criterion. In addition, at least one major player is beginning to evaluate the possibility of aspect weaving as part of the virtual machine itself, as an extension to the kinds of caching and just-in-time compiling the VM already does.

Because AOP’s semantics sometimes require whole program analysis, implementing AOP has caused the old issue of compiler speed to resurface. Several tool projects are examining fast incremental re-weaving in the face of the typical changes programmers make during development.

Intuitiveness

A programming paradigm is intuitive if, when you see the first examples of how it works, you naturally begin to understand it. AOP is similar to object-oriented programming (OOP) in this regard. Many developers, when they see good AOP code, find it easy to understand and see its benefits. But learning how to create good AOP code and gaining a feel for the various trade-offs involved can take some time.

AOP proponents must create training and support materials that will help developers quickly learn the power of the technology and how to use it in a range of applications.

With OOP, we saw an early boomlet in which some developers used OO languages but weren’t thinking objects—they still worked in a procedural style, using objects as data structures. Good training and support materials can help avoid similar pitfalls for AOP.

Compatibility

Most AOP frameworks score well on compatibility. Code written with AspectWerkz, AspectJ and JBoss AOP runs on standard Java VMs, which is essential for widespread adoption.

An open question remains as to whether AOP tools should extend the underlying language syntax. AspectJ extends Java syntax, providing a tight integration of AOP with the Java language. AspectWerkz and JBoss AOP use a separate XML-based language to specify aspect functionality, meaning there are no changes to Java. Whether extending the Java language or adding a new external language will ultimately prove more popular remains to be seen. I believe that integrating AOP tightly into the language is the better bet—that certainly was the case with OOP.

Tool Support

Good tool support is vital to widespread adoption of AOP. Structure browsers, online documentation and debuggers really help us to understand a large system written with aspects, just as they do a large system written with objects.

[click for larger image] Crosscut Support Eclipse support for AspectJ makes crosscutting structure explicit with editor annotations and structure view links.

AOP proponents are hard at work in this area. AspectJ support is available for many IDEs, including Sun NetBeans, Borland JBuilder and Eclipse. IntelliJ has early-access support. Once a consensus emerges on how to represent crosscutting aspect structure, these IDE extensions should be able to support tools such as AspectWerkz, as well.

Sustaining the Second Wave

State-of-the-art AOP scores very well on expressivity and fairly well on efficiency and compatibility. These three criteria measure a new paradigm’s potential, some of its costs and ease of integration. Meeting these criteria is what gets a new paradigm out of the starting gate; indeed, this is what has led to so much interest in AOP. Developers see that it can simplify and improve their code, and that it has the potential to be efficient and easy to integrate with existing systems.

But we need more developer support material, including training, books, design guidelines, design notations, libraries and the like. In addition, we need expanded and enhanced tool support. The very first wave of adopters (the so-called bleeding edge) are more willing to do without this, but second-wave developers, who are still early adopters, need better training, support and tools. AOP proponents know that building such a foundation is a key challenge.

Next month: What does crosscutting mean, anyway?