Mr Roller wants to know why I don't like JDO.   I was hoping Matthew would come up with his rant first, well I guess I'm on the spot now.

For starters, I didn't like the fact that none of the OO relational mapping vendors were part of the specification committee.  The committee was mostly composed of ODBMS vendors.  In fact, the basic premise of JDO was to provide a more Java friendly api for ODBMS in replacement of the more language neutral ODMG specification.  It was meant to be something like what JDOM is for DOM, a friendlier api.

The confusion most people have with it is that they equate JDO to be a standard for Java persistence.  It is not a standard for Java persistence, rather its a standard api for ODBMS (object oriented database management system).  The standard itself is not supported by any of the major relational database vendors (i.e. IBM, Oracle, Sybase).  (You may claim Oracle supports it through Toplink, but that's just because Oracle purchased Toplink, Oracle had no intention of originally supporting it).  Also read this, a press release from ThoughtInc makers of Cocobase regarding JDO.

The specification in itself doesn't address any of the concerns of OO-relational mapping frameworks.  If you've ever worked with a tool like TopLink or Cocobase, you'll quickly realize that there's a lot more to OO-relational mapping than what you find in JDO or even EJB CMP. For starters, there's the need to retrieve only partial objects, to selectively turn off the cache, to have scrollable cursors, to incrementally read in object graphs, to manage optimistic locking, to perform advanced queries, to perform batch updates and other issues.  All these capabilities are required because you cannot really hide the underlying implementation details, that being a thin pipe accessing a relational database. 

OO-relational mapping is simply not addressed by JDO, and that's the whole point.  I would like to have the full flexibility of a Java model at the same time have as many options as possible in how I persist it into a RDBMs.  That's what a good framework gives you, that's why Hibernate is better than OJB.  It simply has more options.  OJB is concentrating on an API that really has very little to do with mapping. 

Finally, not all standards are good for you, my blog rants about a whole bunch of bad standards.  Lets go down the list EJB, Web Services (i.e. SOAP, WSDL), TagLibs, CLI and of course JDO.

BTW, if you're interested in an opensource JDO implementation, here's one: TJDO (disclaimer: not a recommendation!). Oh, its got an Apache License, maybe they should merge code bases with OJB and be done with this JDO fiasco.