A POJO with annotations is not Plain
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.
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.
- 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. 😉