Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 20: Orthogonal Persistence for the JavaTM Platform

Stage Access Start Finish
Rejected   11 Aug, 1999  
JSR Approval   20 Jun, 1999 28 Jun, 1999
Status: Rejected
Reason: This work duplicates functionality to be provided by JSR-000012 Java Data Objects Specification. Work on Orthogonal Persistence continued at SunLabs.
JCP version in use: 1.0
Java Specification Participation Agreement version in use: 1.0


Description:
Orthogonal persistence for the JavaTM platform (OPJ) would have provided persistence for the full computational model specified by the JavaTM Language Specification (JLS).

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
  Mick Jordan Oracle
Expert Group
  Oracle    

This JSR has been Rejected
Reason: This work duplicates functionality to be provided by JSR-000012 Java Data Objects Specification. Work on Orthogonal Persistence continued at SunLabs.

Original Java Specification Request (JSR)

Identification   |   Request  |   Contributions

Section 1. Identification

Submitting Participant: Sun Microsystems, Inc.
Name of Contact Person: Mick Jordan
E-Mail Address: mick.jordan@sun.com
Telephone Number: 650-336-6028
Fax Number: 650-969-7269

List of other Participants who endorse this JSR:

Prof. Malcolm Atkinson
Department of Computing Science,
University of Glasgow,
8-17, Lilybank Gardens,
Glasgow, G12 8RZ
Scotland
Tel: 141-330-4359
Email: mpa@dcs.gla.ac.uk

Section 2: Request

2.1 Please describe the proposed Specification:
Orthogonal persistence for the Java platform (OPJ) provides persistence for the full computational model specified by the Java Language Specification (JLS). Persistence is defined as the ability for the computation state to survive in stable storage, across multiple executions of a Java Virtual Machine and in the face of system and application failure.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
The specification is applicable to all Java platforms.
2.3 What need of the Java community will be addressed by the proposed specification?
The Java language provides the programmer with a simple but powerful object model, a strong type system, automatic main memory storage management and concurrency through lightweight threads. Within the closed world of an executing Java program, these properties are extremely useful, vital even, in the timely development of reliable and robust applications. However, at present the Java platform provides no satisfactory way of maintaining these properties beyond the single execution of a Java Virtual Machine. Instead the programmer must deal explicitly with saving the state of an application, using one of a variety of persistence mechanisms, for example, file input/output, object serialization or relational database connectivity, none of which approach complete support for the full computational model. This lack of completeness, while only a minor nuisance for simple applications, becomes a serious problem as application complexity increases. In effect, without orthogonal persistence, the full benefits of the Java programming model are lost because long-term data has to be defined using a separate model, which, because of its longevity, becomes dominant. Orthogonal persistence for the Java platform addresses these limitations with no changes to the source language and minor modifications to the specification of the Java Virtual Machine life-cycle. In effect, orthogonal persistence extends the automatic memory management of the Java platform to encompass stable memory.
2.4 Why isn't this need met by existing specifications?
None of the existing persistence mechanisms offer support for the persistence of the complete Java language specification. Although the Java Data Objects JSR proposes transparent persistence, the focus of that specification is on mapping Java objects to existing legacy data stores. In contrast, the goal of orthogonal persistence, while not precluding the use of legacy data stores as an implementation mechanism, is to maintain the illusion of a continuously executing Java program, in the face of planned and unplanned system shutdowns.
2.5 Please give a short description of the underlying technology or technologies:
We propose to extend the Java platform with the notion of a checkpoint operation, which atomically preserves the state of the computation in a persistent store that is associated with the Java Virtual Machine. The nature of the persistent store is not defined by the specification, though it will typically be on disk, but could, for example, be in flash memory. A checkpointed computation may be resumed. Some implementations may provide mechanisms for changing a checkpointed computation, to another JLS compliant consistent state, before resumption.

A checkpoint can be explicitly invoked by calling a method, or it can occur implicitly when the virtual machine exits. Objects become persistent by reachability, using the same rules as the JLS, but taking account of the transient modifier.

