Annotation Dilema

Annotations and annotation processing are great new methods to insert configuration directly into source code. One immediate result of annotations introduced in Java 5 is the elimination of XML configuration. XML configuration does satisfy some situations for definitions and configuration but leads can make the application more complex, harder to maintain, and take longer to develop. Annotations can be directly inserted into the application code itself as opposed to externally describing the data from another file. The benefits are extrodinary. The java objects are easier to read and faster to write. It is easier to determine behavior while also having less code.

The annotated java class utilized by a developer that is external to the framework requirements or annotation proccesor will not be considered a POJO from that perspective. The object clearly looses its simplicity and can be aguably tightly coupled with the annotation framework.

In an example of a POJO, the object may need to be configured for two different frameworks. In a traditional approach, XML or a properties file would define the configuration for the object. Using Annotations, the Pojo in essense tightly couples the object with the framwork (or configuration).

Lets take a look at a simple Customer POJO java object.

public class Customer {
  private Integer id;
  private String firstName;
  private String lastName;
 
  // getters and setters
}

Now with JPA applied to the POJO it takes on a new appearence.

@Entity 
public Customer class {
 
  @Id private Integer id;
  @Column(name="first_name") private String firstName;
  @Column(name="last_name") private String lastName;
 
  public Integer getId() { return id; } 
  public void setId(Integer id) { this.id = id; }
 
  // more getter setters
  // ...
}

The big movement right now is to develop code in this manner. This is very simplistic and easy to understand. Much easier than creating an XML file to define the database mappings. However this does challenge the definition of 'POJO'.

Two main problems with annotation based configuration put into a pojo.
1) If the pojo is utilized by a developer in an unrelated part of the application
2) If another framework needs to annotate the POJO causing disorganization and chaos in the file.

If we examine the first situation closer, we can see that the once loosely coupled object, now has annotations all throughout it. Another developer utilizing this object will see all of this unneccessary annotation. Is it may not be a huge problem, but the coupling becomes tighter and design begins to suffer.

The second point occurs when an object is needed to be annotated by a completely seperate framework. The pojo could potentially be annotated by 2 or more different frameworks. It leads one to believe that the best course of action in this situation is to stick with an XML file/properties file.

The goal of a framework is less coding for the developer while still maintaining loose coupling with the specific business logic of the application. It is up to the developers to walk the fine line between abstraction and framework coupling with business logic. The line itself needs to be determined where best to be placed to suit the needs of the business.

Real world Dilema

Lets take a look again at the simple Customer object. THis time, I will be adding annotation definitions from two different frameworks. One is JPA annotations and the other is JAXB annotations. As you see below, this original POJO now has added complexity with several different annotations throughout.

@Entity 
@XmlRootElement
public Customer class {
 
  @Id 
  @XmlAttribute("id") 
  private Integer id;
 
  @Column(name="first_name") 
  @XmlAttribute("first")
  private String firstName;
 
  @Column(name="last_name") 
  @XmlAttribute("last")
  private String lastName;
 
  public Integer getId() { return id; } 
  public void setId(Integer id) { this.id = id; }
 
  // more getter setters
  // ...
}

Other annotations such as web services, DWR, Spring, and JSR250 just to name a few can also be added to this file to make it even more complex.

This should not deter developers from choosing the annotation path but to be aware of issues and limitations.