2.1 Please describe the proposed Specification:

A specification for providing long term persistence for
JavaBeans within the JavaTM 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.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.