It basically tells what version the class is. When you serialize an instance, you want to deserialize it with the same version of the class. If the version does not match, an exception will be thrown (InvalidClassException I think).
You do the following to understand serialVersionUID.
1- Serialize instances of your class. 2- Change the class definition, add method(s), remove member variables or add 3- Try to deserialize the instances you serialized in the step 1 You will get InvalidClassException because while serialization takes place, some information about your class in also saved as part of serialization.
OK! serialVerisonUID at your rescue! 1- Define serialVersionUID in your class! 2- Now serialize the instances 3- Make chages to your class 4- Deserialize the instances, Aren't you happy because this time no InvalidException occured, because serialization process didn't take trouble to generate serialVersionUID because you have defined it, and it is same (make sure you have not changed this)
i make the instance of the class serializable by implementing
serializable interface ,then how can i get them deserialize
Joined: Feb 28, 2007
Sure I have written the code demonstrating the use of serialVersionUID for you, Look at the following code,
/* * Once you have defined serialVersionUID for your * class, the Java is not going to compute it for you; * As a result you can change the definition of a class * by adding removing methods, members or so while * deserializing. The JVM wont show you error that * serialVerionUID mismatch. Because you have constant * serialVersionUID at every execution of your code. */
The version information is written into the serialisation stream, to ensure that one version of your code doesn't try and fail to read data written by another version.
By default, the version changes whenever fields or methods change in your code. So any slight change causes a failure.
However, by defining the version yourself using the serialVersionUID field, you can tell Java whether you believe the streams are compatible. Very often, changes to methods have no effect on whether the streams are compatible, and you want to ensure Java understands this, by having a serialVersionUID that doesn't change when methods change.
Sometimes, streams are compatible even when fields have changed. A field that's in the stream but not in the local class will be discarded. A field that's not in the stream but is in the local class will be initialised to its default. If you know that your code will cope with this, then use serialVersionUID to tell Java the streams are compatible.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com