Wednesday, May 07, 2008

An AJO is not a POJO

A POJO is a plain old Java object. Everyone talks POJOs these days. They are easy to compose and unit test. They are free of coupling to specific infrastructure details. So you can take your POJO to another infrastructure. For example, from JavaEE to Spring or OSGi. I like them and I think it is the right way to do things.

However, people are also fascinated with annotations now. Things like Guice and EJB3 and Glassfish all want you to annotate your POJO. But once you do that, your POJO ceases to be plain. While the non-annotation part of your code is still the same, the annotations in your code mean that your source now has coupling to specific infrastructure details and it is wrong to call is a POJO anymore. You can't compile your code without the proper support for those annotations. If you want to deploy your code in another infrastructure that uses annotations to describe the infrastructure details, you have to add more annotations to your source.

While I see the interest in putting the infrastructure information in the source near where it is used. We need to be honest. Your code is not a POJO anymore. It is now an AJO: an annotated Java object.

6 comments:

Ed Merks said...

I've always wondered if there is a clear cut definition of what makes any old Java object (AOJO) stop being plain and old? I.e., where is the AOJO/POJO boarder? You're suggesting that as soon as an annotation appears, the plainness disappears. But clearly an @Override won't be a concern, so even here the dividing line seems less that clearly spelled out.

Another example to consider is java.io.Serializable support. If my framework requires all objects to support that API, does my framework support POJOs? I would think not. In any case, it certainly doesn't support AOJOs, so one might argue that an AOJO that's Serializable isn't a POJO. But that seems kind of illogical as well.

It seems to me that POJOness might well be a thing like beauty: a fleeting ill-defined thing that exists primarily in the beholder's eye...

צְבִיקַ'ה said...

hey, let's not get too postmodern about the definition of POJO, shall we? :)

conceptually, an annotated pojo is a pojo with touches of aspects that hint managed environments as to how to treat the object. the separation between java se and java ee runtimes shouldn't apply for annotation jars, I think, although that's a whole different issue. anyway, one of the deeper meanings of POJOs to the world of JEE is that the distinction between client and server runtimes is made fluid, much thanks to OSGi. Extensible POJOs is more like it, in my view. how about EOJOs?

BJ Hargrave said...

@ed merks: Using @Override, which is part of the standard Java now, does not alter the plainness of the Java object. But when you use annotations which are specific to particular framework infrastructure, for example @EJB, your source is no longer plain. The infrastructure details begin to litter your source code. As John Hurst said in a TSS thread: "A class full of 3rd party annotations isn't a POJO any more -- it has dependencies on 3rd party framework code." This is my point exactly.

Chris Aniszczyk (zx) said...

I agree BJ, you tell 'em.

Rafael Chaves said...

Totally agree.

Java standard annotations or implementing Serializable (which is basically part of the language) don't affect the plainness of a Java class.

Hoever, 3rd party annotations are just a veiled form of dependency. It is easier on the eye, and they can even be ignored/ineffective during runtime, but they are still intrusive.

Steven Peh said...

I would disagree. It is still a POJO. The annotation doesnt make the POJO dependant on the framework. The annotation merely lets external consumers of the POJO know how to apply extra features, which are irrelevant to the POJO within its Object boundary (the specific business logic it provides), albeit not necessarily irrelevant to its interaction with other POJOs in the same system.