Java programmers like working with objects (I hope!). Applications often, if not always, need us to persist information. Most server-side developers have worked with the JDBC API, which allows us to access databases, and is mainly used to query relational databases. Since we already have our model in our objects, wouldn't it be nice to be able to persist the objects that it makes sense to store? It can be a real pain to write code that jumps from our objects and saves the values away into a database. This can also get tricky when you get into relationships between objects. The Serialization mechanism allows us to take an object and save the graph to a stream, but Serialization is not built to allow multi-user sharing.
Along comes Java Data Objects, a specification proposed under the Java Community Process as JSR 012, to allow developers to work on the business solution, without worrying about the infrastructure code to map between objects and databases. The JDO API is a standard API that a developer can learn once and use everywhere. At the same time, multiple implementations of the interfaces exist. This is similar to learning JDBC, and being able to access Oracle, Sybase, etc. just by changing the JDBC driver. Aren't you glad that you don't have to study the Oracle OCI libraries, or Sybase's Dblib? I am.
Since becoming a JSR, however, JDO hasn't met with a universally warm reception. Some people love the idea of standardizing on persistent objects, and some like to criticize. Specification lead Craig Russell has found himself having to combat the critics (as we will see later).
So now we have a "standard" API for persisting objects in the enterprise. What do the vendors that have been doing this all along think? In June, Thought Inc., makers of the popular CocoBase object-to-relational (O/R) mapping solution for EJB application servers, announced their transparent object persistence. The press release took a bit of a side shot at the way JDO is designed -- "Many consider the designs of ODMG and JDO to be counter to Java's open access, cross platform, component reuse design intent. While CocoBase's architecture makes Java classes vendor neutral, the other approaches deeply tie the source or binary code to only one vendor. Their system creates a Java class hierarchy that once processed and integrated by one vendor becomes completely incompatible with another" -- and Craig Russell (JDO guy) had to hit back. One JDO implementation detail that Thought Inc. really didn't like was the fact that JDO class files go through bytecode manipulation and inject "special code." CocoBase's solution wraps around your pure object model, and doesn't force you to extend a particular class, or run bytecode processing. You can read the original press release, Craig's responses, and Thought's counter-responses, as well as comments from common readers on The ServerSide.com. It's an interesting read!
If you were in Thought Inc.'s position, and you thought that there was a "better way to do it," would you go off on your own, or go with the standard, trying to really push for them to hear your opinion?
In an ideal world, it would be great if all O/R vendors would start to use the JDO standard. TOPLink seems to be taking the approach of, "We will support some level of JDO, but where we think it is poor (for performance reasons) we will offer our own APIs." These O/R mapping tools are great; it doesn't make sense for a developer to have to hand-code O/R mapping. We should be able to say, "I want to be able to do X," and have the tools take care of it all for us. In some ways, Java is still behind the tools that Smalltalk used to have. The future must hold tools that do more work for developers, allowing us to focus on solving business needs.
There are more criticisms out there, and Craig has been good enough to try to explain things to the critics. Check out the links at the end of this article, if you are interested.
JDO is also causing waves in the EJB forums. As soon as JDO came on the scene, a bunch of people were touting it as "what Entity beans should have been." Entity beans have always had a bad rap (maybe rightfully so), and many people thought it was obvious that Sun should scrap them as they are now and couple them with JDO. This never happened, and EJB 2.0 was released, supporting relationships, EJB-QL, and local interfaces. Rumors abound that Sun and the EJB group (BEA, IBM, Borland, Oracle, etc.) had spent a lot of money on Entity beans, and didn't want to scrap them, thinking that it would be "bad marketing" to come out and say "OK, Entity beans are not good." A lot of EJB developers are ignoring CMP Entity beans, and plugging the O/R mapping into BMP Entity beans. Where people were using JDBC at this layer "for performance," they are now jumping to JDO.
I still think there is a place for CMP Entity beans. The 2.0 version of the spec allows for decent performance, with the vendor being able to do a lot of optimizing behind the scenes. The days of Entity beans as distributed objects may be gone, and the best practice of having a Session bean front and Entity beans will be enforced with local interfaces. If this is the case, does the Entity bean need to be the component that it is today?
Whatever technology I want to use behind my EJBs, I still come back to the great tools out there now, which will generate my beans for me and offer high-performance engines. Working with TOPLink and CocoBase is a charm. If I never touch the code for an Entity bean again, I will be a happy man. I can just point at a database, select fields and stored procedures, and "Generate CMP bean" (or BMP, or whatever I want). I look forward to the year of the tools, as our standards mature.
JDO is a topic that everyone has opinions on. It will be great to see more implementations of the spec, and to see the technology mature. It has the potential to be used all over the enterprise, along with tools, to really help developers as they work with data.
Dion Almaer is a Principal Technologist for The Middleware Company, and Chief Architect of TheServerSide.Com J2EE Community.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.