serialVersionUID (again)

[Mark Wielaard]

Hi,

There was a small discussion on address@hidden (between Warren
Levy, Tom Tromey, Michael Koch, Eric Blake and myself) when some of the
newly added serialVersionUID fixes made by Michael were merged into
libgcj. Since I assume not everybody reads that list I give the summary
here (I hope one of the above people will correct me when I make a wrong
conclusion).

The specification for computing a Stream Unique Identifier
(serialVersionUID) when it is not declared in a class is given here:
http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/class.doc6.html

This algorithm is implemented in java.io.ObjectStreamClass and for a
Serializable class you can get the serialVersionUID by calling:

        ObjectStreamClass.lookup(Class).getSerialVersionUID()

Warren Levy has made sure that our implementation gets all the corner
cases right (or at least does the same as the Sun version) and that gcj
generates class files that contain as much as possible the same method
names as the Sun javac compiler does.

So the rule for libgcj was: If the serialVersionUID is different from
that calculated by the SUN JDK, then figure out _why_ it's different and
fix either the compiler, or the class method names, or the
ObjectStreamClass implementation and only if all that fails add a
serialVersionUID and make sure to add a comment why it is necessary.

But when we recently discussed the issue on this list (and as pointed
out again by Eric Blake in the above discussion) the synthetic method
names generated by different java bytecode compilers for e.g. inner
classes access to private variables of their outer class or to implement
the SomeClass.class construct are note the same. (Eric gives a nice
example in the following email:
http://gcc.gnu.org/ml/java-patches/2002-q4/msg00036.html.)

And we currently use either jikes or GNU gcj to compile GNU Classpath
which don't generate the same accessor method names.

What I don't understand is why it is so hard to specify the actual
accessor methods. Does anybody know why they were never clearly
specified?

If both Tom Tromey and Eric Blake say that although theoretical
possible, it is too difficult for us to ensure compatibility in the free
compilers with the proprietary Sun javac naming scheme and other
synthetic stuff I think that are current policy (always add
serialVersionUID if the class is Serializable) is a good one.

What do others think? Should we try to reverse engineer the naming
scheme? Or do we keep the current policy? Or we could even ignore being
serializable compatible with the Sun JDK till this is clearly specified.

Cheers,

Mark