A POJO with annotations is not Plain

28 Jan, 2007

Everybody loves POJO’s. Ever since Martin Fowler, Rebecca Parsons, and Josh MacKenzie coined the term back in 2000, the idea has taken the Java world by storm. Successful frameworks like Spring and Hibernate have centered on POJO’s to make J2EE development a whole lot easier.
Since then JDK 1.5 came along and brought us annotations. And now everybody’s going crazy again. And by claiming to support POJO’s old-skool tech is now trying to become fashionable again.
Although I could not find an official definition of POJO, I think we can generalize from Martin Fowler’s original definition that a POJO is not an EJB to a POJO is a Java object that is not tied to any specific framework, and therefore can be used by multiple frameworks in different situations and configurations. If you accept this definition, you’d have to agree this annotated POJO craze is silly.

There’s four problems with this, especially with the trend that a lot of these annotations are used to put configuration data in your code:

  • You can’t compile an annotated POJO without having the frameworks that include the annotations.
  • The syntax is horrible when a lot of configuration data is put in. I’m not a big fan of XML configuration either but annotations just replace angle brackets with a whole lot of parentheses and curly braces.
  • By putting configuration data in the class, you have to recompile your code to change the configuration.
  • And finally, by doing this you can’t have multiple configuration for the same class, e.g. map one class to multiple tables in the database.

(Of course, you could use AspectJ 5’s declare annotation feature to keep the configuration separate. But we already had that when we used XML configuration files. If you declaratively added annotations with AspectJ you’re not only adding parentheses and curly braces but also the whole AspectJ syntax. Makes XML looks really nice by comparison.)
So, I propose to call these things a-POJO’s from now on. You could imagine that to be short for Annotated Plain Old Java Object, but that’s not what I mean. 😉

Newest Most Voted
Inline Feedbacks
View all comments
Ron Kersic
15 years ago

Unquestionably, the annotation examples you highlighted are stark reminders how difficult it seems to be to learn from earlier mistakes. Setting these examples aside, and forgetting how half-baked the support is in Java 5, I’m not sure whether an application of annotations actually removes the “plainness” from POJO’s.
Adding (layers of) metadata on top of our POJO’s isn’t a new trick of course. The @deprecated JavaDoc tag, the transient keyword, and the Serializable interface but also the Spring ApplicationContent.xml are all examples of adding metadata to objects that still would qualify as POJO’s in my book (or at the least, as objects that enjoy the same benefits as POJO’s do).
As long as the core values of a class (or class hierarchy) can be verified in isolation from the qualities its annotations are communicating then the moniker POJO still seems applicable. This holds for “Java-generic” annotations (@Deprecated, @SupressWarnings) or “domain-specific” annotations (@Product, @Role).
But even annotations that draw from the solution domain are not always harmful. A domain class annotated with @Table(name=”foo”) should not prevent using the class solely for its domain qualities (e.g. calculating a mortgage). You can’t test its persistency qualities without some implementation/container present of course and yes, you need the definition of the ‘Table’ annotation, but no great harm seems being done. No?
My $0,02….

Erik Brakkee
15 years ago

Completely agree. The current annotations craze is just another example of overcompensation and overuse of new cool features. One framework that takse this to the limit is JBoss SEAM where you really have to write only a few lines of code but your code gets totally blurred by large numbers of annotations.
The trick is to use annotations to the right extent. For instance, as far as the JPA annotations go, I think it is really useful to have an annotation like @ManyToOne because it enriches the code. Namely, it tells you that the relation is many-to-one and not one-to-one, a fact that cannot be determined from the code alone. Nevertheless, it starts to get a bit dubious when information that might be deployment specific enters the code such as table or column names.
I guess we will know in a few years time what really works or not.

15 years ago

[…] @EJB??? There it is! But why there? I don’t care that the customer is an EJB, I just want it to be injected. Now one of the main reasons for using interfaces is gone: my AcccountServive knows implementation details about the CustomerBean, namely that it is an EJB. A more general problem with using these annotations is that my classes are now dependent on JEE to compile, since the annotations are in the JEE API and not the JSE. This is also one the points Vincent talked about when mixing annotations and POJO’s. […]

15 years ago

POJO term is stupid. Don’t you see that it is context dependent? POJO by definition is not derived from any framework’s abstract class or interface. If my class is derived from, let’s say, XMLBean abstract class then in context of EJB it is still a POJO but in context of XMLBean framework it is not. Since its definition is unclear from the beginning it allows for any type of abuse.

7 years ago

I agree with the author of this article, event if annotations are a convenient way to add metadata, I would definitely like to have a way to separate my classes to the way they are serialized in XML. This for the reasons explained in the article, and more generally for the sake of separation of concerns. In huge applications, having this distinction between the Model and the XML serialization is a real benefit in term of maintenance.

Explore related posts