Sun rejects orthogonal persistence for Java

[shapj@us.ibm.com]

> I think we are all in vigorous agreement.

Probably. I'm not sure, however, so I beg your indulgence while I test this
hypothesis.

>The upgrade problem, however, is a vastly more strenuous form
>of "data interchange" than that normally considered: the
>interchange, forward in time, of the semantically meaningful
>state of a program into future code for executing that
>program.

Indeed, but this usually isn't any different from content serialization for
interchange.  If we accept the argument that programs exist to manipulate (and
present) data, then the program does not *possess* semantically useful state qua
program -- only qua content.

The place where this potentially breaks down comes when we consider
object-structured content (as distinct from object-structured programs).  Your
program and my program may manipulate independent content having common
substructure, and the identity of this common substructure must be preserved
across serializations and while the other program potentially continues to
execute.

The difficulty is that such state *cannot* really be interconverted by
serialization, because the other program can always modify it while this one is
being upgraded.  It's not clear, then, how to ensure consistency in such
upgrades.

Fundamentally, the problem is how to freeze all of the right things during the
upgrade, and how to guarantee that the code which manipulates the object
upgrades consistent with the representation, all the while preserving identity.

Orthogonal persistence helps, but introduces difficulties when the upgrade
involves refactoring.  I do not know of an elegant solution to this in
principle.

Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085  (Tieline: 863)
Fax: +1 914 784 7595