Comments on: A POJO with annotations is not Plain

By: Somebody

Somebody — Fri, 20 Apr 2007 14:47:08 +0000

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.

By: Xebia Blog

Xebia Blog — Tue, 03 Apr 2007 08:44:03 +0000

[...] @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. [...]

By: Erik Brakkee

Erik Brakkee — Wed, 14 Feb 2007 23:01:08 +0000

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.

By: Ron Kersic

Ron Kersic — Wed, 31 Jan 2007 22:03:43 +0000

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….