Aspect-Oriented Programming (AOP) is one of new buzz-words at the high-end of Java technology. AOP addresses Cross-Cutting concerns in a project. These are areas of functionality that are not limited to a single class but instead are applicable across a whole range of classes. The oft-quoted example is application logging, developers can spend considerable time on adding logging and diagnostic code to their class implementations. AOP allows features like logging, especially method-call tracing, to be abstracted out as an Aspect and applied across a whole set of classes.

Higher-level application features such as authorization, access-control, and transactions can be viewed as cross-cutting concerns.

I first ran into AOP via the AspectJ project over 3 years ago. AspectJ used a precompiler to add aspects, declared in a separate source file using regular expressions to match class names and methods to be enhanced.

Since I work for clients for limited engagements I have never felt comfortable leaving a client with a project that depends upon a source-code pre-processor that the client's own staff may not have used. Recently, however, the industry seems to be embracing AOP in a more "wholesome" form. The JBOSS project has embraced Aspect Oriented programming for it's 4.0 release. The JBOSS implementation uses run-time byte-code modification to enhance classes.

The byte-code enhancement can be made via API calls into the AOP framework classes or by dropping an XML descriptor file into your jar file. The enhancements are specified as:

1. Interceptors
   Code to be executed when a method matching a pattern, is called. The pattern specification allows class names, method names and argument lists to be matched. The interceptor implements the Interceptor interface. Interceptors can be grouped into Stacks, named lists of interceptors which can be applied as a group to classes and methods matching a pattern.
2. Aspects
   An Aspect is a class whose methods are bound to class/method name patterns. Whenever a method is called that matches one of the patterns, the method bound to that pattern is called. Aspects do not have to implement a particular interface and they can be declared with VM (One Aspect instance per VM), Class (One Aspect instance per class) and Instance (One Aspect instance for each object) scope.
3. Introduction
   Introductions allow interfaces to be added to a class at run-time. A "mixin" class can be specified which implements the interface. An instance of the mixin class will be created for each new object of the classes specified by the Introduction pattern. Whenever a method in the interface is called on the original object, the method on the mixin instance is called.

Since the modifications are made at run-time, third-party classes can be modified.

JBOSS is heading towards a J2EE++ world where the JBOSS container is J2EE compliant but AOP can be used instead of EJB to enforce deployment concerns such as transactions, security, and persistence. This will be a major leap for J2EE developers who can return to modeling pure Java Objects, with inheritance and add the J2EE features via AOP instead of the current method of subclassing and interfaces. Business logic can be tested outside the J2EE container and deployed into an Enterprise-Savvy environment with AOP.

This seems very powerful, and if you ever programmed on NeXT or Mac OS X Cocoa you'll recognize features that match the Categories and poseAs: features of Objective-C.

For more information on Aspect-Oriented Programming:

• JBoss AOP Home
• JBoss AOP Wiki
• aosd.net
• AspectJ