 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 57: Long-Term Persistence for JavaBeansTM Specification
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: JSR 57 provides streams to convert graphs of JavaBeansTM architecture to and from version resilient file formats (typically XML documents). Please direct comments on this JSR to the Spec Lead(s) Team
Original Java Specification Request (JSR) Identification | Request | Contributions Section 1. Identification Submitting Participant: Sun Microsystems, Inc. Name of Contact Person: Mark Davidson E-Mail Address: mark.davidson@sun.com Telephone Number: +1 408 343 1455 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 JavaTM platform. These APIs will be suitable for creating archives of graphs of JavaBeans as textual representations of their properties. It is envisaged that:
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
