Matthew Adams has written up a "Quick Comparison of EJB 3.0 JPA & JDO 2.0
," saying that JDO is object-oriented whereas JPA is aimed at relational databases, JDOQL is very "Java-like," and a few other things JDO implemented differently than JPA, like fetching optimizations.
It is my humble opinion that, in the long run, EJB 3.0 JPA will look more and more like JDO 2.0, if not syntactically, at least conceptually. Heck, it already does.
It has to be said that Matthew is a JDO supporter, with other blog entries like "Why do you hate JDO?
" (which defends against many of the things people complained about.)
JDO still lives, of course. The specification isn't likely to progress much - according to Sun, at least - but JDO remains a good specification, and its users tend to swear by it. However, the majourity of developers seem to have stayed away in droves, and JDO's strengths seem to have not served it as much as it deserved.
JPA targets only relational back ends. JDO 2.0 is still largely datastore type agnostic, but standardizes most things relational.
This is a strength of JDO and certainly possibly a weakness in JPA. However, is this really a problem? How many users are not
using a relational datastore? While it's interesting and potentially very useful to be able to map accurately to a heterogenous datastore such as a CODASYL
datastore - basically a way of managing data with heterogenous sets, as a drastically oversimplified explanation - how many TSS readers need the capability to do this?
So what do - or did - you think of JDO? Many of its ideas found their way into the Java Persistence API; did enough of them? Should the next JPA spec attempt to implement more of the best features of JDO, as Matthew predicts it will?