Figured I'd take a moment and think out loud about how I want to apporach writing JDO tools for OJB, and why. Right now if you are writing a long-lifespan application you take two routes: use Entity Beans, or use a home-rolled DAO layer as a mediator between you and the persistence solution. Go look at Spring for an elegant example of this. Queries in both cases are very limited -- you have named queries. That's it. Projections are very limited, you have named queries, that's it, so whatever projection you define coming back from the query.
All of the major o/r mapping tools can do better than this, but, frankly, no one trusts that o/r mapping, or a particular tool, will be the way to access data in the future. Okay, some people do, but the smart ones don't. Things change too fast. Once upon a time hierarchical databases were the obvious way to access data, what could get better? Anyway.
The ubiquitous DAO layer is the same technique as has been used since sometime in the 80's when you externalized you SQL and called named queries. It works, is well understood, and is very limiting. You have to play to the lowest common denominator.
What JDO promises is to standardize the DAO layer and provide real dynamic query access through it. The idea is simply that you can write against the JDO client API's right now, and fifteen years from now, when data is stored in positronic anti-cloud information dumpsters they will still support JDO. Using JDO directly, then, will feel like dealing with SQL C api's right now, but it will still work.
OJB, Hibernate, Cayenne, iBatis, Spring, etc, won't. SQL adaptors will probably continue to exist, but then you are limited to the DAO type thing you do now. Right now, JDO promises to let you swap out any of said tools and still run your code, so if OJB doesn't perform the way you want for your queries, you can drop in iBatis, etc.
JDO doesn't provide this right now. JDO is not a real standard because in its initial incarnation it was incredibly awkward to provide an exposed JDO interface. JDO 2.0 is trying to change that, and the approach I am trying to take to OJB's JDO 2.0 tools is designed to help even more.
The JDO 1.0.1 RI is a great example of what to do. It very nicely provides a tool designed to make mapping other stores to the JDORI almost trivial. Its license made this irrelevent. The idea was right though. So, lets take the idea and run with it. If we make it incredibly easy to put a JDO interface on *anything* the promise starts to be realized. If we build it with two clients in mind -- the programmer using JDO, and the data store developer writing a backend, this can be done. Obviously, I hope people will want to use the OJB backend, but that doesn't fit all circumstances.
So, to do this I plugged together a totally datastore independent object-space transaction management library last night. It is young yet, but its only dependency is jdk1.4, and it provides full object space state querying, graph traversal, and collection/property rollback capabilities. It provides no callback hooks for persistence, yet, but those are coming. This starts to provide, and hopefully will fully provide, the state tracking, and state management hooks needed by backend stores.
The next fun part is the JDOQL interpreter. Thomas Dudziak is working on a clean AST compiler for JDOQL. Any datastore provider will need to be able to implement a visitor which can compile down to native queries. This will probably be the most inconvenient, but providing the JDOQL AST is probably as convenient as we can help make it.
The promise of JDO is only realized if it does become as ubiquitous as SQL for object querying. The only other thing trying to do this is EJB Entity Beans -- but they have their own headaches (which EJB 3 is trying to fix, and if they could only seperate the persistence parts from the rest of it, would be relevent). It will only be ubiquitous if it is cheap and easy to provide to the interface, and the interface solves the problems people have.