Tom Tromey writes:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
The question is what the fix is? In every service release of SUNs JDK
they change some of the serialVersionUIDs. Whenever you run japi locally
against another service release of SUN you will get other differences.
On Mon, Mar 27, 2006 at 11:18:27AM +0100, Andrew Haley wrote:
Tom Tromey writes:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
The question is what the fix is? In every service release of SUNs JDK
they change some of the serialVersionUIDs. Whenever you run japi locally
Tom Tromey writes:
Stuart == Stuart Ballard [EMAIL PROTECTED] writes:
Stuart Perhaps in the same spirit as the throws NotImplementedException
Stuart hack, we could add a NotReallySerializable interface that classes
Stuart whose svuids should be ignored could implement...
I don't
On Sat, Mar 25, 2006 at 10:06:15AM +, Andrew Haley wrote:
Tom Tromey writes:
Stuart == Stuart Ballard [EMAIL PROTECTED] writes:
Stuart Perhaps in the same spirit as the throws NotImplementedException
Stuart hack, we could add a NotReallySerializable interface that classes
Michael Koch writes:
On Sat, Mar 25, 2006 at 10:06:15AM +, Andrew Haley wrote:
Tom Tromey writes:
Stuart == Stuart Ballard [EMAIL PROTECTED] writes:
Stuart Perhaps in the same spirit as the throws
NotImplementedException
Stuart hack, we could add a
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
The question is what the fix is? In every service release of SUNs JDK
they change some of the serialVersionUIDs. Whenever you run japi locally
against another service release of SUN you will get other differences.
Yeah. javax.swing is a
Hi Carsten,
On Fri, 2006-03-24 at 18:44 +0100, Carsten Neumann wrote:
I'm new around here and was looking for a spot where I could make a
contribution. Browsing the japi test results I noticed that a lot of
SerialVersionUID missmatches are reported. Fixing these appears to be
quite simple,
Carsten == Carsten Neumann [EMAIL PROTECTED] writes:
Carsten I'm new around here and was looking for a spot where I could make a
Carsten contribution. Browsing the japi test results I noticed that a lot of
Carsten SerialVersionUID missmatches are reported. Fixing these appears to be
Carsten
On 24 Mar 2006 12:45:27 -0700, Tom Tromey [EMAIL PROTECTED] wrote:
I don't really know what we should do long term. Maybe fixing these
to be compatible is best. However it isn't sufficient to add the
serialVersionUID, you need to also make sure that the serialized
forms are the same.
Stuart == Stuart Ballard [EMAIL PROTECTED] writes:
Stuart Perhaps in the same spirit as the throws NotImplementedException
Stuart hack, we could add a NotReallySerializable interface that classes
Stuart whose svuids should be ignored could implement...
I don't think we could do that, as a new
hultul writes:
Hi, all~
I did some tests of java.io.Serializable's serialVersionUID using cp-tools.
All the VM's used in tests were from Debian testing release.
As a result, kaffe, jamvm, sablevm, and gij showed different results from
Sun's java, where gij in GCC-3.4.3 not in
Serializable is an interface, anyway, not a class. Interfaces can
never be serializable and so it makes absolutely no difference what
serialver returns for them. I'd actually suggest it would be nice if
serialver gave a warning or an error in that case!
Yes, I know that Sun sometimes put
Your summary seemed good to me.
Mark Wielaard wrote:
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?
Partly because it was a hack added in JDK 1.1. To maintain the most
possible backward
I've added this information to the hacking document, thanks Eric.
Brian
Eric Blake [EMAIL PROTECTED] writes:
If a class has a field (of any accessibility) named serialVersionUID
of type long, that is what serialver uses. Otherwise it computes a
value using some sort of hash function on the
Eric Blake [EMAIL PROTECTED] writes:
It is necessary for serialization, although it is usually a private
field. ALL classes in classpath which implement java.io.Serializable
should declare this field, and it should match the results of running
Sun's serialver tool on that class; otherwise,
Hi Giannis,
--- Giannis Georgalis [EMAIL PROTECTED] wrote:
Eric Blake [EMAIL PROTECTED] writes:
It is necessary for serialization, although it is
usually a private
field. ALL classes in classpath which implement
java.io.Serializable
should declare this field, and it should match the
On Thu, 26 Sep 2002, Dalibor Topic wrote:
If classpath uses different implementations of java
classes on different platforms the genuine
serialVersionUID for the different implementations
will obviously differ. I assume that Suns
serialVersionUID is the same on all platforms, though;
If a class has a field (of any accessibility) named serialVersionUID of
type long, that is what serialver uses. Otherwise it computes a value
using some sort of hash function on the names of all method signatures
in the .class file. I'm not sure whether the methods are sorted first,
or what
Tom Tromey [EMAIL PROTECTED] writes:
Eric == Eric Blake [EMAIL PROTECTED] writes:
Eric The fact that different compilers create different synthetic
Eric method signatures, such as access$0() if an inner class needs
Eric access to a private member of an enclosing class, make it
Eric
It is necessary for serialization, although it is usually a private
field. ALL classes in classpath which implement java.io.Serializable
should declare this field, and it should match the results of running
Sun's serialver tool on that class; otherwise, Classpath will not be
compatible for
20 matches
Mail list logo
