ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Flawed Understanding of JDO Leads to FUD

by David Jordan, coauthor of Java Data Objects

When a new technology comes along that introduces a paradigm shift, it often challenges the existing, established technology in use. It is a natural tendency for those with a vested interest in maintaining the status quo to spread fear, uncertainty, and doubt (FUD) about the new technology. Java Data Objects (JDO) is a new technology released from the Java Community Process that allows developers to directly persist their object models in transactional datastores. It supports the development of applications where the Java object model serves as the sole data model used in the application. It provides a query facility that allows applications to filter the objects in their object model using query operators and syntax taken directly from Java. JDBC and SQL are noticeably absent from JDO's interface, yet it has been designed so that it can be layered on top of these relational database technologies.

Donald Bales recently wrote an article for OnJava.com titled "Flawed JDO Points the Way to the Objectbase." In this article, he brings up issues he has with JDO and then presents an application program that is supposed to provide an "apples-to-apples" comparison between JDBC and JDO. He provides an Oracle-specific JDBC program that is similar, yet different, from an article by Dion Almaer titled "Using Java Data Objects."

Bales' program does not provide the same functionality as that found in Almaer's article, so it is not a true apples-to-apples comparison. In the interest of brevity, I will not enumerate all of the differences among the programs in these two prior articles; however, I will provide a complete, compiled, and working JDO program that does correspond to the program provided in Bales' article.

Before presenting the application, I'd like to address some statements Bales made in his article. He claims:

JDO threatens the livelihood of products such as object/relational mapping utilities that map Java objects to relational data. Because of this, and for other reasons, JDO has received more than its fair share of bad press.

Unfortunately, no references are provided to support his claim that JDO has received a lot of bad press. I am only aware of one such negative commentary in the press. It comes directly from one of the object/relational mapping vendors of a product that maps Java objects to relational data. This vendor has their own product with a proprietary API that stands to lose significantly if JDO succeeds. To those familiar with the situation, it is well understood that the attacks are motivated by the company's financial concerns. JDO provides a standard Java interface to support object/relational (OR) mapping. It only threatens existing OR products based on proprietary interfaces that will lose favor as JDO adoption accelerates. It is very common for companies with proprietary solutions to raise criticisms of a new standard that makes their current solution obsolete.

Bales states he has two issues with JDO. First, he claims that "somehow SQL has become a bad thing." I am not sure how this suggests a flaw in JDO. JDO proponents are not stating SQL is bad. JDO merely provides an alternative, Java-centric means of persisting information in a database and does not use SQL in its interface. Many of the JDO implementations available in the market are implemented on top of JDBC and SQL. SQL provides capabilities that JDO does not, and probably never will, provide. SQL provides support for the relational data model, allowing it to dynamically associate "formerly unrelated populations of information," as Bales claims. For many applications, the facilities of SQL are essential. But many Java developers want to have a Java object model view of their information. They have struggled due to a lack of a standard for persisting their Java object models in a database. JDO provides an alternative to JDBC/SQL more suited for these applications.

Bales' second issue with JDO is his belief that JDO treats a database management system (DBMS) like a file. He claims that with JDO you open a file, read it all into your application, write changes back to disk, and close the file. He states that this "does not properly facilitate multi-user access." It is not clear where he got this misunderstanding of JDO. The "Using JDO" article that Bales references used Oracle, the same database Bales uses in his example. While JDO implementations exist that are built directly on top of the file system, implementations are available for object databases and most relational databases. JDO has been architected to allow updates to be made at the granularity of a single field of a single instance in the database. So there is nothing inherent in JDO that precludes multi-user access.

Bales states that JDO is a "workaround" and that:

... [O]bject-oriented programmers ... have not applied it to solving the business problems. ... (They are) stuck in the world of functional decomposition ... abstracting things in the real world by categorizing information about them, but ignore their behaviors.

First of all, I whole-heartedly disagree with his characterization of object-oriented programmers. And it is very unclear how this statement is related to JDO being a workaround. JDO allows one to build object models and software that are completely orthogonal to the ways in which they are composed and used in applications, with many different decompositions of the application's architecture, functional or otherwise.

Bales then proposes that what we need is an "objectbase" instead of a database, where binary executables can be stored and retrieved. He then suggests that the way to do this is to use JDBC or SQLJ. In particular, he advocates using Oracle's specific implementation of OR mapping. One of the goals of JDO is binary portability of applications across all underlying datastores. A JDO implementation is free to optimize its mapping of Java models onto the underlying Oracle OR feature set. With JDO this mapping is hidden from the application, which allows it to be portable across a wide variety of databases.

Pages: 1, 2, 3

Next Pagearrow