Re: Why are serialVersionUIDs explicitly set in Exceptions?

[Bryce McKinlay]

Eric Arseneau wrote:

> > Since the computed values are the same as the explicitly set ones
> > I am wondering if we could not just remove them. It might hide bugs.
> > What do people think about it?
>
> You will find that for now the values may be the same, but if the algorithm
> changes later, or use on a different VM that the result is not the same.
> The reason for the UID is to identify an object uniquely regardless of VM,
> library version or any other variable that could affect the computation of
> the UID value.  So a first crack may be to let the environment produce one,
> but then turn that out into an explicit set.  It is the only way to
> guarantee that the value will always be the same.

The algorithm for calculating the UID is explicitly specified as part of the
serialization specification, isn't it? 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.

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.

regards

  [ bryce ]