To have a standard persistence API for J2EE and J2SE is a worthy goal.

Instead of calling it "The Standard Java Persistence API" though, Linda DeMichiel and Craig Russell, decided to call it "The POJO Persistence Model" in their "Letter to the Java Community".

"The new POJO persistence model will be delivered by JSR-220 as a separate specification..."

There already is a specification for POJOs and it is, by definition, the Plain Old Java Language Specification.

More specifically, POJOs are not subject to:
 - interface implementation conventions
 - naming conventions
 - getter/setter conventions
 - member visibility restrictions
 - code annotation requirements
such as the persistent entities described in the EJB 3.0 Specification Early Draft.

Any supplemental "POJO spec" is a contradiction in terms.

"Sun Microsystems is leading a community effort to create a single POJO (Plain Old Java Object) persistence model for the Java community."

I am not worried about the merits of the JSR-220 itself. We have already discussed them here on TSS last September.

I am only worried that, if the POJO definition hijack is successful, we will have no name left for those lovely
little things Martin Fowler and friends have originally called POJOs.

We will need a new name.

Any ideas? Martin?

Klaus,
I don't think they're hijacking the definition of POJO at all. They aren't trying to redefine what POJOs are. They're merely trying to come up with a new specification for persisting POJOs.

Hi James,

Thanks for your reply.

I don't think they're hijacking the definition of POJO at all. They aren't trying to redefine what POJOs are. They're merely trying to come up with a new specification for persisting POJOs.

It is OK if my item doesn't get published because you don't like, but please don't simply contradict my conclusion ignoring my points.

Please comment on this:

More specifically, POJOs are not subject to:
 - interface implementation conventions
 - naming conventions
 - getter/setter conventions
 - member visibility restrictions
 - code annotation requirements
such as the persistent entities described in the EJB 3.0 Specification Early Draft.

Thanks, Klaus.

Klaus,

First of all, I don't know what you're talking about when you say "It is OK if my item doesn't get published because you don't like." I have no control over what gets published anywhere. I have a hard enough time getting my own stuff published! :-)

As for your argument, I think I see what you're saying. In the purest sense a POJO should have no restrictions on it, other than it is an instance of java.lang.Object (the JO part). A POJO is (http://c2.com/cgi/wiki?PlainOldJavaObject) "a normal Java object that is not a JavaBean, an EntityBean, a SessionBean, etc." So, by definition, a POJO is an object which doesn't conform to some (official?) specification or framework. Right? If that's true, then the term "POJO persistence specification" is somewhat of an oxymoron. Is that what you mean? If so, then maybe you're right. Maybe they did choose a poor name. Maybe they should have chosen a name which more adequately reflects what they're trying to convey which is that the persistence specification is "transparent" or "non-intrusive" and can be applied to any object. Even those claims are a bit subject, though.

I don't so much mind the Serializable requirement for objects that need to be passed remotely, as that's just the way it's done in Java. Nor do I mind the getter/setter naming convention, as there are many very useful frameworks out there (Commons BeanUtils comes to mind) that rely upon those naming conventions. However, the code annotation requirement (is it a requirement or can you persist third-party objects for which you have no source also?) is somewhat intrusive, in that you do actually have to change source code to insert annotations into a class (not to mention you have to upgrade to JDK 5). The member visibility restrictions (no final methods) are also quite restrictive, but I think they are a bit more palatable. What did you mean by "naming conventions" besides the getters/setters? I'm not saying there are no other restrictions like that, but I just didn't see any that jumped out at me while skimming the specification.

All in all, I do like persistence frameworks. I use Hibernate a lot. I even use XDoclet to generate my mapping files for me, so I'm somewhat a hypocrite about the annotation stuff. However, Hibernate does allow me to write them by hand if I want to. I do not share your view of "Persistence is Futile" (although I applaud its originality). I do, however, think I might agree with you that maybe they should change their "pet name" for this specification (the spec doesn't mention POJO anywhere) so as to not bastardize (or hijack) the meaning of the term POJO. I still don't think that it's the intention to alter what connotations the term POJO brings about, but maybe they might have been a bit hasty when using the term to describe this specification. In the purest sense of the word, as the original person who coined it intended, the objects described by this specification are not POJOs.

James

Klaus, you say 'Any supplemental "POJO spec" is a contradiction in terms.'

Here's the problem: they are not defining a POJO spec. They are defining a persistence spec around POJOs.

Note use of the word "persistence" in front of the word "spec".

So no one is hijacking anything here - except possibly you hijacking the english language for your own inscruitable purposes.

   -Mike

Hi Mike, :)

For the third time, POJOs are not subject to:
 - interface implementation conventions
 - naming conventions
 - getter/setter conventions
 - member visibility restrictions
 - code annotation requirements
such as the persistent entities described in the EJB 3.0 Specification Early Draft.

Therefore, what the JSR-220 is doing cannot be called "POJO Persistence" as they would like.

But, of course, you can just ignore those points for the third time and continue simply contradicting me with absolutely no argument.

See you, Klaus.