The next two sections present the use of aspects in increasingly sophisticated ways. Development aspects are easily removed from production builds. Production aspects are intended to be used in both development and in production, but tend to affect only a few classes.
This section presents examples of aspects that can be used during development of Java applications. These aspects facilitate debugging, testing and performance tuning work. The aspects define behavior that ranges from simple tracing, to profiling, to testing of internal consistency within the application. Using AspectJ makes it possible to cleanly modularize this kind of functionality, thereby making it possible to easily enable and disable the functionality when desired.
This first example shows how to increase the visibility of the internal workings of a program. It is a simple tracing aspect that prints a message at specified method calls. In our figure editor example, one such aspect might simply trace whenever points are drawn.
aspect SimpleTracing { pointcut tracedCall(): call(void FigureElement.draw(GraphicsContext)); before(): tracedCall() { System.out.println("Entering: " + thisJoinPoint); } }
This code makes use of the thisJoinPoint
special
variable. Within all advice bodies this variable is bound to an
object that describes the current join point. The effect of this
code is to print a line like the following every time a figure
element receives a draw
method call:
Entering: call(void FigureElement.draw(GraphicsContext))
To understand the benefit of coding this with AspectJ consider
changing the set of method calls that are traced. With AspectJ,
this just requires editing the definition of the
tracedCalls
pointcut and recompiling. The
individual methods that are traced do not need to be edited.
When debugging, programmers often invest considerable effort in figuring out a good set of trace points to use when looking for a particular kind of problem. When debugging is complete or appears to be complete it is frustrating to have to lose that investment by deleting trace statements from the code. The alternative of just commenting them out makes the code look bad, and can cause trace statements for one kind of debugging to get confused with trace statements for another kind of debugging.
With AspectJ it is easy to both preserve the work of designing a good set of trace points and disable the tracing when it isn t being used. This is done by writing an aspect specifically for that tracing mode, and removing that aspect from the compilation when it is not needed.
This ability to concisely implement and reuse debugging configurations that have proven useful in the past is a direct result of AspectJ modularizing a crosscutting design element the set of methods that are appropriate to trace when looking for a given kind of information.
Our second example shows you how to do some very specific profiling. Although many sophisticated profiling tools are available, and these can gather a variety of information and display the results in useful ways, you may sometimes want to profile or log some very specific behavior. In these cases, it is often possible to write a simple aspect similar to the ones above to do the job.
For example, the following aspect counts the number of calls to the
rotate
method on a Line
and the number of calls to the set*
methods of
a Point
that happen within the control flow
of those calls to rotate
:
aspect SetsInRotateCounting { int rotateCount = 0; int setCount = 0; before(): call(void Line.rotate(double)) { rotateCount++; } before(): call(void Point.set*(int)) && cflow(call(void Line.rotate(double))) { setCount++; } }
In effect, this aspect allows the programmer to ask very specific questions like
How many times is therotate
method defined onLine
objects called?
and
How many times are methods defined onPoint
objects whose name begins with "set
" called in fulfilling those rotate calls?
questions it may be difficult to express using standard profiling or logging tools.
Many programmers use the "Design by Contract" style popularized by Bertand Meyer in Object-Oriented Software Construction, 2/e. In this style of programming, explicit pre-conditions test that callers of a method call it properly and explicit post-conditions test that methods properly do the work they are supposed to.
AspectJ makes it possible to implement pre- and post-condition testing in modular form. For example, this code
aspect PointBoundsChecking { pointcut setX(int x): (call(void FigureElement.setXY(int, int)) && args(x, *)) || (call(void Point.setX(int)) && args(x)); pointcut setY(int y): (call(void FigureElement.setXY(int, int)) && args(*, y)) || (call(void Point.setY(int)) && args(y)); before(int x): setX(x) { if ( x < MIN_X || x > MAX_X ) throw new IllegalArgumentException("x is out of bounds."); } before(int y): setY(y) { if ( y < MIN_Y || y > MAX_Y ) throw new IllegalArgumentException("y is out of bounds."); } }
implements the bounds checking aspect of pre-condition testing for
operations that move points. Notice that the
setX
pointcut refers to all the operations
that can set a Point's x
coordinate; this
includes the setX
method, as well as half of
the setXY
method. In this sense the
setX
pointcut can be seen as involving very
fine-grained crosscutting — it names the the
setX
method and half of the
setXY
method.
Even though pre- and post-condition testing aspects can often be used only during testing, in some cases developers may wish to include them in the production build as well. Again, because AspectJ makes it possible to modularize these crosscutting concerns cleanly, it gives developers good control over this decision.
The property-based crosscutting mechanisms can be very useful in defining more sophisticated contract enforcement. One very powerful use of these mechanisms is to identify method calls that, in a correct program, should not exist. For example, the following aspect enforces the constraint that only the well-known factory methods can add an element to the registry of figure elements. Enforcing this constraint ensures that no figure element is added to the registry more than once.
aspect RegistrationProtection { pointcut register(): call(void Registry.register(FigureElement)); pointcut canRegister(): withincode(static * FigureElement.make*(..)); before(): register() && !canRegister() { throw new IllegalAccessException("Illegal call " + thisJoinPoint); } }
This aspect uses the withincode primitive pointcut to denote all
join points that occur within the body of the factory methods on
FigureElement
(the methods with names that
begin with "make
"). This is a property-based
pointcut because it identifies join points based not on their
signature, but rather on the property that they occur specifically
within the code of another method. The before advice declaration
effectively says signal an error for any calls to register that are
not within the factory methods.
This advice throws a runtime exception at certain join points, but
AspectJ can do better. Using the declare error
form, we can have the compiler signal the
error.
aspect RegistrationProtection { pointcut register(): call(void Registry.register(FigureElement)); pointcut canRegister(): withincode(static * FigureElement.make*(..)); declare error: register() && !canRegister(): "Illegal call" }
When using this aspect, it is impossible for the compiler to
compile programs with these illegal calls. This early detection is
not always possible. In this case, since we depend only on static
information (the withincode
pointcut picks out
join points totally based on their code, and the
call
pointcut here picks out join points
statically). Other enforcement, such as the precondition
enforcement, above, does require dynamic information such as the
runtime value of parameters.
Configuration management for aspects can be handled using a variety of make-file like techniques. To work with optional aspects, the programmer can simply define their make files to either include the aspect in the call to the AspectJ compiler or not, as desired.
Developers who want to be certain that no aspects are included in the production build can do so by configuring their make files so that they use a traditional Java compiler for production builds. To make it easy to write such make files, the AspectJ compiler has a command-line interface that is consistent with ordinary Java compilers.