This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Santosh Kumar Nayak wrote:Yes I am referring to the value of SerialVersionUID.
When you set a serial version UID, you are taking responsibility for the serialization compatibility. If you have two versions of the same class, that is not compatible with each other -- setting them to the same serial version UID is not a good idea.
And there's nothing magic about the value 1 for the serial version UID either. You could use 8055 if you liked, and then if you changed the class in a compatible way and continued to use 8055 then things would work fine. So your idea that "we use 1L" is likely based on a small number of examples that you have seen. It isn't a rule or even a convention.
Santosh Kumar Nayak
Joined: Aug 02, 2011
When we Deserialzie the Object in another JVM then will we face any issue. As I have taken the value of 1L is from the old JVM
Note: there has been no changes to the original class
It isn't the JVM which deserializes the object which will be the cause of any problems. The problems can arise if the application doing the deserializing has a different version of the class which was used when serializing.