he Java Data Objects (JDO) 1.0 specification, accepted in May 2002, was the first standard, data store-neutral specification designed specifically for Java object persistence. Java developers already had many persistence options available to them at the time, including serialization, JDBC, entity beans, object databases, and O/R mapping tools, but these solutions all lacked features, ease-of-use, or standardization. So JDO rapidly gained acceptance among developers and IT managers.
At the JDO 2.0 Specification kickoff meeting held in Washington DC in August, the JDO Expert group, which consists of commercial and open-source JDO vendors, JDO consultants and trainers, end customers, and vendors with alternative technologies, identified a number of topics as critical to continuing the success of Java Data Objects. This article explores some of these topics and discusses the value of each to Java developers and JDO customers.
Author’s Note: The JDO 2 JSR is currently under active development, so some of the features discussed in this article may change between now and the final version.
Object/relational (O/R) mapping, a tremendous pain point for Java developers, is very important for JDO’s acceptance among the general programming public. In fact, O/R mapping currently is the most popular use for JDO. In JDO 2.0, the specification team identified two main goals for JDO implementations that map objects to a relational database:
- A standard metadata form for representing class mappings to relational databases
- A standard runtime behavior for such classes
Because of its independence from any type of back-end data store, JDO 1.0 left O/R mapping to each vendor. However, the latest JDO spec will standardize the metadata and the runtime behavior to provide increased portability and reduced risk for organizations that use JDO for O/R mapping.
For those already using JDO implementations for this type of mapping, JDO 2.0 doesn’t require any major change in functionality, although some of the specific metadata will change. Most vendors likely will provide a conversion tool to ease the burden of these changes on their customers.
The JDO 1.0 standard requires all classes to be concrete. JDO 2.0 includes two new features that expand the scope of JDO persistent types to include interfaces:
- Querying on a persistent interface retrieves matching instances from all persistent classes that implement that interface.
- Users can create an all-interface data model for rapid prototyping and development. The JDO implementation will dynamically generate the necessary implementing classes and data members based on the interfaces’ JavaBeans-style get and set methods.
These features can decrease development time and increase the level of abstraction available to JDO users. The robust handling of interfaces in queries and relations allows the use of complex, decoupled object models. Additionally, this effort opens the door to additional JDO implementation strategies, which grows the JDO community as a whole.
A common procedure for a Web or enterprise application is “detaching” objects from all server resources, modifying them, and then “attaching” them again. For example, a Web application might store persistent data in a user session during a modification based on a series of Web forms. Between each form request, the Web container might serialize the session, requiring that the stored persistent state be disassociated from any other resources.
Similarly, a client/server or EJB application might transfer persistent objects to a client via serialization, allow the client to modify their state, and then have the client return the modified data in order to be saved. This is sometimes referred to as the data transfer object pattern, and it allows fine-grained manipulation of data objects without incurring the performance overhead of multiple remote method invocations.
JDO 2.0 directly supports these scenarios with the new attach and detach APIs, which make using JDO in Web, client/server, and EJB applications significantly easier. The detachment capability eliminates yet another piece of infrastructure coding for JDO developers. Developers will be able to use their JDO instances as data transfer objects, eliminating the need to perform a mapping from JDO instances to data transfer instances.
Architects who prefer to use their own data transfer objects also benefit, as this new capability automates transactional consistency checking across a business transaction that might span multiple JDO transactions.
JDO Query Language Improvements
One of the biggest knocks on the JDO 1.0 specification was its lack of aggregate support in JDO Query Language (JDOQL). Aggregates include things like sum, min, max, average, count, etc. JDO 2.0 adds aggregate support to JDOQL. Additionally, JDOQL’s support for various string-related methods and math functions will improve.
JDO 2.0 also offers named query support, providing a standardized mechanism for statically defining queries. This benefits enterprise users who want a simple way to ensure that all their non-dynamic queries are valid at deploy time.
JDO vendors previously supported this functionality only through proprietary extensions. Customers considering JDO can take comfort in knowing that these basic reporting functions will be available in a standard manner with the 2.0 spec.
JDO Spec Compatibility
JDO 1.0 included implementation details that made it difficult for some existing persistence vendors to adapt their products to the JDO standard. JDO 2.0 drops these details, focusing on functionality rather than implementation strategy. More vendors will be able to adapt their products to JDO, and as a result end users will have more choices and less overall risk in choosing JDO.
The Best of 1.0 Plus Much-needed Functionality
JDO 2.0 looks to be a strong standard that will meet almost all requirements that developers look for in an object persistence API. It builds on the ease-of-use and core functionality provided in JDO 1.0, taking the lessons learned in the 18 months since that specification was standardized and adding some much-needed functionality. Additionally, JDO 2.0 acknowledges the major uses of JDO (object/relational mapping and Web-based, client/server, or EJB applications) by providing specific functionality for developers working with these specific technologies.
Customers will receive a mature standard for object persistence that reduces the risk of using non-standard technologies. As a result, many vendors?even those who have previously publicly opposed JDO?likely will provide support for JDO.
Developers spend an average of 20-40 percent of their total coding time on object/relational mapping and object persistence issues. The Java Data Objects standard has been successful because it greatly reduces that effort. Strapped development shops can focus on business logic rather than infrastructure details, and JDO significantly reduces the ongoing maintenance of applications.