Re: Why are serialVersionUIDs explicitly set in Exceptions?

[Warren Levy]

On Tue, 20 Feb 2001, Bryce McKinlay wrote:

> The algorithm for calculating the UID is explicitly specified as part of the
> serialization specification, isn't it?

Yes, it is.

> If field changes are made to a class
> where the UID was previously calculated automatically, then the UID must
> change, or the class must define readObject() and writeObject() in order to
> maintain compatibility with the existing serialization layout. If not, then it
> seems to me that the use of UIDs is just hiding possible incompatibilies.

Umm, I think there are cases where you don't have to have a readObject or
writeObject without breaking anything.  E.g. if you add new primitive
fields that you have a reasonable default/initialization value for if an
old object is read in.  Thus old objects read by the new class will be
fine and new objects read by an old class will be fine (the new primitive
fields will be ignored).  Though this is a contrived case, I think it
should work (and would require the UIDs to be the same).

In general though, I agree that a readObject/writeObject pair is typically
necessary to prevent incompatibility.

> I don't think that classes that do not have readObject()/writeObject() should
> have an explicit SerialVersionUID. If a VM is calculating a different UID for
> the class, then either the serialized form really isn't the same (in which
> case the UIDs MUST be different), or the serialization implementation is
> broken.

I agree.  Though in the case of libgcj, I found that I had to include a
few UIDs to work around a problem with the classes being generated by the
compiler since that was causing a different UID to be calculated (IIRC it
was a problem with init methods being generated when Sun's javac didn't).
I think I marked these with FIXME's (though I may not have done all of them).
Definitely a kludge I wanted to remove as soon as possible.

Bottom line though is that UIDs shouldn't be included when they aren't
needed.
--warrenl