Wednesday, October 24, 2007

Annotations - Is it a compromise between convenience and flexibility

Annotations have been a craze for sometime now. I heard it the first time when I went through an article on EJB 3.0. As soon as I saw it, I was reminded of Weblogic's xdoclet method of allowing the deployment descriptor attributes to be defined in the code itself. And I did not like it at all. I still don't like it much.

I probably am from the old school but I felt that by moving these back to the code, I lose the flexibility the concept got me at the first place. I always had to change the source code if had to tweek any of these attributes. Did not feel right. But I left it at that.

Then I came across hibernate annotations and used them in a project. Was very handy and friendly. I did not have to go open up another file to define the mappings. Cool... I felt as a developer. Still that earlier thought did not go away. But I was able to convince myself that these mapping probably wont have to change much once it is done. Changing table column names once in production anyway would have been taboo...

Today however I heard about Spring 2.5 coming up with annotation based DI and the question popped up again. If I use annotation and declare my dependency right on the class source code, am I not coupling it with the concrete dependency... Is it defeating the main purpose of DI I was not sure...

Can't better IDEs solve the xml menace instead of going for annotations? It is a thought. The industry will decide...