Adopting AspectJ

I think this has to be one of the more clever approaches to a presentation like this that I've seen. The speaker, Adrian Colyer, could have just gotten up there and tried to show off his tool - AspectJ, apparently the leading AOP framework. Instead, he did something that I thought was really, really cool. He structured his presentation in buckets according to your place on the adoption curve. The whole idea was to show you what baby steps you could take with AspectJ early on with minimal risk/investment, and then ultimately to show you some of the things it can do for designing business logic in your application.

I've seen several presentations on some of these technologies now, and this was one of the most effective ones I think I've ever seen. It was especially great in contrast to the JBoss presentation on their AOP tool, which I did not care for at all. Anyway, on to the content...

The first use-case he presented for AspectJ AOP was to create aspects for enforcement and exploration of your own development code. You can do very simple things like capturing diagnostic information from the application server (session size, whether you are releasing connections in a timely enough fashion, how you're using threads, etc).

The best example was the use of AspectJ's declare warning mechanism. You can create an aspect to throw compiler warnings based on your own rules. The sample code he showed us was detecting and reporting all uses of System.out.println in his application. A more powerful example was using this to provide architecture enforcement. He set up aspects to ensure that calls to his UI components were only coming from appropriate classes in his UI subpackage. He also set up aspects to warn against references to implementation classes where APIs should be used. I cannot describe how cool this was to see... I can't begin to count all of the different ways we could use this kind of technology.

I remember having trouble with deciding how/if I should make certain classes in my NILM Java API package-scoped or leave them public (for future XML/Cache API extensions to use) but somehow move them into a subpackage that I could document as not for public use. Obviously this would only work on compile time, but the idea would have addressed my fundamental problem. I could have published an aspect library and embedded it in my shared component that would warn any client that certain use patterns are not supported. Again, really cool stuff.

This provided a good foot-in-the-door for people looking to get experience with AOP development. The enforcement/exploration stuff is pretty lightweight, disposable, and incredibly valuable during active development. The next milestone of use-cases he addressed was taking the next step into infrastructure utilities in your code. Before, AspectJ was just a compile-time dependency. Now these examples would be run-time dependencies on the framework.

He provided a long list of examples for types of services that could be implemented by aspects to remove the redundant code from the actual business logic. Some of these examples include tracing (reporting in/out in methods and printing out parameter values), logging, exception handling, monitoring statistics, transactions, session management, etc.

So one concrete example of this idea would be to provide an aspect that would intercept any exception that somehow made its way into the UI components of his application. The Throwable would be intercepted and logged, and then the message from the exception would be presented in a dialog box to the user, much more elegant and graceful than a stack trace dump.

Even better than that, he introduced an example of using AspectJ aspects in conjunction with JMX (Java Management Extensions). Here, you can take a simple POJO and apply an aspect that will register the instance with a JMX server. Then, through the JMX web screens (and this really is more about WOW-ing with JMX than AOP), you can manipulate the state of your object and invoke methods interactively. This is obviously not something we'd want to do a whole lot of. But these examples really helped me understand the practicality of these so-called "cross-cutting concerns." It's code that potentially you'd have to write over and over and over again.

One last example in this category of usage, he showed how to abstract away most of the configuration code for persistence frameworks like Hibernate. He provided an aspect that handles all of the session and transaction details, leaving the query method much cleaner and easier to understand than it would have otherwise been. I'm having a hard time wording this correctly, but the sample code made a lot of sense... Basically he moved the Hibernate-specific API calls into the aspect, leaving the code with the actual business logic for the query execution clean and clear. GOOD stuff....

At this point, he had used almost all of his time, so he quickly went through the final two steps in the adoption path for AspectJ: business/core aspects, and aspects in the design. An example of business aspects would be to intercept any object about to persist against the database and make sure it passes validation logic (scrubbing your data). As for the "aspects in design" bucket, he didn't say much about this, but he offered a good analogy to help understand AOP. He said that OO is essentially nouns and verbs, but that AO provides adjectives and adverbs. This is actually a pretty useful description, and I feel like I definitely understand the use cases for AOP much better now.

He concluded with what I thought was a very appropriate step back, asking us to make sure that aspects are actually a good fit before we just start randomly adopting AspectJ just because it's cool. His rules for defining what makes a good aspect are as follows:

• do the parts all belong together?
• does the aspect reduce coupling amongst the modules in the design?
• will the code be easier to maintain or evolve with or without it?
• does the aspect clarify component interactions or obscure them?
• is the program easier to understand?

I can't say when I consider it likely that I would use AspectJ or really any AOP code in production-bound projects anytime soon. However, I'm excited to see what using a little AOP in my development code can do for me.