You can download the Eclipse project as a tar or zip file or browse the code online here.

Implementing the aspect

I decided to use an annotation and an aspect with a pointcut that matches this annotation. All I had to do was to annotate the methods that should be cached.

Here’s the very generic version of a pointcut that matches the execution of all methods annotated with @Cachable:

@Pointcut("execution(@Cachable * *.*(..))")
private void cache() {}

The logic is this simple:

@Around("cache()")
public Object aroundProfileMethods(ProceedingJoinPoint thisJoinPoint) {
  // construct genericIdentifier
  Object obj = cache.get(genericIdentifier);
  if (obj == null) {
    obj = thisJoinPoint.proceed();
    cache.put(genericIdentifier, obj);
  }
  return obj;
}

Everytime a cachable method is executed we’ll first have a look at the cache. If there’s a cache hit we’ll immediately return the object. If there’s no such object in the cache, we’ll call the cachable method, put the returned object in the cache and finally return the object.

The genericIdentifier is a string consisting of the package-, class- and method-name and the supplied arguments. For a method named foo from a class bar inside a package called baz this might result in:

"baz.bar.foo-Integer-42"

The method foo takes one argument and at the time of this execution it was 42. This way we’ll only return objects from the cache if this generic identifier matches.

Using the aspect

All we have to do is to use the @Cachable annotation. Have a look at it:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Cachable {}

It can be used with any method that returns something:

@Cachable
public BigObject getObject(final int param) {
  return new BigObject(param);
}

The first time this method is called we’ll store the object in the cache. If it’s called again with the same parameter we’ll return the object from the cache.

Conclusion

Implementing a cache is simple and so is using it with AspectJ. I presented a straightforward way to speed up any application that deals with big objects which take a long time to load. All you have to do is to use the @Cachable annotation along with the aspect. Implementing another cache in the aspect should be simple, too.

The Eclipse project with the sample code for this post can be downloaded as tar.gz or zip; make sure to install the AspectJ Development Tools. You can browse the code online here.

Classic singleton pattern

The traditional way to implement a singleton consists of a private constructor, a static final field that holds the instance of the class and a getInstance method that returns this instance. In Java this looks like this:

public class Singleton {
  private static final Singleton singleton = new Singleton();
 
  private Singleton() {}
 
  public static Singleton getInstance() {
    return singleton;
  }
}

This gets really annoying if you’ve got this code more than once in your application. So lets have a look at an aspect that resembles this functionality.

Implementing the aspect

If you’ve got more than one singleton in your application you may think of a singleton as a crosscutting concern. Consequently, you’ll write an aspect that intercepts calls to the constructor of the singleton class and instead of creating a new instance every time you’ll return the instance that was created at the very fist call to the constructor.

The logic for this idea can be expressed with the following code fragment:

Map<Class<?>, Object> singletons;
...
Class<?> singletonClass = joinPoint.getSignature().getDeclaringType();
Object singletonObject = this.singletons.get(singletonClass);
if (singletonObject == null) {
  singletonObject = joinPoint.proceed();
  this.singletons.put(singletonClass, singletonObject);
}
return singletonObject;

We have a map that holds references to all instances of our singleton classes. The method that intercepts the calls to the constructor of a given class stores a reference to the created instance in the map and returns that instance on the following calls to the constructor of the same class.

So, you can do the following in the code and will get references to the same instance of the class:

Singleton s1 = new Singleton();
Singleton s2 = new Singleton();
// s1 == s2

All that’s left to do, is to define a pointcut and to remove the boilerplate code from the singleton class. A pointcut can look like this:

@Pointcut("call(*.SingletonAop.new(..))")
protected void singletons() {}

Conclusion

We implemented a solution for the singleton pattern with AspectJ 5. The used approach caches the instances of the singleton classes and returns the cached ones once the constructor has been called for the first time. Note: to simplify matters we left out thread safety.

Although this solution is somehow elegant and may be useful to clean up some code in a legacy system, we should consider the following points:

Can we use a dependency injection framework?

Spring uses singletons by default and with Guice you can mark singletons with the @Singleton annotation. So, we might want to choose one of these frameworks instead of implementing this functionality on our own.

Java skill of the team?

