The JDO 2.0 JSR has been submitted with the following major goals:

1.Make JDO easier to use.
2.More closely align JDO with J2EE.
3.Standardize JDO’s support of relational databases.
4.Broaden the scope of JDO to include more vendor persistence architectures.

#3 is perhaps the most critical. In current JDO implemementations, the O-R Mapping approach is completely defined by the vendor. Although they are probably similar, and migration won’t be completely brutal, the lack of a standard is probably a key factor discouraging adoption of JDO.

Other key features in the JSR include:

• Disconnected operation – allow users to extract objects from the database, disconnect, modify, and resubmit changes. It sounds like it tracks a unique identifier for disconnected objects and uses this to determine what data to update.
• Interface persistence – in JDO 1.0, interfaces couldn’t be persisted. Just classes. Fair enough.
• Binary compatibility not required – In JDO 1.0, there was apparently a contract the vendor had to conform to when the enhanced the bytecode. No real idea why this was required, so it’s good it’s going.
• J2EE alignment – the main thrust of this is a cleaner transaction API
• JDOQL enhancements – adding aggregates, string manipulation, better range of return values. This is evidence of the maturing of the technology.
• Enhanced relationships – Bidirectional and composition relationships MAY be addressed.

Of course there are other minor tweaks that will creep in. In any case, a recent Solarmetric presentation on JDO led me to conclude that JDO 1.0 hasn’t quite hit its stride, but JDO 2.0 will have enough of the candy that O-R Mapping junkies are used to that it can start to pick up some momentum. Thankfully, the expert group has kept the specs manageable up to this point to where migration to JDO is a realistic prospect (for an anti-pattern, look at JSF).