Re: serialVersionUID fixes

[Warren Levy <WarrenL at cruzio dot com>]

Mark Wielaard wrote:
> 
> I assumed that most/all libgcj hackers are also on the Classpath
> mailinglist, but if that is not the case could people please check that
> Hacking Guide to see if there are things in it that are different from
> the way they should be done in libgcj and/or if things that are done in
> libgcj are not in the Classpath Hacking Guide? Hopefully we can make
> that document as usefull as possible to all GNU java hackers.

Don't presume that your assumption is invalid due to my email ;-).  
I'm actually on the Classpath mailing list also and I do seem to recall
seeing this go by, so I'm the one to apologize for not following it
more closely.  Java hacking has unfortunately been a background task
for me since parting ways with Red Hat.

>     Sun has produced documentation concerning much of the information
>     needed to make Classpath serializable compatible with Sun
>     implementations. Part of doing this is to make sure that every class
>     that is Serializable actually defines a field named serialVersionUID
>     with a value that matches the output of serialver on Sun's
>     implementation.

Actually, this was (and hopefully, still is) not necessary in libgcj.
A fair bit of work was done in both the compiler and the library to ensure 
that the generated .class files would have calculated serialVersionUID values 
that matched Sun's values (without having to explicitly set them).  We
realized that writers of Serializable classes would not be likely to
set serialVersionUID in their own classes (especially if they were migrating
from using Sun's JDK to gcj), yet they'd still expect that their classes be 
serialization compatible with the same source compiled with Sun's compiler.

About 2 years ago I had run serialver on Sun's packages and used a comparable 
tool to generate the values for libgcj and diff'ed them.  This was all after 
pouring over the Sun doc/specs at 
http://java.sun.com/j2se/1.4/docs/api/serialized-form.html 
and http://java.sun.com/j2se/1.4/docs/guide/serialization/ (well, actually
it was the JDK 1.2 versions at the time) and making the libgcj classes
compliant to the entries in the "serialized-form" doc.  By that point, there 
were few classes in libgcj that were generating different serialVersionUID
values and discrepancies typically highlighted real libgcj/JDK compatibility 
issues.

If serialVersionUID is added to all libgcj classes without first checking
that the correct value is already generated (or worse, if it is there and 
someone later makes changes to the libgcj source that masks a different 
serialVersionUID that would be generated), we won't be able to catch true 
serialization divergences.  We'd simply be masking problems.

For these reasons I was very loath to set serialVersionUID without
first making sure it was absolutely necessary in a particular class;
hence my question to Michael about setting serialVersionUID in his patches.
--warrenl