Are Annotated Java Classes Still POJOs?

The Spring framework, as a lightweight container, prides itself in being able to "wire together" Plain Ordinary Java Objects (POJOs) through dependency injection. Most descriptions that I've read of the dependency injection model of the up-and-coming EJB3 specification claim the same. (For an example, see this ONJava article comparing Spring and EJB3.)

However, while Spring specifies the "wiring rules" in XML configuration files (deployment descriptors), EJB3 relies on Java 1.5's annotations to specify how objects are wired together.

So that brings us to the question, "Are annotated Java classes still POJOs"?

Personally, I think not. Why?

One definition of POJO might be: "A POJO is a Java class that is not required to extend a particular superclass or implement a particular interface."

I think a better definition of a POJO would be: "A POJO is a Java class that is not required to reference or use another resource in any way."

The second definition is more generalized. To run or compile a POJO, I should not be required to reference any third-party Java resource, whether it be a class or an interface (including annotation interfaces). For that matter, I shouldn't be required to use any core Java resource in my POJO.

(To be fair, it may be possible to run annotated classes in a JVM without requiring that the annotation interfaces exist in the classpath. Someone please correct me if I'm wrong. Either way, you certainly need the annotation interface in order to compile the class.)

According to this definition, Spring wires POJOs together, but EJB3's dependency injection does not, because it doesn't do dependency injection without annotations. Similarly, JSF's faces-config.xml defines POJO relationships; JBoss Seam's slick annotated "bijection" does not, because you can't use bijection without referencing the annotations. As a final example, Hibernate (with XML) persists POJOs; the annotated entity beans of the new Java Persistence API 1.0 aren't really POJOs.

Note that the Java Persistence API is able to persist your true POJOs using XML declarations, much like Hibernate. See chapter 10 of the Java Persistence API public review for more information. However, that is precisely my point: without the XML alternative, you wouldn't be able to persist any old Java object unless you have the ability to modify the original source and directly tie it to an external identifying resource (the annotation).

So, does this mean that annotations are bad? No, it does not. Annotations bring the metadata closer to the actual object, which certainly can improve development efficiency. Certainly the case can be made that annotations done right, combined with their respective containers, bring Java closer to Ruby on Rails in both fun and efficiency.

And does this mean that XML deployment descriptors are good? Not necessarily. I'd rather see these descriptors defined in something a bit more lightweight, such as YAML or JSON. But it seems to me that external descriptors certainly have their place.

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.

It's a simple matter of definition.