Long-Term Persistence: An Update

By Philip Milne

Almost a year ago we published an article about an experimental implementation of a reliable, long-term persistence strategy for JavaBeans. This article brings you up to date, telling you what's happened since the first article was published. Most notably, we've used the Java Community Process (JCP) Program to pull together a community-wide effort to arrive at a formal specification of the persistence mechanism for J2SE v 1.4.

If you're not familiar with our persistence work, you can learn about it by reading the first persistence article and the description of the specification request. This article has the following sections:

The JCP and JSR 57

JBuilder (Borland/Inprise)
VisualAge for Java (IBM)
VisualCafé (Symantec/WebGain)
AppDev Studio (SAS)
Forte for Java (Sun)

One of most important achievements of the expert group was to focus our efforts towards practical cases and the problems that often get left out of abstract specifications. We avoided expanding the design with a plethora of new features to accommodate deficiencies. Instead, we focused our efforts on factoring the API so that each internal assumption was made in one place and could easily be replaced by subclassing or delegation. The surprising result is that the revised API, though applicable to a much wider range of scenarios than we had initially foreseen, is significantly smaller and simpler than the original API.

The JSR 57 specification and reference implementation is available for download. Please note that the reference implementation contained in that bundle requires the 1.3 version of the Java 2 Platform, Standard Edition (J2SE v 1.3).

JavaOne 2000 Demonstration of GUI Builders

In the demonstration, a simple design was created in Borland's JBuilder (running Sun's J2SE v 1.3 beta on Windows NT) and saved as an XML document. This document was then imported into both IBM's VisualAge for Java (running IBM's J2SE v 1.2.2 on Windows NT) and Sun's Forte for Java (running Sun's J2SE v 1.3 beta on Linux). The design was then edited in Forte for Java, saved, reimported back into JBuilder, and edited again to show a complete cycle.

This is the first opportunity we've had to publicly thank all the people from Borland, IBM, and Sun's Forte for Java team not just for joining us on stage to demonstrate the persistence APIs working in their tools, but for finding time from their very busy work schedules to help with the preparation work in the weeks leading up to JavaOne -- many thanks!

Major Changes

To all those of you who looked into that code base in detail, here is a list of the substantial differences between that implementation and the new specification.

Public API now exists for taking complete control of the way instances of a particular class are encoded. For more details on this please see the definitions of the new Encoder and PersistenceDelegate classes in the specification.
Only one file format is supported -- an XML format. As before, all meta information pertaining to the special persistence requirements of a particular class is syntax independent so that other formats can easily be supported, either by creating a new encoder/decoder pair or by translating the output streams using pre-/post-processing filters. The XML schema used in the last article was changed to use lowercase names for all tags and attributes in the schema. The "aliasing" scheme for classes was removed because of a requirement to support similarly named classes in different packages.
The classes that read and write files (or, more precisely, streams) are now called XMLEncoder and XMLDecoder. They no longer implement the ObjectOutput and ObjectInput interfaces because some of the methods in those interfaces aren't appropriate for XML streams. Instead, XMLEncoder implements only one ObjectOutput write method: writeObject. Similarly, XMLDecoder implements only one ObjectInput read method: readObject.
The XMLDecoder class uses the new JAXP parsing API, which will be included in J2SE v 1.4.

In response to our last article, we received hundreds of emails with ideas for changes and bug fixes. As those of you who wrote to us know, we replied to most of the mail and often found ways to incorporate the suggestions into the specification. As always, we'd like to thank everyone who wrote to us for their contribution to this effort.

Please send any comments, criticisms, or ideas you have on this work to the following alias: java-beans@eng.sun.com.

Updated Example: Bean Builder

Note: You will need to install J2SE v 1.3 to use this demonstration program.

Like the original BeanBox, this builder is not a commercial product and is intended to serve only as an example of how these techniques would be used in a real IDE. This builder takes the original BeanBox concept forward a little by showing not just how the properties of a single Bean can be manipulated, but how a group of Beans can be "wired up" to make the user interface of an application.

To try out the builder, download beanbox.zip (~ 880 KB), unzip it, and follow the instructions in the docs/readme.html file.