Annotations in POJO – a boon or a curse?

The purpose of annotations have been well put forward with the recent upgradation of EJB to EJB 3.0 and also in the web services field by JAX-WS. Annotations help in reducing the learning curve associated with these specifications by avoiding the need to learn the deployment descriptors which are necessary to properly deploy an EJB or a JAX-WS web service respectively.

Annotations – a boon or a curse?
Due to the above situation, the influence on the usage of annotations is steadily rising. It is but natural that programmers would try to do their work quickly without having to waste the time in learning the XML Schema’s required for deployment. Annotations are purposely aimed at this programmer’s dilemma. In fact when I was working in JAX RPC, I used to think as to when I would get a tool to code those ugly descriptors in an easier fashion. With annotation based web services creation in JAX-WS, half of my work is done when I put them in the POJO itself.

All of this can be attributed as a boon to the presence of annotations. But the point of worry is, whether all those annotations which are pushed in the POJO to do work in an easier manner are really worthwhile? What has happened to the age old technique wherein a POJO by nature would remain a POJO such that it could be used wherever required without having to change the code in future.

Degradation of POJO’s
You have to remember that the ugly deployment descriptors which we swear at are the actual components in an application which give us the power of code flexibility and code reuse. They are here to make changes and configurations during runtime without having to touch the class files. But with the presence of annotations I fear that people would become slaves to them and all of the configuration code would be pushed into the POJO‘s.

According to the POJO definition, a POJO doesn’t remain a POJO anymore, once it relies on any kind of API or framework which makes it dependent on an environment other than the JVM. According to Wikipedia, a POJO should not have to,

  1. extend prespecified classes
  2. implement prespecified interfaces
  3. contain prespecified annotations

An annotation may not change a POJO‘s behavior but it makes it dependent on the environment. If you try to compile a POJO in your JVM it won’t get compiled. This is because an annotation also requires an environment to get translated into its specific configuration file. So the question is how would you attribute a normal POJO behavior to the one with annotations. They are not the same.

The problem in using Annotations
A framework which makes use of the normal POJO without changing them would be a truly flexible framework. If we try to compare EJB 3.0 with the Spring framework we would immediately come to know the difference. In EJB 3.0 you declare a bean with an annotation in a POJO whereas in a Spring framework an XML file is used for weaving the POJO‘s to make a flow control or give them special functionalities.

Nathan has stated in his tech blog,

In conclusion, annotated objects, for the simple reason that you can’t compile them without needing external resources, are not truly “Plain Ordinary Java Objects.” They have been made un-plain and un-ordinary by their annotations.

This is the same point that I am trying to make through the above comparison that annotations might be great but they make a dependency in your POJO functionalities. The rule of thumb in the application development domain is to always keep the business functionality away from the technicalities of the framework or any of the 3rd party API’s. And annotations do the exact opposite. How can one guarantee that the annotated POJO‘s would be useful in another container which does not have the annotation related classes?

A cause for worry
Even though the above problem exists we cannot give away with annotations, because we don’t have time time enough to learn the humongous amount of XML schema’s to make our configurations. In this case we would either require a lightweight framework which does not heavily rely on XML descriptors like Spring as compared with those in EJB 2.1. Or the round about manner is the use the annotation only in those classes where the special functionality is to be attributed to the POJO. This is a similar to following patterns such as the factory or the decorator pattern.

But who would guarantee that all the programmers would be following such methods? Not everyone understands the depth of technology. Normally people work with the things taught to them . But if they are only taught annotations as per the current trends, it wouldn’t be much late before our age old methods to keep POJO‘s as POJO would fail because with annotations, they would become dependent and later we would need something which would once again make them flexible as earlier. Doesn’t it seem like we are reinventing the wheel?

4 thoughts on “Annotations in POJO – a boon or a curse?

  1. Very well put Nitin,

    Quite obviously, I agree completely.

    I would like to ask you to have a look at the cajo project. It allows remote POJOs to work together without any modification; and most importantly, it uses neither XML, nor annotations.

    As a result, it is exceedingly easy to use, and is also completely free.

    John Catherino
    Project Lead
    The cajo project
    https://cajo.dev.java.net

  2. I have had the same concerns regarding Annotations. I think that this concern could be addressed by allowing runtime modification and creation of Annotations with RUNTIME retention. Having the ability to modify or create Annotations would make it possible to use Annotations with XML configuration descriptors.

  3. Nitin wrote “How can one guarantee that the annotated POJO’s would be useful in another container which does not have the annotation related classes?”. Can someone answer this: How can one guarantee that the injected POJO’s into the objects via Spring’s IOC would be useful in another container which does not have the Spring framework related classes?

Leave a Reply

Your email address will not be published. Required fields are marked *