Phil Steitz wrote:
Yes, I was thinking from the standpoint of serializing in the old version and deserializing to the new version. I see now you are thinking in the other direction (which is as valid). I suspect the optimal way to manage this in a compatable fashion (and not until we feel the api is more stable) is through deprication and planned refactorings over more than one version release.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.
to clarify, it would make "de-serialization" incompatable.
Yes, if any incompatability arises we should alter serialversion ids, but, I think we should make this a responsibility of a "serialization manager" or one or more developers who are managing the test cases for serialization compatability. I think that developers shouldn't currently focus on if thier change will break serialization compatability. This way developement won't hindered by the developer focusing to heavily on compatability. As new versions are released, we can rate them on serialization compatability, as the library matures, then compatability will become more stable and it will be easier to up our efforts in maintaining it.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
I will gladly begin some efforts to review Collections serialization testing and work to implement something similar for math.
-Mark
-- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
