-----Original Message-----
From:   Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent:   Tue 7/13/2004 7:13 AM
To:     Jakarta Commons Developers List
Cc:     
Subject:        Re: [math] Serialization redux


Mark R. Diggory wrote:
>>
>> [phil]
>>
>>> * Either drop or customize serialization for all classes in the
>>> univariate package (other than StatisticalSummaryValues),
>>> especially those in the moment subpackage. Default serialization
>>> ties us to the current physical implementation, which may well
>>> change as we optimize implementations.  For example,
>>> SummaryStatisticsImpl currently holds a (redundant) private field
>>> n. Removing this field after release would break backward
>>> serialization compatability. I will probably eliminate this field
>>> before release, but this is the kind of thing that makes me want to
>>> be conservative about serialization.  My vote would be to release
>>> 1.0 without serialization support for these classes.
>>
>>

>Not neccessarily, if you provided an alternate implementation (say use 
>the "n" found in the Sum object) then your new version would simply not 
>set the n field because it doesn't exist in this version, the new 
>version of SummaryStatisticsImpl's getN() would draw the value from the 
>instance of Sum instead. This is why using getters/setters to access 
>values is recommended so often in java.

If the field were deleted, then an old version receiving a new instance serialized 
without the field would initialize it to the default value (0) and getN() would return 
that (spurious) value.  See
http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp6678
for details on serialization compatible/incompatible changes.

A better example would be the change that I made recently to StandardDeviation, making 
it wrap, rather than extend Variance. That change would cause (default) serialization 
to fail.

Since no other committers have responded to this thread, I am assuming that all are OK 
with releasing serializable classes that may undergo serialization incompatible 
changes prior to 2.0.  While I do not like this, I agree that we need to get 1.0 out, 
so I can live with the compromise that we state clearly somewhere that there is no 
guarantee of backward serialization compatability, and we implement something like the 
[collections] serialization compatibility tests and change the serialVersionUIDs when 
incompatible changes are introduced.

Phil
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to