Re: serialVersionUID fixes

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Sun, 2002-10-06 at 12:21, Warren Levy wrote:
> 
> Perhaps this had already been discussed on the list, I must admit I
> haven't been as diligent in keeping up with the list as I should, nor
> have I had the opportunities I'd hoped to get back to hacking on libgcj
> so I may be a bit out of touch; if so, I apologize.
> 
> If there is a need to explicitly set a serialVersionUID in the code,
> it might be helpful to document/comment the issue(s) of why it was necessary
> to do so.  That would be helpful in code review, and for folks looking at the 
> code in the future.

This was discussed on the Classpath mailinglist and not on this one.
Sorry, we should probably announce Classpath policy decisions on this
list also. Anyway, the Classpath Hacking Guide now has the following in
the section on Portability:

    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. The reason for doing this is below.
    
    If a class has a field (of any accessibility) named serialVersionUID
    of type long, that is what serialver uses. Otherwise it computes a
    value using some sort of hash function on the names of all method
    signatures in the .class file. I'm not sure whether the methods are
    sorted first, or what the hash function is. The fact that different
    compilers create different synthetic method signatures, such as
    access$0() if an inner class needs access to a private member of an
    enclosing class, make it impossible for two distinct compilers to
    reliably generate the same serial #, because their .class files
    differ. However, once you have a .class file, its serial # is
    unique, and the computation will give the same result no matter what
    platform you execute on.

http://www.gnu.org/software/classpath/doc/hacking.html#SEC8

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.

Cheers,

Mark