AOP

From APIDesign

Current revision

Bytecode patching

There used to be a time when people went nuts on hearing the phrase bytecode manipulation. That's no longer the case. People aren't afraid to execute bytecode different to that produced by the Java compiler anymore. However, if you tell them to go directly into the .class file and manipulate the bits, the fear returns. Why is that? I believe this is due to AOP. AOP makes bytecode changes normal, without requiring understanding of the class file format. In fact, AOP can be seen as a high level language for bytecode manipulation. It is not as powerful as making changes to the .class file directly, yet it is approachable to the masses and generally understandable. This perfectly illustrates the principle that good abstractions make everything more usable. The principle is true in the world of bytecode manipulation as well as in that of API design.

Hard too use

If direct manipulation of bytecode is like writing something in assembly language, then AOP is like programming in C. Quite easier, but still not supporting cluelessness enough. It is fine I can write an aspect with pointcut that executes all methods in my classes asynchronously, however to do that I need to understand a lot. I need to know how to declare a pointcut, how to describe what exactly it shall match and also how my aspect gets merged into the affected object. Quite a lot of knowledge. There has to be something simpler, if this kind of programming shall be used by masses!

Annotations

What can be simpler? Of course, annotations (they are solution for everything these days, as this is TheYearOfAnnotations2009). If I want to apply the asynchronous aspect to my class, I shall be able to write just:

@Asynchronous
class MyClass {
   public void oneMethod() { ... }
   public void sndMethod() { ... }
}

and the annotation shall do the rest. Why is this simpler? First of all everything remains in one place, one does not need to switch to .aspect file and use different language. Code completion works for annotations. Annotations can have parameters. Probably (with the help of AnnotationProcessors) one does not need any special compiler. Using JavaC is enough. In short, this is the clueless solution end users want. Actually this is also solution taken by some projects (Lombok comes to my mind).

This is fine enough for end users, however try to write your own annotation! Hard, quite hard. You do not need to directly manipulate with bytecode, but you need to manipulate with abstract syntax trees used by compiler. That is not much simpler and definitely not clueless.

Harmony

Of course, there is much more people using these annotations than writing their own. Still writing own shall be simplified. How? Via AOP! If there was an easy way to connect annotation with an aspect (for example .aspect file), one could get benefits of both worlds - end users would have all the comfort of annotations and providers could use higher level language to define what an annotation is supposed to mean. This is well balanced path that maximizes cluelessness of all parties. As such it fully deserves Good Technology name. This is the style majority of us will code in short future. Old AOP is dead, long live annotation based AOP!

I have seen a demonstration of PostSharp for .Net recently. It provides this kind of perfect harmony between users (via annotations) and aspect developers. When I saw it I was amazed. This is how AOP shall look like! Does anyone knows if there actually is some framework in Java that works this way?

<comments/>

AspectJ

There is a pretty good explanation by btilford in the comments section showing that AspectJ can be used to define an annotation and provide an aspect that processes methods annotated by such annotation. So the only thing I am missing is integration with AnnotationProcessors - e.g. just by running compiler, also process these annotations. This does not seem to be possible now, but as Nicolas Dumoulin explains with maven it is very easy to setup a project to use aspects. Thus we are back where we started: Java is again ahead of any other competition.