Thursday, May 14, 2009

JDO Support Spreads For Good Reason

It looks like Google AppEngine for Java's JDO support is beginning to spread to others. In particular, Grails now supports JDO on GAEJ, and it looks like GORM is being enhanced to support JDO.

Some of you may not have been aware that JDO has been under active, continous development at Apache ever since before the JDO 2.0 release. In fact, it's the only JSR that I know of that was and continues to be developed in open source, with the expert group's doors flung wide open, and its discussions on a public mailing list. The most current version of JDO is 2.2, with 2.3 imminent.

I, for one, am really happy to see Grails support JDO, seeing that I entered an enhancement request for it a very long time ago. Back then, it got shot down, but clearly, things have changed.

Why did the folks at GAEJ go with JDO over Hibernate? Well, I can't speak for them, but recall that Hibernate (and JPA), by design, target relational databases only, whereas JDO's API is designed to be fundamentally independent of the underlying datastore. Since the most common implementations of JDO in the past have been object-relational mappers, one major enhancement delivered in JDO 2.0 back in 2006 was to standardize object-relational mapping metadata. This had very little effect on the API, and where it did, it was only a matter of convenience for those who needed hybrid applications that used both JDO and SQL together.

JDO, by design, is intended to support any kind of datastore. This is an important point, because only JDO allows us to consider new and exciting ways of storing our data. With little or no change to our code, we can run our applications against relational databases, Google's BigTable on GAEJ, or even new, as yet undeveloped datastores.

I don't think that the day is far off that JDO supports not only cloud-based datastores (BigTable might be considered one), but also multiple datastores, whose boundaries are managed by your JDO implementation. Imagine a comprehensive persistent object model of your entire domain, regardless of where and how its bits and pieces are stored and retrieved, whether they be via relational databases, clouds, web services, RESTful services, other stores, and/or multiple, heterogeneous instances thereof. Better yet, imagine writing a Grails or even a Naked Objects application over such comprehensive object models!

We've all heard of the unified view of the customer; well, JDO is definitely the path to get there.