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."
