SerialVersionUID
====================================
- In serialization both sender and receiver need not to be same location.
- The person may be different, the machine may be different and location may be different.
- In serialization both sender and receiver has .class (dot class) file at the beginning only. Just state of object is traveling from sender to receiver.
- At the time of serialization with every object sender side JVM will save a unique identifier.
- JVM is responsible to generate this unique identifier based on .class ( dot class ) file.
- At the time of de-serialization receiver side JVM will compare unique identifier associated with the object with local class unique identifier. If both are matched then only de-serialization will be performed otherwise we will get Runtime exception: InvalidClassException.
- This unique identifier is nothing but SerialVersionUID.
Problems of depending on default SerialVersioUID generated by JVM
- Both sender and receiver should use same JVM with respect to vendar, plateform and version. Otherwise receiver unable to de-serialize because of different SerialVersionUID.
- Both sender and receiver should use same .class file version. After serialization if there is any change in .class file at receiver side then receiver unable to de-serialize.
- To generate SerialVersionUID internally JVM may use complex algorithm which may create performance problem.
We can solve above problems by configuring our own SerialVersionUID.
We can configure our own SerialVersionUID as follows-
Ex:
- In above program after serialization if we perform any change to the class file at receiver side, we would not get any problem at time time of de-serialization.
- In this case sender and receiver not required to maintain same JVM versions.
Note:
- Some IDEs prompt programmers to enter SerialVersionUID explicitly.
- Some IDEs may generate SerialVersionUID automatically.