Kaffe serialVersionUID bug?

[Stuart Ballard]

[warning - long post]
Hi,

I've just finished porting Japize (my public-API-dumper) to use the
Jode.bytecode library, which (a) can make a correct determination about
compiletime constants, and (b) makes it possible to run against classes
from a different java implementation.

I've been testing this to make sure that the results from the jode
version are identical to the results from the reflection version when
run against the same libraries, and I've found a few problems related to
SerialVersionUID calculations.

Firstly, it seems that a lot of Kaffe's serialVersionUID fields are
declared public rather than private (or at the very least
package-private).

Secondly, or perhaps as a result of the first bug, I'm getting duplicate
SerialVersionUID fields appearing in Kaffe's public API, which is
causing my code some confusion. Should getFields() return superclass
fields that are hidden by fields in the current class?

Thirdly, I'm finding that for most classes, the SerialVersionUID
calculated by my code based on the bytecode is not matching the
SerialVersionUID given to me by ObjectStreamClass. The code I am using
has been tested on every serializable class in JDK1.1.8, so I have some
confidence that it does give the right results. It's a port to
jode.bytecode of GNU Classpath's implementation. A few examples of
classes getting different results:

class java.sql.SQLException# has SerialVersionUID -3387516993124229948
in kaffe.japi but 2135244094396331484 in kaffe-jodek.japi
class java.sql.SQLWarning# has SerialVersionUID -3387516993124229948 in
kaffe.japi but 3917336774604784856 in kaffe-jodek.japi
class java.sql.DataTruncation# has SerialVersionUID -3387516993124229948
in kaffe.japi but 6464298989504059473 in kaffe-jodek.japi
class java.sql.Time# has SerialVersionUID 7523967970034938905 in
kaffe.japi but 8397324403548013681 in kaffe-jodek.japi
class java.sql.Date# has SerialVersionUID 7523967970034938905 in
kaffe.japi but 1511598038487230103 in kaffe-jodek.japi
class java.util.mime.MimeTypeParseException# has SerialVersionUID
-3387516993124229948 in kaffe.japi but -4890415686267543068 in
kaffe-jodek.japi
class java.io.ObjectStreamException# has SerialVersionUID
7818375828146090155 in kaffe.japi but 7260898174833392607 in
kaffe-jodek.japi
class java.io.InvalidObjectException# has SerialVersionUID
7818375828146090155 in kaffe.japi but 3233174318281839583 in
kaffe-jodek.japi
class java.io.OptionalDataException# has SerialVersionUID
7818375828146090155 in kaffe.japi but 5107349927844423197 in
kaffe-jodek.japi
class java.io.CharConversionException# has SerialVersionUID
7818375828146090155 in kaffe.japi but -8680016352018427031 in
kaffe-jodek.japi

The "kaffe.japi" results were returned by Kaffe's ObjectStreamClass, the
kaffe-jodek.japi results are what I expect to be getting based on my
calculations.

The vast majority of these errors were Throwable classes, but as you can
see by my random-ish sample, there are a few that are not. It's also
worth noticing that Kaffe is reporting the same value for java.sql.Date
as for java.sql.Time, and likewise for the various java.io.*Exceptions.
Is it possible that, because the serialVersionUID field is public, these
classes are "inheriting" a declared SerialVersionUID from a parent class
rather than having it calculated (eg java.sql.Date and Time both inherit
from java.util.Date; the io.*Exceptions all inherit from IOException).

Thanks very much for your help,
Stuart.