What is the use of setting SerialVersionUID in serialization?

The serialVersionUID is a universal version identifier for a Serializable class. Deserialization uses this number to ensure that a loaded class corresponds exactly to a serialized object. If no match is found, then an InvalidClassException is thrown.

Guidelines for serialVersionUID :

* always include it as a field, for example: "private static final long serialVersionUID = 7526472295622776147L; " include this field even in the first version of the class, as a reminder of its importance
* do not change the value of this field in future versions, unless you are knowingly making changes to the class which will render it incompatible with old serialized objects
* new versions of Serializable classes may or may not be able to read old serialized objects; it depends upon the nature of the change; provide a pointer to Sun's guidelines for what constitutes a compatible change, as a convenience to future maintainers

In Windows, generate serialVersionUID using the JDK's graphical tool like so :

* use Control Panel | System | Environment to set the classpath to the correct directory
* run serialver -show from the command line
* point the tool to the class file including the package, for example, finance.stock.Account - without the .class
* (here are the serialver docs for both Win and Unix)

readObject and writeObject :

* readObject implementations always start by calling default methods
* deserialization must be treated as any constructor : validate the object state at the end of deserializing - this implies that readObject should almost always be implemented in Serializable classes, such that this validation is performed.
* deserialization must be treated as any constructor : if constructors make defensive copies for mutable object fields, so must readObject
* when serializing a Collection, store the number of objects in the Collection as well, and use this number to read them back in upon deserialization; avoid tricks using null

Other points :

* use javadoc's @serial tag to denote Serializable fields
* the .ser extension is conventionally used for files representing serialized objects
* no static or transient fields undergo default serialization
* extendable classes should not be Serializable, unless necessary
* inner classes should rarely, if ever, implement Serializable
* container classes should usually follow the style of Hashtable, which implements Serializable by storing keys and values, as opposed to a large hash table data structure


/**
* Determines if a de-serialized file is compatible with this class.
*
* Maintainers must change this value if and only if the new version
* of this class is not compatible with old versions. See Sun docs
* for * /serialization/spec/version.doc.html> details.
*
* Not necessary to include in first version of the class, but
* included here as a reminder of its importance.
*/
private static final long serialVersionUID = 7526471155622776147L;




[Post New]posted Monday, May 09, 2005 10:44 PM private message
Quote [Up]
*g* as you mention "Java RMI"... it says:

"The downside of using serialVersionUID is that, if a significant change is made (for example, if a field is added to the class definition), the suid will not reflect this difference. This means that the deserialization code might not detect an incompatible version of a class."

and furtheron suggests to implement readObject & friends and writing a version "manually".

All this in order to gain performance:

"Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you don't set serialVersionUID, the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID, on the other hand, the serialization mechanism simply looks up a single value."

Satyam -Latest information

Mr.Raju surrendered to HYG DGP last night. Experts says that this was a wise movement from Mr.Raju. The main concerns now are

1. How many people from the corporate are involved in the sandal?
2. What about the future of the 53,000 employees?
3. Do the existing customers are willing to continue with satyam projects.?
4. Is Satyam going to pay salaries for the employees for couple of months. Rumors that Satyam does not have enough fund for paying off Salaries for the employees and they might layoff 10,000 employees or cut short the salary for the employees. However there are no official communication from Satyam on this.

Experts says that whatever happens, eventually it is the employees who are going to pay off due to any type of fraud from their bosses. That being a general statement, lets hope it will not happen with Satyam employees.

However personally I support Mr.Raju. I am not very sure about what inside the scandal issue. But from my understanding there are something bigger behind the scene.
Lets wait & see!!!!

2009

Satyam-India's 4th largest IT company is having tough time in 2009. I hope there will be a positive result after the January 10th borad meeting. Roumers are many other top companies like IBM, HP and CTS are in top list of the bidding companies.