>
> * If I don't set any serialVersionUID (and turn off the compiler
> warning), then each time I compile a class a new,
> automatically-generated serialVersionUID is created by the compiler (or
> some part of that pipeline). This creates the potential problem that if
> something was serialized out using a previous build, and then serialized
> in using a later build, there will be an error because the UID's won't
> match.
Correct. Also note that if you were to use the velocity generator,
you'd be in the same boat... it just explicitly says what the JVM
would generate automatically. Handy for bridging the gap between JVMs
that don't serialize the same (usually these are documented as JVM
bugs), but otherwise, it just shuts up a warning.
>
> * If I do set a serialVersionUID, then the assumption is made that my
> class will be smart enough to know how to convert older versions into
> newer versions. I assume your class has to implement some method to
> handle this situation.
>
Actually, you only have to override readObject if you do something
that would break compatibility - usually removing fields that
previously existed or changing data types. We manage serialVersionUIDs
for a bunch of classes, but only override readObject in a couple..
Cris
This archive was generated by hypermail 2.0.0 : Mon Feb 13 2006 - 21:00:56 EST