efore Java Data Objects (JDO), database programming was stuck in the ’80s. All programmers had were either highly proprietary programming interfaces or SQL, a powerful but cumbersome declarative database programming language for relational databases that IBM invented in the late ’70s. For me, SQL is like programming a Macro Assembler. It requires that I know a lot about the database design (e.g., tables, rows, columns, relationships, indexes, etc.) before I can write my application. That was okay in the ’80s, but it’s not acceptable for the increasingly complex applications of today.

Developers tried many times to solve the impedance mismatch between the application code (objects) and the data store code (tables, rows, columns, and SQL). However, none of their attempts ever became a widely accepted standard. Examples of these failed solutions include:

• Proprietary object-relational mapping tools (e.g., Oracle’s TopLink)
• Container-based solutions like BMP and CMP that run only within the J2EE space
• Simple object streaming, which is available only for flat files
• The ill-fated Object Data Management Group (ODMG), which completely ignored the existing relational databases and tried hard to impose a standard for those object databases after the fact (i.e., when the vendors already were offering products with proprietary APIs).

So what makes JDO different? From a technical standpoint, JDO provides an abstraction layer between the application and the data store. Craig Russell from Sun Microsystems and a group of database and persistence experts formed JDO to define a “specification that provides for interface-based definitions of data stores and transactions, and selection and transformation of persistent storage data into native Java programming language objects.” In plain English, JDO is a well thought out application programming interface that provides a common layer to access and manipulate data stores of various kinds (e.g., relational databases, legacy databases, object databases, embedded databases, and even flat files).

JDO provides an abstraction layer between the application and the data store.

The actual coding of the data store remains shielded from the application, which simplifies the application code significantly and makes it less error prone, more productive, and easier to maintain. This is particularly important as today’s applications become more and more complex?developers have more computing power, so they write more complex applications.

Also unlike the above-mentioned attempts, JDO has gained acceptance quickly considering it is a relatively young technology. It was one of the first Java Specification Requests (JSR-12) under the guidelines of the Java Community Process (JCP), receiving approval from the JCP Executive Committee in March 2002 as an optional component for the J2EE specification. In the year since then, it has seen broad adoption:

• At last count, more then 15 commercial JDO implementations were available from vendors including FastObjects, SolarMetric, Object Industries, Object Frontier, and Hemisphere Technologies.
• At least three open-source projects, XORM, ObJectRelationalBridge (OJB), and TriActive JDO, are working on JDO implementations.
• Most recently, JBoss Group and Trifork announced JDO support in their J2EE application servers.

All in all, a wide variety of JDO products exist today that support most standard database systems, including those from the big RDBMS vendors (Oracle, IBM, and Microsoft), providing excellent integration and migration strategies going forward.The Politics of Object Persistence
More and more developers are realizing the merits of an object-based interface, which brings me to the political aspect of JDO. The beauty of JDO is that it runs anywhere, which is great for the developer, but it seems to be a nightmare for some of the established database vendors. As a developer, once you’ve learned to write JDO, you can use it for any project. You can pick the JDO implementation that fits your project and select the most appropriate data store, without needing to retool and relearn every time you start a new project.

JDO also gives corporations much better bang for their bucks. The investment in training their developers and buying JDO toolsets will have a greater return over time than incremental training in various technologies, because the developers can reapply their JDO skills across multiple projects. Plus, JDO increases the level of vendor independence?key in an ever-changing computer industry.

JDO runs anywhere, which is great for the developer but seems to be a nightmare for some established database vendors.

It’s just common sense to have such an object-based interface and to have it standardized. However, solving the impedance mismatch has been one of the biggest political hurdles for JDO so far. Several relational database vendors are not endorsing the open standard yet because it removes the vendor lock-in they have enjoyed and nurtured for the past 20 years. For example, they’ve developed proprietary extensions to SQL and developed proprietary tools or mapping tools, all the while fencing off advanced database systems based on non-relational data models.

However, the mainstream has also shown positive signs of JDO adoption. The JBoss Group and Trifork announced plans to incorporate JDO into their J2EE application servers, and Sybase has partnered with Libelis, a European JDO vendor, to provide data-persistence products for enterprises.

The JDO Controversy Continues
A lot of controversy continues to surround JDO. Proprietary tool vendors such as Oracle’s TopLink are touting their tools as being “JDO-like” but more robust, claiming JDO provides inferior performance because of the additional vendor-independent abstraction it provides on top of the native relational database interfaces. JDO vendors are addressing these claims with several benchmark projects. For example, JDO-specific implementations for the RuBIS, OO7, and PetStore benchmarks are under way and results should be published during the next few months.

Some technical details of JDO, such as the JDO code enhancer and the general persistence model, also have been under attack. Object persistence purists are holding out for a “transparent persistence” model that will work without any code enhancements, as a completely embedded part of the Java language. I have followed the transparent persistence discussion for close to 15 years (e.g., at standards body meetings from the OMG and the ODMG) and I strongly believe that this argument has no merits. First off, Sun?the Java gatekeeper?is not going to change the Java specification to allow for such a mechanism. And, secondly, who wants to have a custom VM anyway? The JDO code enhancer is a great compromise that the JDO experts carefully drafted with full knowledge of what realistically can and cannot be done in this regard.

I strongly believe that the transparent persistence argument has no merits.

With the growing acceptance of JDO, I hope that such controversial discussions take place as active participation in the JDO 2.0 expert group, so the feedback can be funneled into future JDO releases. The Java community should accept JDO as the foundation for Java object persistence and collaborate even better in the future to improve and extend JDO.

The Next Best Thing in Database Development
JDO is here to stay, it is probably the next best thing since the database industry standardized on SQL about 25 years ago. It provides a complete database abstraction at the object (Java) level, it is database independent, it has broad product support, it is very powerful, yet simple to use, and it delivers significantly more bang for the buck.