Gavin King Torpedoes JDO!

Gavin King, founder of Hibernate, has made his case that JDO isn't going to be easy to fix and he would rather take his chances with EJB 3.0.

First, JDOQL is an abomination. (There I said it.) There are four standard ways of expressing object-oriented queries: query language, query by criteria, query by example and native SQL. JDOQL is none of these. I have no idea how the JDO EG arrived at the design they chose, but it sort of looks as if they couldn't decide between query language and query by criteria, so went down some strange middle road that exhibits the advantages of neither approach. My suggestion to adopt something like HQL was a nonstarter. The addition of support for projection and aggregation in JDO2 makes JDOQL even uglier and more complex than before. This is not the solution we need!

Second, field interception - which is a great way to implement stuff like Bill Burke's ACID POJOs or the fine-grained cache replication in JBossCache - turns out, perhaps surprisingly, to be a completely inappropriate way to implement POJO persistence. The biggest problem rears its head when we combine lazy association fetching with detached objects. In a proxy-based solution, we throw an exception from unfetched associations if they are accessed outside the context of the container. JDO represents an unfetched association using null. This, at best, means you get a meaningless NPE instead of a LazyInitializationException. At worst, your code might misinterpret the semantics of the null and assume that there is no associated object. This is simply unnacceptable, and there does not appear to be any way to fix JDO to remedy this problem, without basically rearchitecting JDO. (Unlike Hibernate and TopLink, JDO was not designed to support detachment and reattachment.)

Proxy-base solutions have some other wonderful advantages, such as the ability to create an association to an object without actually fetching it from the database, and the ability to discover the primary key of an associated object without fetching it. These are both very useful features.

Finally, the JDO spec is just absurdly over-complex, defining three - now four - types of identity, where one would do, umpteen lifecycle states and transitions, when there should be just three states (persistent, transient, detached) and is bloated with useless features such as "transient transactional" instances. Again, this stuff is just not easy to change - the whole spec would need to be rewritten.

I guess it reaffirms what I've been arguing for years, JDO is a complete mess any its only saving grace would be to throw it out into the dumpster. It's simple not feasible to turn this barge in midstream. JDO original motivation was to better support object oriented databases. The OODBMS idea was out of wack to begin with, and no amount of duck tape is going to fix it. Just get a reality check from the marketplace, if if actually worked then you would expect to see a ton of legacy OODBMS that you have to maintain today.

If EJB 3.0 delivers as advertised, it'll look more like Hibernate + Spring. If that's the case, then there's absolutely no reason in my mind why a future JDO would be of any use. It turns out, BEA, Oracle and IBM were dead on right when they discover persistence mapping and architectural neutral design?

[ update ] Abe White of Solarmetric posts a rebuttal.