AOP with AspectJ

Recently I read AspectJ in Action by Ramnivas Laddad for the second time. Since I first read the book about three years ago, I haven’t used AspectJ in a real project yet. Generally speaking I think that AOP techniques aren’t applied that often in practice.

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
• 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 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.

If you need step by step instructions – with lots of screenshots – how to setup all this using Eclipse with all that’s necessary to get it running I definitely recommend checking out this great tutorial.

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.