classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serialver [was Re: [PATCH]]


From: Dalibor Topic
Subject: Re: Serialver [was Re: [PATCH]]
Date: Mon, 19 Nov 2001 19:35:40 -0800 (PST)

--- Eric Blake <address@hidden> wrote:
> 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.

The "NOTE:" section in the spec at
http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html
has more about it. It comes down to different
compilers generating different names for synthetic
methods in inner classes. Since these names are used
in SUID algorithm, chances are high that the hashes
won't match.

> 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:

I do not think that the order should matter in any
case. The spec implicitly says that all interfaces,
fields, constructors and methods which matter are
sorted by their names and signatures before being
considered in the calculation.

> 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.

I believe that the naming issue is crucial, and that
ordering does not matter. But as you pointed out,
Serializable is not a class, it's an interface, and
the patch is redundant.

thanks

Dalibor Topic


=====
"Success means never having to wear a suit"

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1



reply via email to

[Prev in Thread] Current Thread [Next in Thread]