• Post Reply Bookmark Topic Watch Topic
  • New Topic

Serialization | General Questions

 
Prashant Sehgal
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

It is said that through serialization one can persist the state of an object.

Q1- What about behaviour? When an object is serialized are only it's attributes persisited or are the methods also sent?

Q2- Adding/removing/modifying data type of an existing attribute will automatically update the serialVersionUId of the class. Will performing similar changes to methods also result in the same?

Thanks.
 
Rob Spoor
Sheriff
Posts: 20820
68
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A1- only non-static non-transient fields are actually serialized.
A while ago, as a test, I wrote two different classes with the same package, name and serialVersionUID. I could serialize an instance of one class, and deserialize it as an instance of the second. It had the behaviour of the second.

A2- The best answer is of course to try it out, but I think it does.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Only the state of any object instance is serialized.
As Rob told, by default only non-static and non-transient fields are serialized.
Now, de-serialization is equivalent to instantiating the class in the other JVM and then pre-populating the state into the new instance.
Since, this instantiation follows the same rule as the normal way of instantiation(via the new operator), so the class definition available in the local JVM will be used. This explains why the change in methods will take effect while de-serialization. However, this will work only if the serialVersionUid is the same for both the version of the classes. This essentially means that the serial version uid is explicitly specified in the class.
Of course, if dynamic classloading is enabled then the class definitions will be loaded from the origination JVM and so the class definition present there will be used, if it is not available in the local JVM where deserialization is done.

The serialversionUid is kind of a checksum of the class definition so, any change, like modifying the methods(in any way like changing the body or signature) or fields will change the serial version uid.
However, the serialversionUid specified explicitly in any class is not overridden during compilation.
SO, if you have not specified the id then it will be *automatically* changed.
On the other hand, if you have specified it and not changed then it will remain the same.
[ September 29, 2008: Message edited by: Nitesh Kant ]
 
Rob Spoor
Sheriff
Posts: 20820
68
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nitesh Kant:
in any way like changing the body

Actually, experience has told me that if I change only the body of a method but leave the signature intact, the serialVersionUID will remain the same.

Since I've told my Eclipse to warn against missing serialVersionUIDs, I am adding generated values where needed. If I only change the body of a method, comment out the old serialVersionUID and then let Eclipse generate a new one (using serialver) it is exactly the same.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!