Frequently Asked Questions about Orthogonal Persistence for Java

See also the the following explanatory papers:

• An Orthogonally Persistent Java
• Early Experiences with Persistent Java
• Orthogonal Persistence for Java - A Mid-term Report
• Orthogonal Persistence for Java - Specification

1. How does the functionality of orthogonal persistence for Java differ from that offered by Object Serialization (an API which is at the heart of RMI)? Where might it be used that Object Serialization could not?

   In short: they solve different problems.

   Serialization translates data (at some computational cost) into a portable format, suitable for wire transmission of RMI arguments, but also for "pickling" objects into ascii files. Objects must be recomposed (at more computational cost) before they can be used again. Furthermore, there is a certain loss of security, no crash-recovery, and no support for the kind of incremental reading/writing demanded by data-centric applications. In other words, it does not support large-scale application data persistence.

   Orthogonal persistence for Java has more in common with OO database (OODB) systems, such as might be realized by a full implementation of the ODMG Java binding. Both are suitable for maintenance of large and complex data structures in multi-user application environments, including server-based systems. Neither have the weaknesses mentioned above. Both might use RMI for distribution.

   ---

2. From a developer's perspective, what is the difference between using orthogonal persistence in a Java application vs. using JDBC or an object-relational mapping system, to get to a relational database such as Sybase or Oracle?

   Orthogonal persistence for Java does not address applications for which a relational data model and SQL are important; for such applications a solution involving a relational database is appropriate.

   On the other hand, if a Java application involves objects constructed at runtime, and if those objects are needed during more than invocation of the application, then orthogonal persistence for Java can simplify the developer's task immensely. Our paper Early Experiences with Persistent Java discusses four case studies of applications that profit from orthogonal persistence.

   In principle an object-relational (OR) mapping system could provide the same degree of transparency as orthogonal persistence for Java. However, in practice, all OR mapping systems impose constraints on acceptable code and/or require substantial modifications to the code.

   ---

3. My application uses AWT and does not run correctly when run from a persistent store.

   Unfortunately, despite much effort on our part, there are still aspects of AWT that PJama does not handle correctly. If you can supply us with the code, we would be happy to try to fix the problem. We strongly advise the use of the Swing components in OPJ applications as these maintain their state in Java objects, which makes them more reliable in the OPJ context.

   ---

4. Why does my application behaviour not reflect the changes that I make to my Java source code?

   When an object is first made persistent in a store, the class of the object, including the bytecodes is also made persistent and the object is bound to the persistent instance of the class. So when you make changes to the Java source code in the file system, and recompile, generating a new class file, it has no effect on the behaviour of the objects in the persistent store. Furthermore, all subsequent class resolution binds to the persistent class in the store, so any new objects will acquire the same (consistent) behaviour. Modifying the class in the persistent store requires the additional step of the opjsubst tool. During early development it is often simpler to delete the persistent store and recreate it from scratch.