Second-generation aspect-oriented programming

Apply advice dynamically with the new crop of AOP frameworks

By Dave Schweisguth, JavaWorld.com, 07/05/04

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

Page 3 of 6

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.