Java Serialization Interview Questions and Answers Part-3

---

A How can one customize the Serialization process? or What is the purpose of implementing the writeObject() and readObject() method?

When you want to store the transient variables state as a part of the serialized object at the time of serialization the class must implement the following methods:

private void wrtiteObject(ObjectOutputStream outStream) {
  //code to save the transient variables state 
  //as a part of serialized  object
}
private void readObject(ObjectInputStream inStream) {
 //code to read the transient variables state 
//and assign it to the  de-serialized object
}

A What is the difference between Serializable and Externalizable interface in Java?

Externalizable provides us writeExternal() and readExternal() method which gives us flexibility to control java serialization mechanism instead of relying on Java's default serialization. Correct implementation of Externalizable interface can improve performance of application drastically.

A What is SerialVersionUID in java serialization?

serialVersionUID is used for version control of object. serialVersionUID is used to ensure that same class(That was used during Serialization) is loaded during Deserialization.

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;  

serialVersionUID must be Static and final. You can assign any number to it. For example, if you serialize an object and deserialize it, it will work fine as long as serialVersionUID is not changed. But after serializing, if you change serialVersionUID, and try to deserialize it, you will get error. Something like this:

local class incompatible: stream classdesc serialVersionUID = 1, local class serialVersionUID = 2

It complains about Serialvesionuid being changed.

A Why serialversionuid is required?

It is possible that you have serialized an object in a file and you deserialized it after few months on different JVM. In between serialization and deserialization class declaration has been changed. So it is a good idea to maintain version system and serialversionuid does exactly same thing. It checks if you are deserializing same object which you have serialized.

A When do I have to change the serialVersionUID? When should you update serialVersionUID?

The value of the serialVersionUID field should ideally be changed when incompatible changes are made to the structure of the class.

A What are the compatible and incompatible changes when dealing with versioned serialized objects during serialization?

Changes to a serializable class can be compatible or incompatible. Following is the list of changes which are compatible:

• Adding fields - When the class being reconstituted has a field that does not occur in the stream, that field in the object will be initialized to the default value for its type.
• Adding or removing classes - Comparing the class hierarchy in the stream with that of the current class can detect that a class has been deleted or added.
• Adding or removing writeObject/readObject methods
• Changing the access to a field - The access modifiers public, package, protected, and private have no effect on the ability of serialization to assign values to the fields.
• Changing a field from static to nonstatic or transient to nontransient - When relying on default serialization to compute the serializable fields, this change is equivalent to adding a field to the class. The new field will be written to the stream but earlier classes will ignore the value since serialization will not assign values to static or transient fields.

List of incompatible changes:

• Deleting fields
• Changing a nonstatic field to static or a nontransient field to transient
• Changing the declared type of a primitive field
• Changing a class from Serializable to Externalizable or vice versa is an incompatible change since the stream will contain data that is incompatible with the implementation of the available class.
• Changing a class from a non-enum type to an enum type or vice versa
• Removing either Serializable or Externalizable is an incompatible change since when written it will no longer supply the fields needed by older versions of the class.
• Changing the writeObject or readObject method
• Moving classes up or down the hierarchy - This cannot be allowed since the data in the stream appears in the wrong sequence.

A What are the guidelines for using serialVersionUID?

• You must declare serialVersionUID because it give us more control.for e.g. Default rules for generating serialVersionUID can be too strict in some cases. For example when the visibility of a field changes, the serialVersionUID changes too. or sometimes you just want to forbid deserialization of old serialized object then you can just change serialVersionUID.
• Include this field even in the first version of the class, as a reminder of its importance
• You must not only declare it but also maintain it. You should change serialVersionUID when there is some change in the definition of data stored in the class for example data type of field is changed.

A Does setting the serialVersionUID class field improve Java serialization performance?

Declaring an explicit serialVersionUID field in your classes saves some CPU time only the first time the JVM process serializes a given Class. However the gain is not significant, In case when you have not declared the serialVersionUID its value is computed by JVM once and subsequently kept in a soft cache for future use.

A Suppose you have a class which you serialized it and stored in persistence and later modified that class to add a new field. What will happen if you deserialize the object already serialized?

It depends on whether class has its own serialVersionUID or not. As we know that if we don't provide serialVersionUID in our code java compiler will generate it and normally it’s equal to hashCode of object. By adding any new field there is chance that new serialVersionUID generated for that class version is not the same of already serialized object and in this case Java Serialization API will throw java.io.InvalidClassException and this is the reason its recommended to have your own serialVersionUID in code and make sure to keep it same always for a single class.

A How serialVersionUID works?

When an object is serialized, the serialVersionUID is serialized along with the other contents. Later when that is deserialized, the serialVersionUID from the deserialized object is extracted and compared with the serialVersionUID of the loaded class. If the numbers do not match then, InvalidClassException is thrown.

If the loaded class is not having a serialVersionUID declared, then it is automatically generated.

A How serialVersionUID is generated?

serialVersionUID is a 64-bit hash of the class name, interface class names, methods and fields. Serialization runtime generates a serialVersionUID if you do not add one in source.

However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations and can produce different serialVersionUID in different environments. This can result in unexpected InvalidClassException during de-serialization.

Refer this link for the algorithm to generate serialVersionUID.

A How to generate serialVersionUID?

You can use JDK “serialver” or Eclipse IDE to generate serialVersionUID automatically.

---