Re: Serialver [was Re: [PATCH]]

[Eric Blake]

Brian Jones wrote:
> 
> The Jikes developer discussion list recently had a small thread about
> this and at least according to my understanding they think the
> specification is incomplete such that it cannot be implemented
> correctly by a compiler to exactly match Sun's compiler.  Therefore
> when Classpath is compiled with Jikes it is incompatible with any Sun
> VM.  I wish Eric Blake could comment further to explain to us a bit
> more if I've misrepresented in some way.
> 
> Brian
> --
> Brian Jones <address@hidden>
> 

I'll do my best, although I cannot guarantee a satisfactory answer.  As
I understand it, the serial version number of a class is based on some
hashing algorithm that uses the either the contents of the constant
pool, or perhaps just the method names, in the order they appear in the
.class file.  But since jikes sometimes emits methods with different
names, or in a different order, than Sun, the hash algorithm will
generate a different result for classes generated by the different
compilers.

As an example, if you compile:

class Foo { void bar() {} }

javac and jikes will emit bar() and <init>() (the implicit constructor)
in opposite order from one another.  Another example is accessor
methods:

class Outer {
  private int i;
  class Inner { int j = i; }
}

javac emits an accessor named access$000(), while jikes uses
access$0().  And even if jikes and javac emitted the same methods,
simply listing the methods in a different order in the .java file would
cause them to be emitted in a different order, again changing the UID.

Therefore, the safest course of action is to explicitly have a
serialVersionUID for all Serializeable classes, rather than relying on
the implicit UID generated by the undocumented hash behavior.  Note that
the serialVersionUID field should be a private variable (Sun's serialver
neglects this fact, making it seem like package-private is acceptable),
so that it is not inherited by other subclasses in the same package.

However, I doubt that java.io.Serializable needs a serialVersionUID, as
it is an interface.  You only serialize Objects, not interfaces, so it
makes no difference whether Serializable has a UID.  Besides, as pointed
out earlier, the jikes-compiled Classpath version has the same UID from
Sun's serialver, simply because there ARE no methods or fields, so the
hashing function has no incompatibilities with Sun's version.

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer