wood burning stoves 2.0*
The moose likes Java in General and the fly likes serialVersionUID field is of type static final long , then why it gets serialized in Serialization ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "serialVersionUID field is of type static final long , then why it gets serialized in Serialization ?" Watch "serialVersionUID field is of type static final long , then why it gets serialized in Serialization ?" New topic
Author

serialVersionUID field is of type static final long , then why it gets serialized in Serialization ?

Tarik Makhija
Greenhorn

Joined: Sep 27, 2011
Posts: 1



Hi Coderanch Team,
This is my first post on this forum www.coderanch.com

While googling , I have read somewhere that

serialVersionUID is a static final field of type long. We can assign any number of our choice to it.

serialVersionUID is a must in serialization process. But it is optional for the developer to add it in java source file.
If we are not going to add it in java source file, serialization runtime will generate a serialVersionUID and associate it with the class.

The serialized object will contain this serialVersionUID along with other data.

Even though serialVersionUID is a static field, it gets serialized along with the object.

Now My Question is Since , serialVersionUID field is of type static final long , then why it gets serialized in Serialization of Object ,
Is this the one exception to the general serialization rule that, static fields are not serialized. ? Please advise ?


Regards,
Tarik Makhija
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2161
    
  47
Welcome to the ranch.

Yes it is the exception because serialVersionUID is used by the serialisation system to determine if a class has been changed since the object was serialized ie if it is safe to de-serialize the object to the current class definition. If the serialVersionUID in a serialized object is the same as the in class then it is assumed that no modifications that will effect the de-serialisation have been made to the class. So for instance, if a class has been modified to add a new method then there is probably no need to change the class' serialVersionUID however if you have added/removed/changed the type of an instance variable then you must change the serialVersionUID or provide special handling code for de-serialising objects serialized before the change.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Tarik Makhija wrote:
Is this the one exception to the general serialization rule that, static fields are not serialized. ? Please advise ?[/b]


Yes.

You can view it as a sort of checksum on the class definition.

When we serialize an object, we only store the class name, the state of the object (non-static member variables) and the serialVersionUID. We expect that whoever deserializes it will have the appropriate class definition to put those member variables into their correct, meaningful spots. The class name tells the deserializer which class this data corresponds to, but multiple unrelated classes can have the same name, and even the same class can go through different incompatible versions during its lifetime, so the serialVerionUID is a way to ensure that we have a class that is compatible with the data we're sending. There's no guarantee of course, but if we're smart in how we generate that ID, with 2^64 possible values, it's unlikely that we'll have a match on the wrong class.
K Abhijit
Ranch Hand

Joined: Mar 03, 2008
Posts: 88
Now My Question is Since , serialVersionUID field is of type static final long , then why it gets serialized in Serialization of Object ,
Is this the one exception to the general serialization rule that, static fields are not serialized. ? Please advise


YES its is an exception::
Now you would say WHY this is an exception
The answer lies in 'WHAT IT DOES FOR CLASS' and HOW ITS HANDLED IN JAVA

serialVersionUID:
It's version that serialization run time associates with each serializable class which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization.
If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException

Logically thinking considering OBJECT Serialization Policy USAGE of this variable ; IT HAS to be CLASS Level NOT INSTANCE Level. (if you understand its usage you would agree this statement)

BUT THIS VERSION ID of the sender class (instance) which is getting serialized should also be available on Remote serializable runtime to CONFIRM /VALIDATE the version of incoming (serialized) INSTANCE Of class
so it SHOULD BE PART OF SERIALIZED package


HENCE IT IS SERIALIZABLE

hope it answers your doubt
cheers


“The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'.”
 
jQuery in Action, 2nd edition
 
subject: serialVersionUID field is of type static final long , then why it gets serialized in Serialization ?
 
Similar Threads
serialVersionUID in SessionBean
serializable
what is the use of the private static long serialVersionUID variable ?
Serialization - different JVM version ?
ArrayList problem ...