The presented implementation should be well documented, because nothing would be more irritating than a novice developer in your team who doesn’t know about this magic behind the scenes and relies on different instances of the singleton class (“I thought new would be doing…”).

There are other solutions available to this problem. So, I wouldn’t recommend to implement this kind of caching with AspectJ.

If you’d like to check out the sample code that accompanies this post, you can download the Eclipse project as tar.gz or zip; make sure to install the AspectJ Development Tools. You can browse the code online here.

How to profile methods

Writing an aspect that adds advice to the methods you’d like to profile is as easy as this. You define a pointcut that matches the methods you’d like to monitor and define an around advice that calculates the time it took the method to execute. Have a look at the following piece of code:

@Around("profile()")
public void aroundInterestingMethods(ProceedingJoinPoint thisJoinPoint)
            throws Throwable {
  final long start, end;
  start = System.nanoTime();
  thisJoinPoint.proceed();
  end = System.nanoTime();
  // calculate time: (end - start) / 1000) / 1000;
}

All that’s left to do is to define a pointcut named profile, that matches the methods you’d like to monitor. Since the pointcut will be variable, I wrote an abstract aspect that can be subclassed for different monitoring needs.

In a subclass you would implement the profile method like so, if you’d like to monitor all methods named run:

@Pointcut("execution(* *.*.run())")
protected void profile() {}

What about the results?

If you would run the sample code, you could see this:

    Results for Runner.run (1002ms)
    Method: TaskB.run() took 600ms (60.0%)
    Method: TaskA.run() took 400ms (40.0%)

Once the run method of the Runner class comes to an end, we can see these statistics, produced by the afterTopLevelMethod method from the profiling aspect.

Based on this textual results it would be pretty easy to produce a graphical representation with gnuplot or JFreeChart. I could imagine a picture like this:

Although this looks very simple, a picture might be easier to absorb if there would be more methods.

Conclusion

As we’ve seen, profiling with AspectJ can be implemented straight forward. My simple example showed how to monitor certain methods and calculate the their execution time. The authors of this paper point us to some more things we might want to profile, e.g. heap space. Although I haven’t tried it yet, it should be possible to implement this too.

• implement this AbstractLoggingAspect and define the methods you’d like to monitor
• declare advice before, after or around the logging pointcut and println your logging to stdout.

Once you’re finished with this you’ve got logging in your application without touching the original code. We’ll have a look at the details in the next sections.

If you’d like to check out the code that accompanies this post you can download the Eclipse project as tar.gz or zip; make sure to install the AspectJ Development Tools. You can browse the code online here.

The logging template

The abstract aspect I wrote was inspired by the IndentedLogging aspect from the book AspectJ in Action by Ramnivas Laddad. My AbstractLoggingAspect class does the following:

• indents logging and
• supplies an abstract method.

The abstract method needs to be implemented by an aspect, that defines things that should be monitored. The advice for this logging method should just print messages to stdout with System.out’s println – this way they’re getting indented.

Implementing the aspect

A subclass of AbstractLoggingAspect implements the logging method and uses a pointcut to define join points that should be monitored. I wrote one for the sample code like so:

@Pointcut("(execution(* *.*doEverything()) ||
            execution(* *.*doSomething())) &&
           !within(*Test)")
protected void logging() {}

Every execution of the methods doEverything and doSomething that isn’t inside a test class will be matched. After that we can write an around advice to print some logging information. If you would run the sample code it would print the following:

Entering [MyLogic.doEverything()]
  Doing everything...
  Entering [A.doSomething()]
    Doing : A
  Leaving  [A.doSomething()]
  Entering [B.doSomething()]
    Doing : B
  Leaving  [B.doSomething()]
Leaving  [MyLogic.doEverything()]

The calls to the different methods are logged and indented.

Conclusion

Adding fancy indented logging to your application with AspectJ is very easy: subclass the AbstractLoggingAspect and customize the logging to your needs. After that you’ve logging in your application without changing the original code – all the work gets done inside the aspects.

I think this should change, so I put together some sensible arguments for AOP. After that we’ll have a quick look at AspectJ. I’d like to emphasize the word quick here, because there’s a lot of information out there. If you’d like to read more about AOP, you may check out the following links:

