spect oriented programming's (AOP's) rapid rise in popularity inspires both fear and worshipand for good reasonsit's a very powerful software development technique that separates business logic from the infrastructure services that support that logic. In other words, AOP facilitates the centralization of concerns that cut across code boundaries, such as transactions, security, and auditing. Another compelling use of AOP is in leveraging aspects that enforce policies, such as programmatic security checks, rather than simply relying on programmers to adhere to coding standards.
But because AOP is such a powerful tool you must use it carefullyand for the right reasons. Aspects, by their very nature, can alter the behavior of almost any point of execution within your application. Furthermore, because aspects remove cross-cutting concerns from the normal flow of business logic, their insertion into the execution path of your application is invisible when looking at source code. One of the trickiest parts of working with aspects is defining how
they should be woven into the flow of your application, a process known as defining a pointcut
. Defining pointcuts is challenging because it's difficult to select specific points in the flow of the program (join points) accurately using an expression. For more information about AOP and pointcuts, see the Related Resources in the left column of this article.
Annotations were introduced to the Java language with JSR 175 and the release of Java 5. They provide metadata about packages, classes, fields, and methods that tools and applications can use. Though interesting by themselves, annotations really shine when combined with the power of AOP, as they can alleviate some of the drawbacks of aspects. For example, annotations used in a pointcut can provide visibility into which methods are receiving additional behavior (advice) from your aspects. This lends greater precision and simplifies the pointcut definition itself. Annotations can provide not only a marker for pointcut selection, but also additional information to be used by the aspect when applying its advice.
The most popular example of this practice is declarative transaction management, in which you can use annotations to mark the methods that should be wrapped in a transaction and specify what the transaction isolation level and propagation should be. In fact, this illustrates the approach taken by many lightweight application containers today, and is one method used in EJB 3.0 to declare CMT beans.
Pre-Java 5 Metadata
All the advantages sound good, but what if you're stuck using an older version of Java that doesn't support JSR 175 annotations? Fear not, for there are several options available to you. Most pre-Java 5 metadata solutions involve placing additional data within javadoc comments prefixed with the ampersand (@
) character. Sun actually initiated this approach with their decision to define method deprecation within javadoc comments. Code generation tools such as XDoclet use the same approachletting you process sources and create various other artifacts from the metadata contained in special javadoc comments.
|Despite the power offered by metadata frameworks, all are still plagued by the unfortunate fact that data affecting the behavior of your code is expressed in comments.|
Several frameworks for dealing with javadoc metadata have surfaced recently that give you almost all of the power offered by JSR 175 annotations. QDox and XJavaDoc both allow programs to read javadoc comments from source files. Jakarta Commons-Attributes lets you define annotations in a type-safe manner, scoped only to elements where they have meaning, and inherited automatically in subclasses. Also, you can use Backport 175 to create annotations in Java 1.3/1.4 that are bytecode compatible with JSR 175 annotations.
Spring uses Jakarta Commons-Attributes to enable the use of javadoc metadata by aspects. AspectWerkz and JBoss AOP both provide custom solutions with similar support. Backport 175 and load-time weaving let you integrate pre-Java 5 annotations with AspectJ. Despite the power offered by frameworks such as these, all are still plagued by the unfortunate fact that data affecting the behavior of your code is expressed in comments.
Although their implementations differ, these metadata frameworks share fundamental similarities. They all offer Ant tasks (AspectWerkz and Commons-Attributes tout Maven plugins as well) to process source code javadoc comments and to store metadata for retrieval at runtime. Typically the metadata is read using tools such as QDox or XJavaDoc, and then stored for later retrieval in XML, generated classes, or existing classes enhanced by tools such as ASM or BCEL. An API specific to each provider makes this information available at runtime.