-----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]
