Re: Why are serialVersionUIDs explicitly set in Exceptions?

[Jochen Hoenicke]

On Feb 20, Bryce McKinlay wrote:
> 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 algorithm for calculating the UID is explicitly specified as part of the
> serialization specification, isn't it? [...]

Yes it is.

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

The serialVersionUID doesn't only depend on the serialized fields, but
also on the non private methods and non private static/transient
fields.  So if you add a method, the UID changes, while the serialized
form keeps the same.

Normally exceptions have a very canonic set of methods, so relying on
the default UID is quite safe.  But IMHO the existance of an explicit
serialVersionUID in a serializable class is a good indicator that
someone checked that the serial form is correct.

  Jochen