Greg Hamilton blogged about AOP: Madness and Sanity talking about where and where not to use AOP and I nearly threw up, figuratively speaking, of course. Primary AOP is a concept that wants to relive the developer from some of the constraints of traditional OOP. I say traditionally here because J2EE is some sort of a AOP light framework already using some of the AOP concepts even though it is not really AOP by any stretch of imagination. In addition he said that the AOP allows the add code in a cross-cutting concerns manner but I think that is not the most important feature of AOP even though it is the best selling point because it can be illustrated quite easily. For me the most important feature of AOP is what I call "feature merge" or "loose integration" meaning that I can take two or more components and massage them in a way where they can interact together without actually changing their code base. I think that is actually what Greg's thinks is the bad part of AOP and he said that only Container based AOP is good because it is well defined even though I know too many J2EE developers who do not even understand the basic concept of J2EE transactions good enough to work as a J2EE developer. But Container base AOP is somewhat weak, very limited in its scope (not everything is an EJB in Java) and very rigid. On the other hand I am quite surprised that after the past where Sun said that JBoss will not pass the certification because it allows the user to change the way J2EE framework works by changing the interceptors I now see that interceptors are part of EJB3 specification. So I guess that JBoss has prevailed with its vision of a dynamic J2EE.

If I am going to use AOP then I need a very compelling reason and J2EE is not going to cut it. Therefore I crafted the title to indicate that AOP is not here to be squeezed into a container but to free us from the constraints of OOP and therefore we have to free AOP from any container. If you want to be on the safe side and do not want to explore the final frontiers of software development then AOP is not for you. AOP is difficult, hard to debug and sometimes risky to use but you can gain a lot from it: no pain, no gain. AOP is not here (at least currently) for the weak but for the brave who dares to push the limits to make things easier. I can promise you that you will be frustrated quite a lot and you will fail several times until something is working as expected. But anyone how made the transition from procedural programming to OOP or hierarchical to relational DBs can hopefully use his/her experience to understand the difficulties in the transition from OOP to AOP.

Oh yeah, annotation has to end up here because it is so great, isn't it !?! Annotation in EJB3 makes the whole thing only complexer because I now need a tool to know what is a remote interface, an ejb and what the actual JNDI name is because it is buried insight the bytecode rather than to have it explicitly insight an XML file. Annotations are just a way to tag elements in a class, nothing more and nothing less and so do not have anything to do with AOP. Most AOP systems like AspectJ or JBoss AOP provide support for annotations to declare aspects, pointcuts etc but especially for AOP I prefer to keep the definition outside of the source code because I want to be able to change it without rebuilding the project.

Any paradigm shift is painful because we have to give up our comfort zone in order to conquer new ground but it is not done by restriction. Christopher Columbus would not have found America if he did believe into world's view of that time and so sanity can be the madness of human evolution. Don't get me wrong if you are happy with you have and you want to code Java for the rest of your life then be my guest but do not expect that the world just stops spinning because of you.

-Andy