Saving Pure Runtime Objects

#summary How to persist objects that are "pure runtime"

(Btw, here is a library the implements a lot of tricks to bypass JVM limitation when instantiating and initializing the state of an object, it might be useful in this context: http://objenesis.googlecode.com/svn/docs/index.html)

Pure runtime objects are such that are instantiated by the run-time system, usually large, contain mainly/only runtime relevant data etc. Clearly, it would be a stretch to attempt to serialize their full state (even though this would be possible in theory). Our general strategy in dealing with this situation is to bind such objects to an expression that can be evaluated at runtime to produce them. So the general idea is: instead of storing the object, store the means to produce; then store a reference that is resolved by evaluating the expression that produces the value.

Now, some such objects can deemed "system level" and can't be bound to an evaluatable expression easily. The HyperGraphDB niche instance is such an object, or the top-level frame/canvas, or the HyperGraphPeer instance etc. So, here is an idea what could be done about them: store them as "runtime atoms" with a special purpose type. A handle to such a runtime atom means that the value of the atom is supposed to be available at runtime, in the cache already, initialized by some bootstrapping procedure or by the objects themselves. So to save an instance of something like this:

public class A { private HyperGraphPeer thisPeer; // .... }

The Java-HGDB type mapping facilities should first query the cache for atom corresponding to the 'thisPeer' Java object reference. If there's such an atom, its handle should be saved in that field through a regular symbolic HGAtomRef. When the A instance is brought back to live, the handle of the 'thisPeer' runtime object will be prepopulated in the cache already and it will be readily available.

The problem then reduces to the proper management of those pure runtime objects. And the solution actually makes sense in general: if an object has a member variable which is already an existing atom, it only makes sense to save the HGAtomRef, rather then a copy of the value of the atom!