The serializable class does not declare a static final serialVersionUID field of type long.

[Michael Mangus <mm...@SEWELL.com>]

Hi,

 

I was using Eclipse 3.01 and I realized it doesn't use JDK1.5.  I
downloaded and installed Eclipse 3.1M4, Spindle 3.1.15, and Jetty
Launcher 1.2.1.

 

Everything works with no problems, but I noticed a few classes in the
tiaexamples that implement Serializable were being shown by Eclipse with
the following note:

 

The serializable class does not declare a static final serialVersionUID
field of type long.

 

After doing a google about serialVersionUID:

The serialVersionUID is computed using the signature of a stream of
bytes that reflect the class definition.  The values input to the stream
are defined by the Java(tm) Virtual Machine (VM) specification for
classes.

 

I used serialver to determine what the current serialVersionUID for
ToDoItem.class and coded the private static final serial which resolved
eclipses lightbulb on implementing serializable.

 

My question:

 

When I change the contents of the class the algorithm will output a
different serialVersionUID.   Do I need to update the serialVersionUID
every time a change is made to the class?  I noticed even if I make
changes that the serialver will use the coded serial so I assume it
doesn't really need to be updated.  

 

I thought I'd ask because I'm not sure of the drawbacks if I don't
update the serialVersionUID to reflect the algorithm used to create it.

 

Thanks.

 

Michael Mangus
Business Systems Analyst
Sewell Automotive Companies
3860 W. Northwest Hwy - Suite 104
Dallas, TX 75220

phone: 214.902.2207 
fax: 214.902.9887 
email: mmangus@sewell.com

 

Re: The serializable class does not declare a static final serialVersionUID field of type long.

[Jonny Wray <jo...@yahoo.com>]

I have to admit, this is one of those subjects that I think I've got a good
handle on but when I come to explain it to someone I find I don't quite
understand it. Anyway, check out Effective Java for a great discussion on
the subject.

As for your question, I'll give it my best shot. The serialVersionUID is
used by the deserializing method to find out if the serialized stream is
coming from the same version of a class as it is. So, if you change your
implementation details then, yes, the version id should change, unless you
are sure the changes don't make any difference to serialization. Otherwise,
the deserialization will be constructing an object from a different version
of the objects class, which could lead to very strange behavior I'd have
thought.

The other situation where you don't need to change it is if you can replace
all the old class files with the new ones, which in the most simple
situation is when you are operating only within one jvm.

> 
> My question:
> 
> 
> 
> When I change the contents of the class the algorithm will output a
> different serialVersionUID.   Do I need to update the serialVersionUID
> every time a change is made to the class?  I noticed even if I make
> changes that the serialver will use the coded serial so I assume it
> doesn't really need to be updated.
> 
> 
> 
> I thought I'd ask because I'm not sure of the drawbacks if I don't
> update the serialVersionUID to reflect the algorithm used to create it.
> 
> 
> 
> Thanks.
> 
> 
> 
> Michael Mangus
> Business Systems Analyst
> Sewell Automotive Companies
> 3860 W. Northwest Hwy - Suite 104
> Dallas, TX 75220
> 
> phone: 214.902.2207
> fax: 214.902.9887
> email: mmangus@sewell.com
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org