• AspectJ Project homepage
• AspectWerkz at the Codehaus
• AWbench is a benchmark of different AOP implementations
• The AspectJ^TM 5 Developer’s Notebook
• an IBM article introducing AspectJ 5
• don’t confuse with Abject-Oriented Programming
• do a Google search

Why AOP?

Suppose you’re building a web application. The more you code the more features you’d like to add. More features translate to more concerns in your application: you might want to add logging, security and persistence just to name a few. These concerns are crosscutting concerns because you need to add them in various places in your application. Of course you’ll create one single class (OOP-style) that’ll handle logging but this class has to be called in a lot of different places throughout your application. The same thing holds true for the other concerns and you probably end up with a system like this:

Suddenly your excellently organized code gets polluted with totally different aspects of the desired features. As more and more aspects are scattered over your code, it’ll will be harder to read and you’ll have a hard time figuring out where your business logic is.

Luckily, you can avoid this if you reorganize the different aspects into separate classes: there’ll be one for logging, security, persistence and so on. This keeps your business logic code concise and to the point. Furthermore it’ll be easier for you if you’d like to change the behavior of these concerns – just change the corresponding aspects. This leads to a system with aspects in different modules separated from the business logic code:

How to AOP?

The rule of thumb is this: if you have to copy code into different modules of your application over and over again, consider writing an aspect instead, because you might be working on a crosscutting concern. More often than not you already have a separate class and calls on various locations in the code to methods of that class. Instead of calling these methods everywhere in your code, you can put them into an aspect.

Think of a class that handles a sessions for you; whatever a session might be (e.g. one for a database). Now there are some methods that need a session object and the boilerplate code in the methods always looks like this:

public void someMethod(final Session session) {
  try {
    session.startSession();
    // do something
} finally {
  session.endSession();
}

So you’ll have this try-finally block, startSession() and endSession() everywhere in your code where you need to handle a session. A much cleaner solution would be the following:

public void someMethod(final Session session) {
    // do something
}

and an aspect like this:

public void aroundSomeMethod(final ProceedingJoinPoint thisJoinPoint,
                             final Session session) throws Throwable {
  try {
    session.startSession();
    thisJoinPoint.proceed();
  } finally {
    session.endSession();
  }
}

Now you have a single method (aroundSomeMethod()) where you can configure the calls to a session object and all the other methods (e.g. someMethod()) that need a session object will remain small and will contain only business logic.

I wrote a simple example for this and you can browse the code here; have a look at the example package and the Runner class. The code demonstrates how to get rid of boilerplate code and do things the AOP way:

What do you think when looking at the picture? Inversion of control? I think that AOP can be very helpful when designing an application with IoC in mind.

Quick look at AspectJ

I wrote a very simple Hello World application with two aspects: AspectJAspect and AspectJAnnotation. While AspectJ at first introduced a Java-like language to write aspects, with AspectJ 5 it’s possible to write aspects as classes with special annotations: the two aspects I wrote demonstrate both approaches. Second, there’s the code for the example I explained in the previous section.

You can download the Eclipse project as tar.gz or zip or browse the code here. If you’d like to run the project in Eclipse, make sure that you’ve got the AspectJ Development Tools installed.

All the code does is introducing a Main class that has a helloWorld() method. The two aspects AspectJAspect and AspectJAnnotation print some information before and after the helloWorld() method and around the constructor and main() method of the Main class.

Conclusion

Although the example code doesn’t do very much, it showcases some important things:

• AspectJ integrates seamlessly into Maven and Eclipse. That are the most important points to check: if something doesn’t work with Maven or Eclipse, it’s probably not worth using anyway. This isn’t true for things that are really cool – if it’s really cool I might be willing to do some cumbersome hacks to us it.
• AspectJ 5 is very easy to use: some annotations here and there – that’s it. This is a good thing because this way it should be much easier to promote AOP. There are still some weird error messages, but… shush, you don’t have to mention that .

Because AOP isn’t common knowledge yet, encourage other programmers to read up on AOP; hand them a copy of AspectJ in Action. If you can’t convince other people to use AOP, use it to increase your own productivity, i.e. start using it for logging, tracing or coding policy enforcement.