Speaking of ODMG and Java

An interview with Ericsson’s David Jordan…

by Doug Barry
DB Prog, & Design – September 1998

In previous columns, I have pointed out that the ODMG Java binding is the only industry standard for Java object storage. This month, I’d like to present an interview with David Jordan, an expert on both Java and object storage, to give you a closer look at this very hot topic.

David recently joined Ericsson as a Consulting Engineer in Research Triangle Park, North Carolina. Prior to Ericsson, he was at Bell Laboratories for 15 years. David’s career has focused been databases and object technology. He was appointed a Distinguished Member of Technical Staff at Bell Labs for his contributions in these areas. David is the author of C++ Object Databases, published by Addison-Wesley. Currently, he serves as the Java and C++ editor for the Object Data Management Group (ODMG).

Java and ODMG: A Strong Play

Doug Barry: Thanks for taking the time to talk with us. Please tell us about your work and how the ODMG standard is important it.

David Jordan: I am responsible for database technology for a Java-based wireless platform under development at Ericsson. We need to store our Java object models. ODMG is really the only standard in the industry that seamlessly integrates application classes with a database. This Ericsson platform will eventually be marketed to third-party software developers, who expect and rely on standard APIs.

Barry: How are you involved with ODMG?

Jordan: I serve as the editor of the C++ and Java chapters of the ODMG standard. I am also active in the Object Query Language (OQL) working group.

Barry: In your opinion, what makes the ODMG standard significant to the industry?

Jordan: Standard interfaces are very important – people are very reluctant to use proprietary interfaces these days. The ODMG is the only standard for directly storing objects in a database. Most applications need to store their data in a database and many are now based on object technology. Trying to use objects with a database that does not support them is very cumbersome. Having one object model shared by the database and the applications is simpler and increases development productivity.

Barry: What are the benefits of the ODMG standard from an application programming perspective?

Jordan: The ODMG standard provides an interface that supports database transparency. An application’s classes define the database schema. Since the database software understands the application classes, it can provide a direct mapping from the database into a cache it manages in the application memory. As application software navigates among related objects, the database software maps them into the cache. As objects in the cache are modified by the application, the database software tracks modified objects and writes them back to the database at transaction commit time. This client cache management creates a higher degree of coupling between the database and the application, making standardization very important.

Barry: And from a technical manager’s viewpoint?

Jordan: Since multiple vendors are supporting the same interface, your risks are reduced. Your software becomes more portable across implementations and it is easier to find staff that already knows the interface. When there are multiple vendors supporting the same interface and competing for your business, you have greater leverage in business negotiations with them.

Barry: Who has the most urgent need for ODMG storage?

Jordan: There is an immediate benefit to anyone developing applications with an object-oriented programming language like C++ or Java. Applications that navigate known static relationships that exist among objects are usually better off with an object storage than a relational database. Since there are implementations of the ODMG Java interface for both relational and object databases, it provides a standard interface that does not commit you to an object or relational database.

Barry: How do you think ODMG plays in the enterprise Java arena?

Jordan: Java has gained market acceptance very rapidly, and the vast majority of enterprise applications use a database. Anyone building enterprise applications in Java will need to map their objects into a database, and ODMG is the only standard Java interface for storing objects. All the other choices available in the industry are either proprietary, supported by a single vendor, or they do not directly map between the database and an application’s Java classes.

The ODMG Java binding has been endorsed by Sun and Sun even developed its own product called Java Blend that implements the binding on relational databases. The people building completely new applications in Java now with entirely new databases are not constrained by database choices made a decade ago. They have the luxury of being able to choose the best database technology available today for Java. That technology is based on the ODMG interface, whether it is built on a relational or an object database engine.

Working with the ODMG Java Binding

Barry: How does a Java developer actually use ODMG data storage? Is there anything special involved, like learning another programming language?

Jordan: No, you don’t need to learn another language. You just use Java to access and manipulate a database. When you use an ODMG implementation, a schema capture tool processes your classes at the source or bytecode level. You have to tell the schema capture tool which Java classes will have instances stored in the database. And you must use vendor-provided collection classes that conform to the ODMG specification. You use a Database class to open and close a database and a Transaction class to begin and commit transactions. That’s about it, since it directly understands your Java classes and can map instances between the database and memory. It just cannot get any simpler than this!

JavaSoft JDK 1.2 Collection Classes Bring Standardization

Barry: Why are collections so important to developers writing database applications in Java?

Jordan: Collections are used to specify relationships among objects – they are important when writing any application in Java. Your Java models in memory use them and you want to be able to store them and access them from the database.

Barry: What’s significant about JavaSoft’s addition of collection classes to JDK 1.2? Weren’t collection classes available before?

Jordan: JavaSoft had the Vector and Hashtable classes, but applications need more than these –collections like lists and sets. JavaSoft has added a set of collection interfaces and classes in JDK 1.2. They are also available under a different package hierarchy for JDK 1.1 environments.

Barry: Weren’t there third party solutions available? Why not use those?

Jordan: There were some, like the Java Generic Library (JGL) from Objectspace. But most Java developers I know were anticipating and waiting for collections from JavaSoft. Now that they are available in the JDK, it would be hard to justify any other choice.

Consider the history of C++ in this area. The lack of standard collection classes for C++ had a major negative impact on development organizations. In the very early days of C++, organizations had to develop their own collections. Third-party libraries eventually were available, but they never became ubiquitous because they were not considered part of “core C++” and they imposed an extra cost. Eventually the ISO C++ Standard Template Library (STL) was designed and provides collection classes, but it has only been available the last few years. C++ application development would have benefited greatly if a collection library like STL had been available sooner.

Barry: Why is it important that ODMG has revised the ODMG Java binding to support the JDK 1.2 collection classes? Didn’t the ODMG Java binding already have collections?

