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)
Section 1. Identification
||Sun Microsystems, Inc.
|Name of Contact Person:
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
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
|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
|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,
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 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
|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
|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
|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
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
|The draft OPJ specification document and associated rationale form a basis for public discussion.