Whether you like it or not, annotations are making there way into the Java language. The EJB expert group has identified the potential gain annotations could bring to EJBs by devising new ways of developing enterprise beans using one single file that would contain all the necessary information needed by the container to make the bean work properly. The goal of the new spec is to simplify the development of EJBs by eliminating the hassle of explicitely having to create home and component interfaces as well as deployment descriptors. While this somehow makes sense, I have already exposed my views on the subject in a previous blog entry.

Today, Cédric Beust proposes a mechanism for allowing future developers to override annotations at deployment time. In my opinion, the idea is worth spending some time on it. What puzzles me somewhat is that Cédric proposes to specify all the overriding behavior in... an ad-hoc XML file that could be loaded dynamically by some AnnotationOverrider. Sorry but this smells big time!!

I'm aware that overriding annotations would only have to be done in few special cases and that not everybody would have to use that mechanism, but having to specify the overriding mechanism in an XML file would somehow defeat one the primary goals for which annotations have been brought up in the first place, literally "to replace the various ad hoc metadata facilities in use today".

What I see coming is that people will start consuming annotations as they consume normal Java code and their source files will end up being incredibly cluttered with both code and metadata, which I legitimately called the "annotation hell syndrom". This will inevitably lead to unmaintainable source files, exactly what the solution was originally supposed to prevent from happening.

Although not always ideal, the original idea behind deployment descriptors was viable as they made it easier to assemble/deploy/redeploy enterprise applications without having to rebuild the whole code base. In the future, we will have to rebuild/deploy the whole stuff whenever someone changes metadata since annotations will be tightly coupled with the code they describe. I don't reject annotations, I think they can be very powerful, I'm just skeptical about whether we will be able to use them correctly or not.

Again, I think that tool builders have some homework to do in order to provide developers with cutting-edge tools that hide much of the complexity related to the issues I mentioned. If tool builders fail to create new tools that help developers manage this complexity, we will have a hard time developing complex applications in the future.