Home » Eclipse Projects » Eclipse Platform » serialVersionUID killing us
| serialVersionUID killing us [message #281563] |
Mon, 21 February 2005 21:30  |
Eclipse User |
|
|
|
Originally posted by: xixhub.na.direcway.com
I hate to harp on this, but I've done exactly as suggested. Jre1.5,
Eclipse3.1. and our big program dies as soon as the Data File, RN is
accessed. All of the classes that did any io had yellow warnings at the top
about UID's so I clicked on each one, selected the second option this time
as Olivier Thomann suggested in his anawer to my earlier posting.
Now as soon as the program tries to access RN data file we get:
Exception during deserialization: java.io.InvalidClassException:
org.charts.pkg.RN; local class incompatible: stream clasdesc
serialVersionUID = -914354........., local class serialVersionUID =
39058......11379
What now? I did research on all the Help functions, researched google, sun
micro systems, and of course none of the text's, even the bran new ones,
have anything to say about serialVersionUID, or what to do.
I'm at my wits end, and we are out of business!
Does anyone know how to tame this thing?
|
|
| |
| Re: serialVersionUID killing us [message #281570 is a reply to message #281563] |
Mon, 21 February 2005 23:45  |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Sam King wrote:
> I hate to harp on this, but I've done exactly as suggested. Jre1.5,
> Eclipse3.1. and our big program dies as soon as the Data File, RN is
> accessed. All of the classes that did any io had yellow warnings at the top
> about UID's so I clicked on each one, selected the second option this time
> as Olivier Thomann suggested in his anawer to my earlier posting.
>
> Now as soon as the program tries to access RN data file we get:
> Exception during deserialization: java.io.InvalidClassException:
> org.charts.pkg.RN; local class incompatible: stream clasdesc
> serialVersionUID = -914354........., local class serialVersionUID =
> 39058......11379
>
well you could set your serialVersionUID to match the one in the stream
public static final long serialVersionUID = -914354...;
> What now? I did research on all the Help functions, researched google, sun
> micro systems, and of course none of the text's, even the bran new ones,
> have anything to say about serialVersionUID, or what to do.
>
> I'm at my wits end, and we are out of business!
>
> Does anyone know how to tame this thing?
>
>
SerialversionUID is untameable. That is why everyone recommends you
have one. Otherwise the compiler will generate one for you based on
properties of your file. If you change single thing(generally) you
will get a new serialversionUID, and your old files will no longer
deserialize. You can change someting totally unrelated to
deserilaization like a method name, and that will break your
deserialization of previously serialized classes because the UID will be
now different.
You must go back to the EXACT java/class files you had when you
serialized them. OR you must make your current UID match the old UID.
CL
|
|
| | |
| Re: serialVersionUID killing us [message #281592 is a reply to message #281563] |
Tue, 22 February 2005 10:15 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.rizzoweb.com
Sam King wrote:
> I hate to harp on this, but I've done exactly as suggested. Jre1.5,
> Eclipse3.1. and our big program dies as soon as the Data File, RN is
> accessed. All of the classes that did any io had yellow warnings at the top
> about UID's so I clicked on each one, selected the second option this time
> as Olivier Thomann suggested in his anawer to my earlier posting.
>
> Now as soon as the program tries to access RN data file we get:
> Exception during deserialization: java.io.InvalidClassException:
> org.charts.pkg.RN; local class incompatible: stream clasdesc
> serialVersionUID = -914354........., local class serialVersionUID =
> 39058......11379
>
> What now? I did research on all the Help functions, researched google, sun
> micro systems, and of course none of the text's, even the bran new ones,
> have anything to say about serialVersionUID, or what to do.
>
> I'm at my wits end, and we are out of business!
>
> Does anyone know how to tame this thing?
Lots of other replies, but I wanted to point out some pages that explain
it in detail. I hope you understand that this is not an Eclipse problem
at all - you're just running into common issues with Java object
serialization. Anyway, read here:
http://java.sun.com/developer/technicalArticles/Programming/ serialization/
And here is a good explanation of the rule of thumb "Always Declare
Serial Version UID": http://c2.com/cgi/wiki?AlwaysDeclareSerialVersionUid
HTH,
Eric
|
|
|
| Re: serialVersionUID killing us [message #281597 is a reply to message #281563] |
Tue, 22 February 2005 11:23 |
| Eclipse User |
|
|
|
Originally posted by: grundig.wp.pl
Sam King wrote:
> I hate to harp on this, but I've done exactly as suggested. Jre1.5,
> Eclipse3.1. and our big program dies as soon as the Data File, RN is
> accessed. All of the classes that did any io had yellow warnings at the
> top about UID's so I clicked on each one, selected the second option this
> time as Olivier Thomann suggested in his anawer to my earlier posting.
>
> Now as soon as the program tries to access RN data file we get:
> Exception during deserialization: java.io.InvalidClassException:
> org.charts.pkg.RN; local class incompatible: stream clasdesc
> serialVersionUID = -914354........., local class serialVersionUID =
> 39058......11379
>
> What now? I did research on all the Help functions, researched google,
> sun micro systems, and of course none of the text's, even the bran new
> ones, have anything to say about serialVersionUID, or what to do.
>
> I'm at my wits end, and we are out of business!
>
> Does anyone know how to tame this thing?
Eclipse just warnings about potential programming problems. If you don't
care about it and know what are you doing you can just turn it off.
Window > Preferences > Java > Compiler > Errors/Warnings > Potential
programming problems > Serializable class without serialVersionUID
--
Pozdrawiam,
grundig
|
|
| | |
| Re: serialVersionUID killing us [message #281654 is a reply to message #281638] |
Wed, 23 February 2005 12:03 |
| Eclipse User |
|
|
|
Originally posted by: wegener.cboenospam.com
Maybe the warning should be on the use of the Serializable interface.
The purpose of the serialVersionUID is to indicate whether two different
instances of a class are compatible with respect to serialization, not to
indicate whether two different instances of a class are identical. If the
only change between the two instances of the class was a method name they
would be compatible with respect to serialization. Changing a field name
would break compatibility.
The serialized form of an object represents its state. Method names and
signatures are not part of the state of an object. Unfortunately, method
names are used by the serialization runtime to calculate a default
serialVersionUID. Inner classes require that method signatures be altered
and method names be generated by the compiler. The Java language spec
does not specify how the methods are altered or the names are changed.
This leaves it up to each compiler vendor. This makes the default
serialVersionUID that is calculated by the serialization runtime is
dependent on compiler implementations. The exact same Java code using the
exact same JDK release built with compilers from 2 different vendors will
produce class files that produce different default serialVersionUIDs.
Explicitly declaring a serialVersionUID solves the compiler discrepency
problem. However, it places an added burden on the developer to recognize
actual serializable differences between two versions of a given class. If
a field is different between, they aren't compatible. If the
serialVersionUID isn't changed as well, there will likely be problems.
Its kind of a damned if you do, damned if you don't situation. Flagging
the use of the Serializable interface would account for either situation.
CL [dnoyeb] Gilbert wrote:
> Though its called serialVersionUID it is not about file storage. Its
> about the version of the 'class' being serialized. changing a method
> name is an indication that the class is not the same anymore, so to
> create a class from it during serialization is wrong.
> I think eclipse is wrong in stating that the lack of serialVersionUID is
> worth a warning. In fact the presence of that number should be worth
> a warning. Its an indicaiton that serialization is being used for 'long
> term storage' in general. And 'long term' is not really time related.
> just means to ROM or HD and not to RAM, IMHO.
> you are correct to use your own storage method. Personally I still am
> saving with serilization, but eventually I will not be.
> CL
> Aksel Schmidt wrote:
>> we made a template for controlling this
>> // Turn off automatic generation of serialVersionUID
>>
>> public static final long serialVersionUID = 1;
>>
>> private static final int FORMAT_VERSION = 1;
>>
>> public int getFormatVersion() {
>>
>> return FORMAT_VERSION;
>>
>> }
>>
>> additionally, we implemented extrernalisable in order to control streaming
>> ourselves.
>>
>> this way, we had our own format version to test on - if we want to support
>> streaming of different versions, we just stream the format version as well
>> and tests on this in readExternal, then decide the read mechanism.
>>
>> If the streaming changes, jsut increment the format version
>>
>> /aksel
>>
>>
|
|
| |
| Re: serialVersionUID killing us [message #281776 is a reply to message #281654] |
Fri, 25 February 2005 11:50 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
David Wegener wrote:
> Maybe the warning should be on the use of the Serializable interface.
> The purpose of the serialVersionUID is to indicate whether two different
> instances of a class are compatible with respect to serialization, not
> to indicate whether two different instances of a class are identical. If
> the only change between the two instances of the class was a method name
> they would be compatible with respect to serialization. Changing a
> field name would break compatibility.
I don't think u are correct. Serialization is sending the 'class' over
the wire. This can be shortened by sending only the state if the
classes on both ends are equal. If I change a method of a class, the
class is NOT the same. serialVersionUID properly changes in this case to
indicate the difference.
> The serialized form of an object represents its state. Method names and
> signatures are not part of the state of an object. Unfortunately,
> method names are used by the serialization runtime to calculate a
> default serialVersionUID. Inner classes require that method signatures
> be altered and method names be generated by the compiler. The Java
> language spec does not specify how the methods are altered or the names
> are changed. This leaves it up to each compiler vendor. This makes the
> default serialVersionUID that is calculated by the serialization runtime
> is dependent on compiler implementations. The exact same Java code
> using the exact same JDK release built with compilers from 2 different
> vendors will produce class files that produce different default
> serialVersionUIDs.
>
Again, storage may be about state, but serialization is not. Consider
RMI and how it can ensure class file compatability under your scheme?
It could not. And different compilers should produce different SUIDs
because the class files may in fact be different.
> Explicitly declaring a serialVersionUID solves the compiler discrepency
> problem. However, it places an added burden on the developer to
> recognize actual serializable differences between two versions of a
> given class. If a field is different between, they aren't compatible.
> If the serialVersionUID isn't changed as well, there will likely be
> problems.
> Its kind of a damned if you do, damned if you don't situation. Flagging
> the use of the Serializable interface would account for either situation.
>
What I am suggesting is that if someone has a SUID in their file they
are probably using serialization for long term storage, would you agree?
And if they are, that deserves a warning as this is not what
serialization is for. Thats really my whole point. But what we have
today is the opposite, you get a warning when you don't have a SUID.
But why should you? If you are marshalling you classes, its easier to
have the compiler verify that your class signature has not changed, than
for you to keep track yourself.
CL
|
|
| |
| Re: serialVersionUID killing us [message #281784 is a reply to message #281780] |
Fri, 25 February 2005 13:28 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Bob Foster wrote:
> CL [dnoyeb] Gilbert wrote:
>
>> I don't think u are correct. Serialization is sending the 'class'
>> over the wire. This can be shortened by sending only the state if the
>> classes on both ends are equal. If I change a method of a class, the
>> class is NOT the same. serialVersionUID properly changes in this case
>> to indicate the difference.
>
>
> Yes, yes. You've said that several times. There are two points to be made:
>
> 1) When the class changes incompatibly, of course the serialVersionUID
> must change.
>
> 2) It is not a good idea to leave setting the serialVersionUID to the
> compiler, as that makes it compiler-specific. Unless you can ensure that
> you will always compile the class with the same compiler and the
> compiler won't change the way it computes serialVersionUID, you don't
> want that.
>
> Therefore, the best practice is to set the UID by hand and change it
> when you need to, by hand. Too bad, but that's the way it is.
>
You may want to set the UID, but I wouldn't call it 'best practice.'
Its optional. If you set it, you have a set of issues to deal with. If
you do not set it, that entails its own set of issues.
CL
|
|
|
| Re: serialVersionUID killing us [message #281788 is a reply to message #281780] |
Fri, 25 February 2005 13:42 |
| Eclipse User |
|
|
|
Originally posted by: olivier_thomannNOSPAM.ca.ibm.com
Bob Foster a écrit :
> 2) It is not a good idea to leave setting the serialVersionUID to the
> compiler, as that makes it compiler-specific. Unless you can ensure that
> you will always compile the class with the same compiler and the
> compiler won't change the way it computes serialVersionUID, you don't
> want that.
Just to clarify. The compiler doesn't do the computation. It is done at
runtime, but it is compiler-specific, because the default serialization
is using the synthetic methods added by the compiler in its computation
of a runtime serialVersionUID.
Keeping the same compiler means same version. For example, there is no
garantee that javac 1.4 and javac 1.5 would produce the same
serialVersionUID at runtime. If you use class literal (A.class) in your
code, it won't.
> Therefore, the best practice is to set the UID by hand and change it
> when you need to, by hand. Too bad, but that's the way it is.
yes, it is recommended by Sun to set a serialVersionUID.
--
Olivier
|
|
| | | |
Goto Forum:
Current Time: Fri Oct 31 10:27:03 EDT 2025
Powered by FUDForum. Page generated in 0.27065 seconds |
Home