The Four Types of Aspect-Oriented Programming (AOP) Weavers

At the Institute for Cyber Security, we use many different technologies to help accomplish our goals. One such technology is Aspect-Oriented Programming (AOP)., where one can "weave" cross-cutting concerns into source code, separating them from core concerns.

While compile-time weaving is common, the weaving process itself can take place at one of four different times: compile-time, post-compile time, load-time, and run-time. The run-time behavior of an application are the same regardless of the approach chosen.

• Compile-time weaving: this is the simplest approach. A compile-time weaver will compile from source and produce woven class files as output. The aspects themselves may be in source or binary form.
• Binary-weaving (also called post-compile-time weaving): this is used to weave existing class files and JAR files. As with compile-time weaving, the aspects used for weaving may be in source or binary form, and may themselves be woven by aspects.
• Load-time weaving: here, binary weaving is defered until the point that a class loader loads a class file and defines the class to the system. To support this, one or more "weaving class loaders", either provided explicitly by the run-time environment or enabled through a "weaving agent" are required. 
• Run-time weaving: this is the weaving of classes that have already been defined to the system without reloading those classes, making it a more dynamic load-time weaver.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Implementing the Decorator Pattern in AspectJ

Last week we covered how we'd implement the decorator pattern in Java to solve how to modify the behavior of an existing class without modifying or subclassing it. It turns out that implementing this behavior is even simpler in AspectJ.For a refresher on the decorator pattern, read the preceding post.

As before, say we have a Car class which has some functionality we'd like to modify, say by adding a top to the car or an engine. Listing 1 shows a Car interface and SimpleCar class.

Listing 1: Car Interface and SimpleCar Class

To add a top or an engine, we'd need separate classes for each functionality, and an abstract class that they extend. But instead, we can just add two aspects (see Listing 2).

Listing 2: TopAspect and EngineAspect Aspects

Each aspect modifies the code so that it performs some behavior prior to calling drive(), and it modifies the getInfo method. Both aspects total twelve lines of code (not including braces), whereas the equivalent code in Java totals nearly double the lines at twenty-two.

We can view the results of the Decorator pattern by calling the getInfo method, which should return "car, with top, with revved engine".

Listing 3: DecoratedTest Class

Line three is very straightforward, whereas the equivalent line in the Java-only implementation is a bit more convoluted, as each constructor must be called for each class. For multiple classes, it can be quite unwieldy.

This is a bit perfect example of using AspectJ's interception capabilities to add a crosscutting concern. In a more realistic example, Car could be a communication class, and TopAspect could be a logger, while EngineAspect could be an encryption engine. In this way, Car could be written without "concern" for logic unrelated to itself, and these new aspects could be added later.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Aspect-Oriented Programming and AspectJ

At the Institute for Cyber Security, we use many different technologies to help accomplish our goals at ICS Labs and the Incubator. One such technology is Aspect-Oriented Programming (AOP), a programming paradigm allowing the separation of cross-cutting concerns from core concerns. Although many software frameworks such as Spring allow for limited aspect-oriented development, I've always been fond of the AspectJ language as it provides a better pedagogy for aspects and how they differ from objects.

Object-oriented programming (OOP) guides developers into exploiting the expressive power of the object model and uses classes as their fundamental building blocks. Generally, classes may be too specialized for general “drop” reuse, are "tangled" (implementing many requirements of a system), or are used in many places ("scattered" in many classes), such as security or session expiration mechanisms.

Because scattering and tangling defy the OOP paradigm, they are symptoms of “crosscutting concerns”, as they cut across many modules in a program. AOP is an attempt to corral these naturally, with aspects being well-modularized crosscutting concerns. Gregor Kiczales and his team at Xerox PARC originated the concept of AOP and its most popular general purpose language, AspectJ. AspectJ is the most well-known and is a superset of Java (i.e., all AspectJ programs compile to Java bytecode).

In AOP, points in the code where we would want to run our code (instead of writing it in the class itself) are called "join points". A join point can be almost any line of code—a method or constructor call, a field get or set, object initialization, or exception handler execution. AspectJ intercepts program execution flow at these join points and runs the code we want to run instead, called advice, which can happen before, after, or instead of the join point. An aspect describes these join points as pointcuts, which can describe one or more join points.

An example Java program using a simple logging mechanism is shown below. In MainClass.java, two methods are being called, and with code from Logger.java being executed when each method (save the main method) is entered and left.

MainClass class (left) and Logger aspect (right)

In the AspectJ program below, any reference to logging in MainClass.java is removed. In place of the Logger class, the Logger aspect encapsulates the logging concern. It has one pointcut called SayAnything that describes all join points that are methods being called (using the call keyword) that starts with “say” and has any number of parameters. Two advice are associated with the pointcut. The before advice gets the signature of the join point it is in, and prints “Entering” with the signature’s name. The after advice does the same, printing “Leaving” with the signature's name instead. Thus, whenever any of these join point is reached in the execution of the program, it calls the code in the before advice, executes as normal until the end of the join point, and calls the after advice.

MainClass class (left) and Logger aspect (right)

At compile time, the compiler "weaves" the code from an aspect’s advice into the join points their pointcuts describe, leaving .class files that any Java runtime may execute. Because aspects are a superset of classes, they can contain members and methods, and can even extend other aspects or classes, although classes cannot extend aspects. Also, aspects can be quite powerful, able to read and process code with around advice, affecting the execution of the program at runtime in dynamic and very interesting ways. By the same token, AOP and AspectJ's power lend itself to augment code outside its boundaries, possibly leading to software contract-breaking. Like in any paradigm, a little knowledge is a dangerous thing (but a little more knowledge can do wonders).

For more on AOP and AspectJ, the seminal paper on AOP is a great start. There is also a classic series of tutorials on AOP by Ramnivas Laddad online.

Picture at the top shows the difference between core and corss-cutting concerns, pulled from an older version of Apache Tomcat. Red shows the relevant lines of code. The XML parsing capability of the project is well-modularized in one file, whereas the project's logger is used in a large number of places.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu