The recent vote on the JDO 2.0 JSR reveals the unseemly underbelly of Enterprise Java. That ugly truth is that the commercial wing of Java is willing to try to derail perfectly viable technologies in order to meet the needs of themselves rather than the community. The simple truth of JDO is that developers want a standardized way to abstract their persistence that doesn’t require an EJB container. The single most important aspect of the specification is the standardization of the interface to relational databases. Nearly all JDO implementations already support this functionality in a non-standard way. It’s what developers want to use JDO for. Why not standardize it. Let’s look at the offenders:

• Oracle – claims it overlaps with JDO 3.0. In addition to having an app server, Oracle also owns the TopLink technology. It’s clear that this spec steps on their toes twice over. Once in driving developers away from their app server, and again in commoditizing TopLink-like functionality.
• BEA Systems – It’s obvious here. If developers don’t need an EJB container to manage persistence, they don’t need to pay $15k per CPU licensing fees to BEA. They can develop freestanding applications, or use Tomcat to achieve the same results.
• IBM – Same as BEA. IBM has nothing to gain and plenty to lose with this JSR.

The key flaw in these arguments, as highlighted by Sun, is that if JDO did not exist, the overlap with EJB 3.0 might matter. The fact is that JDO does exist, and gaping holes in the specification have led vendors to fill in the blanks with non-standard solutions. JDO must either receive these enhancements or wither on the vine. If these details can not be standardized, developers are just as well-served using a non-JDO persistence solution such as Hibernate or OJB, because unless they’re using an object database, the JDO standard buys them nothing but limitations.