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.

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.

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.