An API is provided for notification of checkpoints and resumptions, so that classes that manage state that is external to the Java computational environment, such as sockets, graphics, native code in general, etc., can take appropriate action.

It must be stressed that beyond the additional functionality provided by the checkpoint/resume mechanism, all other aspects of the JLS are unchanged. In particular, programs that do not exploit orthogonal persistence execute correctly on a Java Virtual Machine that supports OPJ.

OPJ sounds deceptively simple. We emphasise that the OPJ model requires a minimal API and minimal changes to the JLS. This is harder to achieve than persistence mechanisms which contain exceptions (to catch the unwary), sometimes unstated, sometimes justified in order to avoid implementation challenges, and sometimes a legacy of old application construction and persistence provision habits. We remove these exceptions, and provide a clean model of persistence to application builders and an implementation of that model with acceptable costs.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, com.something, etc.)
javax.op. In our current prototype it is org.opj
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
None in principle, although small configurations, e.g. no-disk or limited stable storage, present engineering challenges.
2.8 Are there any security issues that cannot be addressed by the current security model?
The continuous computation model provided by OPJ has the general implication that the security model is preserved across checkpoints, unless the program explicitly modifies it on resumption. Certain operations in the OPJ API might be candidates for checks by the security manager.
2.9 Are there any internationalization or localization issues?
As with security, the general implication is that the localization regime is preserved across checkpoints, unless the program explicitly modifies it on resumption. There are no internationalization issues.
2.10 Relationship to Existing Specifications
Java Object Serialization is the de facto persistence mechanism for the Java platform. However, it is more accurately viewed as a mechanism for copying object structures into a linearized format. It does not support the goals of orthogonal persistence since it does not preserve object identity or the persistence of static variables. Nor does it support the persistence of java.lang.Class, java.lang.Thread or java.lang.ClassLoader objects or, indeed, any object that does not implement java.io.Serializable. Nor does it scale to large numbers of objects.

The Java Data Objects JSR is more closely related to the OPJ JSR. However, it is principally concerned with defining a mapping between Java objects and external data stores that already define a different data model from the Java language. While these data models may be similar to the Java Data Model, in particular that defined by the ODMG, which is referenced in the Java Data Objects JSR, they are not identical and this inevitably introduces semantic changes and limitations on what objects may be persistent. Another important distinction is that the Java Data Objects JSR introduces the concept of transactional access to objects including implicit object locking. While this is an interesting area of research, transactions are not part of the Java data model and adding them is not a trivial undertaking. Finally, Java Data Objects permits explicit deletion of persistent objects, which is incompatible with the automatic storage management of the Java language.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
The existing JLS specification must be modified in the area of Java Virtual Machine entry and exit, to accomodate the additional life-cycle events of checkpoint and resume. Several APIs need similar clarification to distinguish the notions of "initialize" versus "resume" and "checkpoint" versus "finalize". In the current platform code, these notions are often mixed together. For example, static initializers contain both genuine one-time initialization and other actions that must occur on each resumption. Also, most finalizers are really fulfilling the checkpoint requirements when releasing external resources. Many core classes that deal with external state, e.g. AWT, RMI require modification to operate harmoniously with OPJ. However, the benefits of this are substantial to the application programmer, for example, it is possible to resume applications with the GUI state unchanged from that at the previous checkpoint.

The specification of the "transient" modifier, a natural and valuable facility in the support for orthogonal persistence has, unfortunately, been given a semantics that is specific to Java Object Serialization and sometimes incompatible with orthogonal persistence and the spirit of the intent in the initial version of the JLS. A resolution to this conflict is required.

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.
A document defining the proposed specification for OPJ exists and will be made publically available soon. Many papers describing the history and evolution of OPJ can be found on the SunLabs web-site. These provide useful background information and rationale for the design choices made in the proposed specification. An implementation of the previous OPJ specification is available under licence for research and evaluation purposes from SunLabs. A reference implemention of the proposed specification will be available in a few months.
3.2 Explanation of how these items might be used as a starting point for the work.
The draft OPJ specification document and associated rationale form a basis for public discussion.