Sun rejects orthogonal persistence for Java

[Mark S. Miller]

At 10:23 AM 9/16/99 , shapj@us.ibm.com wrote:
>The normal argument is mistaken.  Data does not live in a vacuum.  If we 
>ignore
>persistence, we still must address the problem of data interchange: a bitmap
>must have some relatively universal representation understood by all graphics
>editors.  Thus, persistence does not eliminate the need for serialization 
>code.

I think we are all in vigorous agreement.  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.  In a capability context, the "program" is simply a set of 
coordinated objects, some of which have relationships to objects outside 
the "program".

On upgrade, not only must state be restored, but these relationships must 
be reestablished as well, and only in accord with our normal security 
principles.  These relationships involve both pointing-in and pointing-out, 
of course.  When such serialization-for-upgrade is also used for 
persistence, then all parties to such relationships are reestablishing 
their part of these relationships simultaneously.


-----------------------------------------------------------
Due to a bug (possibly at my ISP, but probably in Eudora 4.2.0.58), on 9/15
I lost 18 email messages.  If it's possible for you to check whether you
sent me something on that date, resending it would be great.  Otherwise,
please excuse my non-responsiveness to email you may have sent around that
time.  Sorry for the inconvenience, and thanks.

         --MarkM