JT’s Blog

Grails – The Cure for Annotation Hell

Posted by jt - 25/11/09 at 08:11 am

Last night I attended a meeting with the Sarasota Java Users group. It was an interesting presentation on client side technologies for J2EE developers.  The presenter took the typical Hibernate/Spring stack and demonstrated how to apply RESTful web services with dojo to create a Web 2.0 application.

We reviewed a simple Hibernate data model which used JPA annotations.  After using GORM for the last few months, the JPA entity class was painful to look at.  I forgot how ugly all those annotations are! Yuk.  The presenter commented that annotations are so much easy to work with than than XML and were the way of the future.

The first part I certainly agree with.  I remember trying Hibernate 2.0 and entering the world of XML hell.  Being fluent in SQL, I quickly got frustrated with all the configuration I had to do with Hibernate.  My productivity was dying in XML hell.  It was easier just to use a well formed DAO layer and straight JDBC.  I walked away from Hibernate 2.0 feeling it was a tool for Java developers that didn’t know SQL.

Enter Java 5, annotations, and JPA.  Compared to the XML Hell of Hibernate 2.0, this was a breath of fresh air.  It is far easier to work with annotations than it is to work with a separate XML file.  I used to feel annotations were a wonderful solution to XML Hell.  But now that I’ve been working with Grails, I need to ask are we just replacing XML Hell with Annotation Hell?  Are we just moving from something that was really awful, to something that is not as awful?

Annotations, annotations, annotations.  Annotations everywhere!  Seeing the JPA entity class showed me how spoiled I am becoming with GORM.  The Java class was all cluttered up with annotations.  Like any good modern Java developer, the presenter leveraged the Spring validation framework.  Certainly a modern best practice, but again, there is another Java class littered with annotations. In GORM, this class would not even exist.  Validations are cooked right into the domain class.  The Spring validation is still there.  But in GORM it’s wired in with Groovy magic.  As a developer in GORM, I am left with a much cleaner representation of an entity.  The definition of my entity is scattered across multiple class files, it is in one.

The presenter then turned to creating RESTful web services.  This was fairly interesting, because he leveraged the Jersey framework.  Prior to last night, I was unfamiliar with Jersey.  But again, we have another Java class littered with annotations.  Jersey is using configuration instead of convention, while Grails gracefully uses convention over configuration.  In Jersey, you use the @Path annotation to define the url path.  Contrasted to Grails, by convention you automatically get controller name / method name for use in the URL path.  No need to configure it via an annotation.  Of course, if I need to override this, I can.  But 95% of the time, the Grails convention will be fine.

Annotations are certainly in vogue right now.  Its a new toy in the Java community.  After using the common sense approach in Grails, I ponder if the current adoption of annotations is bordering on abuse.  Are annotations just a band aid approach to serving a need that  dynamically typed languages such as Groovy fulfill?  2 or 3 years from now, will the Java community be reminiscing about the days of annotations?

This entry was posted on Wednesday, November 25th, 2009 at 8:14 am and is filed under Uncategorized. The entry is tagged under GORM, Grails. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.