Please direct your comments on this JSR to: jsr-057-comments@sun.com. Remember to identify the JSR you are commenting on somewhere in the subject of your e-mail (this is JSR-000057).

JSR 000057 Long-Term Persistence for JavaBeans™ Specification

Section 1. Identification

Submitting Participant: Sun Microsystems, Inc.

Name of Contact Person: Philip Milne

E-Mail Address: philip.milne@eng.sun.com

Telephone Number: +1 408 863 3105

Fax Number: +1 408 343 1681

Section 2: Request

2.1 Please describe the proposed Specification:

A specification for providing long term persistence for JavaBeans™ within the Java™ platform. These APIs will be suitable for creating archives of graphs of JavaBeans™ as textual representations of their properties.

It is envisaged that:

• Other than implementing the ObjectInput and ObjectOutput interfaces, the new implementations will be independent of the serialization framework that was introduced in JDK 1.1 and will have no effect on the backward compatibility of serialization code that was written to the original specification.
• It will be possible to take complete control of the way that a JavaBean™ is archived by writing BeanInfo for the classes involved.
• The APIs will allow third parties to provide BeanInfo for their beans - thereby moving the responsibility of persistence from IDE vendors to the vendors of the JavaBeans™ themselves.
• By default, the archives produced by the new input and output streams will be version resilient by being written in terms of the public APIs of the JavaBeans™ rather than their private implementation.
• A standard will be developed so that designs can be saved in formats which are not tied to the tools that created them.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Standard Edition.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification is intended to create a standard for designs that is portable between IDEs. This will allow developers to use the IDE that best suits the task at hand rather than having to standardize on an IDE at the start of a project. The introduction of a standard format will allow designs to be exported from one product and imported into others. This is intended to be much like the way word processors now have an option to import and export their contents as HTML documents.

2.4 Why isn't this need met by existing specifications?

The serialization support introduced in JDK 1.1 was designed as a framework which could house alternate encodings. In particular the ObjectInput and ObjectOutput interfaces were provided so that they could be implemented by streams supporting new encodings - such as the XML document format whose popularity postdated the introduction of these APIs.

The only concrete implementations of these interfaces, the ObjectOutputStream and ObjectInputStream classes, provided support for reading and writing binary streams and have been most successful in distributed environments where the versioning issues between the libraries loaded into different VMs can be interrogated and sometimes controlled at read/write time.

In the case of writing archives, the set of design considerations is very different - in particular the versioning issue and the resulting robustness of the files generated is of paramount importance. Spending extra time during the generation of archives, to ensure that they are encoded in a manner which is resilient to possible changes in the implementations of the classes involved, is something which is essential in the "archiving" domain yet arguably inappropriate in the domain of interprocess communication.

This proposal, therefore, is designed specifically to address the long term persistence problem for JavaBeans™ and to lead to implementations which are complementary to the implementations which currently exist in the Java™ platform.

The existing serialization framework will be used to house the new input and output streams, both of which will implement the same interfaces as the existing implementations.

2.5 Please give a short description of the underlying technology or technologies:

Many IDE vendors have moved from using serialization to using code generation to save the designs that are created in their tools. One key advantage of using code generation is that it causes the designs to be encoded in terms of the public APIs of the Beans they contain. When designs are saved this way they tend to survive version changes in the underlying libraries. These same design principles are used in the new input and output streams with the consequence that archives not only survive changes in the versions of the libraries they depend upon but, uniquely with these new techniques, produce portable documents that may be used by different IDEs.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

java.beans

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

Because archives are represented as text they provide an opportunity for alternative techniques to be used to internationalize the applications that use them. Some of these techniques have proven extremely popular in other environments.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No. The existing serialization mechanisms will not be impacted by these additions and will continue to be supported.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Investigative, proof-of-concept implementations have been studied by the Swing Team over the last year. The results, and any useful implementations will be provided as input to the JSR expert group on request.

Articles on the experimental implementations can be found here.