Skip to main content

POJO - Complex New Perl Classes

Posted by kirillcool on April 2, 2005 at 8:29 AM PST

Over the last year the term POJO
has enjoyed an enormous success in the Java community. One of the major reasons for this being, of
course, introduction of
annotations
in JDK 5.0. The new version of
EJB
shows us the promised land where no home or remote interface step,
JAXB 2.0 works exclusively with
annotations, and there is even a whole
JSR that aims to standardize common
annotations in Java.

But i wonder how exactly a Java class seasoned with assorted annotations qualifies as POJO.
Let's stop for a minute and analyze the abbreviation itself (well, i know that it sounds very
sexy, and has a lot of connotations, no pun intended).

  • The P stands for plain. A java class with annotations is quite far from being plain.
    The annotations can be quite complex (take a look at the JAXB 2.0 generated classes).

  • The O stands for old. Apart from the obvious (that the annotations are only part of JDK 5.0),
    i don't see many examples of new JSRs that propose to work with classes that aren't annotated
    at all.

  • The J stands for java. More on this later in the entry, but annotations
    make a class to be non-standard Java (in my view).

  • The O stands for object. The annotations are on classes, and not on a single
    instance, but this may be more suitable for BileBlog
    incoherent blabbering.

And now to the main problem of annotations. As advocated by many (including the vehement
supporters of EJB 3.0), the annotations were devised to make our lives easier. No more need for
complex XML configuration files, no more need for getter and setters that conform to bean
standard, no more need for marker interfaces and so on. Just mark your field / method / class
with an annotation, and you get all that you could before at half a price. But what exactly
have we achieved?

  • The configuration XML file is now spread all over our class model. Furthermore, once you
    compiled your classes, you can't configure annotations (correct me if i'm wrong).

  • The bean getters and setters are gone, but instead the corresponding fields are
    marked with a predefined annotation. You say potato, and i say @potato.

  • The marker interfaces are gone, but instead the corresponding classes are
    marked with a predefined annotation. You say tomato, and i say @tomato.

  • Everybody is welcome to create his own annotations. Everybody can finally feel
    like a king and create his own kingdom. Everybody can finally create his own flavour
    of Java. Everybody does. Sun realizes that and tries to come up with
    common annotations. The community
    happily ignores the JSR. It becomes impossible to read the code because each field and
    class has more than 10 annotations attached to them. Java becomes Perl.
Related Topics >>