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.