permaculture playing cards*
The moose likes Beginning Java and the fly likes Versioning of classes with respect to serializing objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Versioning of classes with respect to serializing objects" Watch "Versioning of classes with respect to serializing objects" New topic
Author

Versioning of classes with respect to serializing objects

Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Hi

I just read that it is important to take care of the version aspect of a class which implements Serializable marker interface. This is because DE-serialization might fail if the object in question was serialized using one version of the class and is being DE-serialized using another version of the same class. I have some questions regarding this statement:

a) First of all, what is meant by different versions of the same class?

b) Secondly, when I try and write a class that implements Serializable interface, the IDE forces me to write private static final long = 1L. What is this got to do with version?

c) How does this come into play in the real world scenario? Could I really get into trouble if I do not use version concept in context of Serialization of objects? Moreover, how does the JVM track and maintain various versions of the same class?


~ Mansukh
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39436
    
  28
I did a search; there were about 8‑10 “hits”, which might be useful to you.
If you have a different version number, it means that the current version of the class is incompatible with previous versions, as far as serialisation is concerned.
No IDE forces you to do anything; it might suggest you give 1L as a default SUID. That means all versions with that SUID are considered mutually compatible.
The JVM uses the SUID to track whether there has been a significant change between successive versions. If you have a class whose generated SUID changes from version to version, consider that you might have made a mistake in changing the class.
I think you generate an SUID like this, but am not sure:-
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Campbell Ritchie wrote:I did a search; there were about 8‑10 “hits”, which might be useful to you.
If you have a different version number, it means that the current version of the class is incompatible with previous versions, as far as serialisation is concerned.
No IDE forces you to do anything; it might suggest you give 1L as a default SUID. That means all versions with that SUID are considered mutually compatible.
The JVM uses the SUID to track whether there has been a significant change between successive versions. If you have a class whose generated SUID changes from version to version, consider that you might have made a mistake in changing the class.
I think you generate an SUID like this, but am not sure:-


Actually, the IDE suggests and does not enforce like you rightly said. My class has the following line :



Is it the same as what you have quoted as example? And why does it have to be long? Cant it be some formatted version String or some expression that I choose to track my class according to some pattern that I want? Maybe alphanumeric or some version structure specific to my organization.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39436
    
  28
Mansukhdeep Thind wrote: . . . My class has the following line :



Is it the same as what you have quoted as example?
Yes, only I had the format of the output slightly wrong. Try it at the command line, and copy and paste from the output into your class, and recompile it.
OR: Delete the line and use the Eclipse option generate SUID.
And why does it have to be long?
Because that is what the JVM expects to find.
Cant it be some formatted version String or some expression that I choose to track my class according to some pattern that I want? Maybe alphanumeric or some version structure specific to my organization.
No. The JVM uses the long and will ognore anything else which isn’t a long. Try it and seeSerialise the class with that version. Change it to "Second attempt" and try deserialising it. See what happens.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39436
    
  28
More details available in the Serialisation specification and the Serializable interface documentation.
Mansukhdeep Thind
Ranch Hand

Joined: Jul 27, 2010
Posts: 1157

Campbell Ritchie wrote:More details available in the Serialisation specification and the Serializable interface documentation.


Thanks a lot sir. High 5..
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39436
    
  28
You’re welcome
 
 
subject: Versioning of classes with respect to serializing objects