Andreas Schaefer's Blog

March 2006 Archives

AOP: The Sanity's Madness

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

JDK Community: Dream or Reality

Yesterday Ray Gan blogged about the JDK Community listing some of the facts about the Peabody project. If you never heard about that project then you are not alone and I only now about it because Joshua Marinacci gave a presentation about it at the LA-JUG last year. But even without knowing about the Peabody project is became a JDK contributor last year in November and started to code a fix for bug #6212146 which I has sent to Sun for a review by the end of November. I got an initial confirmation that the bug fix was received but that was all I heard from Sun for a long time. Then January 2006 Ray blogged about the state of JDK Community and I responded complaining about that I got no feedback from Sun about my patch. A little bit later I finally got an email from Michael McMahon (1/31) that they started to look into the patch. I also spoke with Matt Ingenthron from Sun about it and he tried to find out what is going on and to bring some more transparency into the JDB Community. Needless to say that I did not get any feedback since then

As a good citizen I took the time yesterday to fill out the survey and to pour in some of my thoughts and complaints. Now I take the opportunity of this blog to share my thoughts on the JDK Community to a broader audience. As an active open-source developer I know both sides of the aisle, the one that runs a project and the one that provides patches. But in order to keep a community alive and active the project team must react to input from the community and give feedback without being pushed all the time. Especially in this case where Sun is a huge company and Java is a big project getting a community project up an running is difficult. Nevertheless as a contributor I think I have the right that Sun not only receives the work from the contributors but also gives something in return and the very basic would be feedback on the progress of a patch. Unfortunately a regular contributor cannot get the CTS in order to make sure that one's but fixes does not break Java and so I cannot test it thoroughly. This means a contributor has to wait until Sun provides feedback to improve the patch. As a contributor I do not want that my patch is swallowed by a black hole and one day it makes it into the JDK or not.

I suggested a few improvements and most prominently I would love to have a contract person within Sun with whom I can work on the patch to make it into the JDK. He/she does not have to be the developer that test or improve the patch but he/she must be able to answer questions and to provide feedback. I do not need contests, awards or public recognition but I would love to have my name as author in the Java code when the patch makes it into the JDK. In addition I would love to have forum(s) for contributors where they can discuss items with the Sun's Java developers and also a way to track which contributor is working on which bug so that I can avoid working on a bug that someone else is already working on. Maybe it would be a good idea to invite some contributors into an expert group to improve the JDK Community process.

Currently I am not working on any patches for the JDK because I want to ensure that my time spent on this is spent worthwhile and so I want to see if it makes it into the JDK or not and in case it fails I want to know why. That said I still hope that Sun can improve the JDK Community because I would love to work on the JDK in the future. So far I am disappointed about the process and also think that this is why there are not as many contributions as one would expect (see the JDK Community List).

-Andy

This work is licensed under a Creative Commons License.