On Thursday 13 January 2005 05:37, Vadim Gritsenko wrote: > I am of opposite opinion. If no effort is made to preserve compatibility, > no serialVersionUID should present. Moreover, serialVersionUID should be > added only when making incompatible change and doing an effort to preserve > compatibility.
Perhaps we are in total agreement after all... Only real difference is that I expect compatibility to be preserved, and you assume it won't be. :o) Preserving compatibility should IMHO always be a requirement for any Serializable class, unless it is 'contracted' that it is not. AFAICS, only in the case of RMI (or similar) with dynamic classloading enabled, do you have the 'short-term-ness' that allows you to ignore evolutionary compatibility. Maybe you can find other cases, where an object is serialized and guaranteed to be deserialized by the same version of the class. By emitting serialVersionUID, you force any change to a class signature to break serialization compatibility, whereas with it in place, many (I would even say - most) changes are compatible. I agree the trick is to raise the level of awareness of this contract, since it is often ignored and nasty runtime problems as a result. Cheers Niclas