Jordan: Yes, the ODMG had its own set of collection classes released in May ’97. Unfortunately, JavaSoft’s schedule for releasing collections did not correspond to ODMG’s schedule. It is very important to support the JDK 1.2 collection interfaces because they will be ubiquitous. People will use these collections throughout their object models. Many Java application frameworks will assume the presence of these interfaces. By adopting these collection interfaces, ODMG will gain rapid acceptance and the application models built with ODMG will plug right into the frameworks that assume the JDK 1.2 collection interfaces are available.

Barry: Has the ODMG Java binding changed significantly to support the JDK 1.2 collections?

Jordan: Actually the changes are minimal, thanks to Rick Cattell of JavaSoft. Rick chairs the ODMG Java working group. At JavaSoft he got the developers to design their collections with interfaces very similar to ODMG’s. Only a few minor differences exist between the original ODMG collections and the new ones, which directly extend the JavaSoft interfaces.

Barry: What are the implications for ODMG database vendors?

Jordan: They will all support the same interfaces. Before ODMG, every database vendor had their own proprietary collection interfaces. This locked in users and it made many potential users reluctant to adopt the technology. By using standard interfaces, dictated by JavaSoft, the object database vendors’ market should expand rapidly. I believe the number of developers adopting the technology will increase by a couple orders of magnitude. Especially since the same ODMG interfaces are supported on both relational and object databases.

Barry: What are the implications for tool vendors? In practical terms, what will this mean for CASE tools? GUI tools?

Jordan: Historically, CASE and GUI tool vendors have provided good support for relational databases. The object database market had been so much smaller and proprietary relative to relational database technology, so the tool vendors did not support the technology. But that will change now, they can support both technologies with the same interface. CASE tool vendors will support the JavaSoft collection interfaces in their UML modeling environments. GUI tools that provide interfaces to show collections of things will assume the application is using the JavaSoft collection interfaces. Tools will also appear that directly support the ODMG standard.

Barry: Could you briefly describe the new JDK 1.2 collection classes and provide an example of how they might be used?

Jordan: There are collection interfaces, each with one or more collection classes that implement the interface. The classes supporting the same interface typically have different underlying implementations, with different performance characteristics for the operations. The developer can choose which implementation best meets their needs. What the ODMG has done is to define collection classes that implement the JavaSoft interfaces and support storage in a database.

A base interface called Collection supports generic operations common to all collections. A Set interface extends Collection and provides an unordered collection that does not have any duplicate values and provides efficient lookup of an element. This represents the set concept found in mathematics. A List interface also extends Collection and has the kind of operations you would expect in a linked-list. A Map interface provides a dictionary-like object that provides a mapping from a key of some type to a value of some type. In addition, SortedSet and SortedMap collections allow iteration over their elements in a particular order. A comparison method provided by the user is used by the collection in its algorithms.

ODMG Java Futures

Barry: What’s on the horizon for the ODMG Java specification? What’s being developed? What else is needed?

Jordan: A few things are particularly relevant to collections. Today, collections are defined to store references to Object, yet they always contain references to instances of classes derived from Object. Parameterized types are very important so you can declare that a collection contains instances of a specific class or interface. From an analysis and design standpoint, this information should be specified once in a collection instance’s declaration. It should not be scattered throughout the code in the form of downcast operations, which could be valid or invalid. Specifying the element type in the declaration allows the compiler to enforce use of the right types with a collection.

Weak references, found in JDK 1.2, are another language feature that is very useful for object storage. They allow the object storage to better manage the in-memory cache it maintains for the application. At Ericsson, we would like them supported in Personal Java. They actually become even more important in the small footprint devices that will use Personal Java.

Particular bytecodes require special processing to support persistence in a transparent way. Today implementations either have a Java source preprocessor, Java bytecode postprocessor or a vendor-specific JVM that adds the needed functionality. With the preprocessor and postprocessor, the size of the bytecodes is increased by the extra logic that is added. Placing the logic in the JVM results in only one copy of the extra code shared by all the relevant bytecodes. But people are reluctant to being locked into a single vendor’s JVM and it can be burdensome on the vendor to port their JVM to lots of hardware environments. Another technology being considered is a specialized JVM provided by JavaSoft that calls special methods whenever the JVM processes the relevant bytecodes. Each database vendor would provide an implementation of these methods, but everyone would share the same JVM. This would allow more seamless persistence and avoid the negative aspects that exist with the preprocessor, postprocessor, and vendor-specific JVMs. But JavaSoft must be convinced this is worthwhile.

Barry: In general, where would you like to see the ODMG do additional work? What needs to be improved? What needs to be created?

Jordan: In the current specification, applications have to import vendor-specific packages. I’d like to see a standard package name hierarchy. This will provide a much higher degree of portability. One drawback would be that an application could only use one database vendor in a given JVM environment. But for a very high percentage of the applications being developed this will not be an issue.

To date, most of the ODMG participants have been vendors with relatively few users of the technology. The recent membership changes at ODMG allow users to become voting members and to participate in driving the direction of the standard. I would like the user community to become more active in ODMG – in so doing, they will help themselves and everyone else using the technology.

Barry: Thank you for taking the time to talk with us.

Jordan: Thank you.

For more information about the ODMG, visit its web site at www.odmg.org.

Douglas Barry has worked in database technology for more than 20 years, with an exclusive focus on the application of database technology for objects since 1987. He is the author of The Object Database Handbook (John Wiley & Sons, 1996), The Object Storage Fact Book (Barry & Associates, 1998), and The ODBMS Implementation Stories (Barry & Associates, 1996). He also serves as the executive director of the ODMG. You can email him at dkbarry@odbmsfacts.com. His Web site is www.odbmsfacts.com.