Re: serialVersionUID fixes

[Kresten Krab Thorup <krab at trifork dot com>]

I've been through many of these issues along the way since I've written 
an RMI/IIOP implementation for our J2EE product, so I'll pitch in my 2 
cents...

There are several challenges here:

(A) Given a .class file, be able to compute the SerialVersionUID in 
exactly the same way that the JDK does it.  
(B) Given a .java file, compile this [using gcc] into a .class file 
which given (A) produces the same result as if the same file had been 
compiled with Sun's javac.

(C) Redo Sun's JDK such that all .java files are equivalent with respect 
to the run-time computation of the serial version UID.

It seems that (A) should be entirely possible, and (C) is possible with 
a lot of hard work (using some kind of test suite).  The problem here 
really is (B), i.e. the compiler.  If the compiler is "broken" in this 
respect, then adding static serialVersionUID to all .java files is 
dangerous.   It does however, seem like the only viable option.  The 
question is how we can make it non-dangerous to do so.

[So why is it that the compiler is different, BTW?  I have only vague 
guesses, but I know that the algorithm (A) also involves hashing names 
and types of synthesized methods and fields.  Since all this is entirely 
complex and non-public information, it would seem like a bad choise to 
try to mimic javac...  ]

Sun's notion of Serial Version UID is a badly broken concept, since it 
depends on internal knowledge from the compiler.  So to come up with 
anything reliable, we have to invent our own automated compatability check.

If our check says that two classes are serializable-equivalent - then we 
will add the serialVersionUID as computed by Sun's JDK.  
If this is the setting, then the challenge is to determine this new 
notion of serializable-equivalence.

Kresten