Most ignored concept in java but very important from interview point of view : SerialVersionUID

Believe me or not, serialVersionUID is the most ignored concept in java. But as you get familiar with it, you will get to know how important and how powerful this concept is.

So, lets deep dive to understand the serialVersionUID concept.


Prerequisite

You need to have prior knowledge of serialization and deserialization to understand the serialVersionUID concept better. 


What is serialVersionUID?

When we serialize an object, JVM generates one unique identifier for serializable class. Which is used at the time of deserialization to verify the sender (who serializes the object) and the receiver (who deserializes the object) have loaded the same compatible serializable class versions at their side? This unique identifier is called serialVersionUID.


How JVM calculates default serialVersionUID?

JVM uses various aspects of the class to calculate the serialVersionUID like class name, implemented interface, all members of that class, etc. The calculation of default  serialVersionUID is very much sensitive to all these aspects of the class. Thus, any small change in any of these may change the value of serialVersionUID calculated by JVM.

Check here the detailed algorithm used by JVM to calculate serialVersionUID.


How serialVersionUID works?

  • At the time of serialization, sender side JVM generates the serialVersionUID for serializable class loaded at the sender's side and serializes it along with other instance variables.
  • At the time of deserialization, receiver side JVM fetches that serialized serialVersionUID  and compares it with the receiver side serialVersionUID,  calculated based on its local version of the serializable class.
  • If both match, then only deserialization takes place. Otherwise, it fails with runtime exception saying “InvalidClassException” at the receiver side.

Problems with JVM generated default serialVersionUID

There are some major problems with the default serialVersionUID generated by JVM.

  • Both sender and the receiver should use the same JVM (with respect to version and vendor of JVM) as different JVM may generate different serialVersionUID for the same class version, which may lead to the failure at the time of deserialization.
  • The default serialVersionUID is very sensitive to the class properties. Any slight change in any of them may change the value of serialVersionUID.  So, both, the sender and receiver should have exactly the same version of the class file. Any small change in the class file after serialization may cause a failure at the time of deserialization.
  • To generate serialVersionUID, internally JVM may use a complex algorithm that may create a performance problem.

These are the major problem of relying on default serialVersionUID generated by JVM. But don't lose hope. Every problem has a solution. So is this.


Solution

We can overcome the above problems by defining our own serialVersionUID externally. JVM generates default serialVersionUID if the programmer doesn’t provide it externally. It's always recommended to define external serialVersionUID, instead of relying on the default one created by JVM. Below is the syntax to define serialVersionUID externally.

             any_modifier static final long serialVersionUID = 1L;

Below code snippet shows, how we can define serialVersionUID externally.

 

public class MySerializable implements Serializable{

     public static final long serialVersionUID = 111111L;
     String name = null;
     String paltform = null;
     int version;

     MySerializable(){

           name = "Other blog";
           paltform = "Unknown";
           version = 0;
     }
}

 

public class MySender {

     public static void main(String[] args) throws FileNotFoundException, IOException {
           MySerializable mySerializable = new MySerializable();
           mySerializable.name = "DeepDive91";
           mySerializable.paltform = "Java";
           mySerializable.version = 1;
           ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("DeepDive91.txt"));
           oos.writeObject(mySerializable);
           System.out.println("Serialization completed!! ");
     }
 }

 

public class MyReceiver {

     public static void main(String[] args) throws ClassNotFoundException, IOException {
           MySerializable mySerializable = new MySerializable();
           ObjectInputStream ois = new ObjectInputStream(new FileInputStream("DeepDive91.txt"));
           mySerializable = (MySerializable)ois.readObject();
           System.out.println("Deserialization completed!! ");
           System.out.println("Blog name= "+mySerializable.name);
           System.out.println("Platform= "+mySerializable.paltform);
           System.out.println("Version= "+mySerializable.version);
     }
} 

Interview Quiz

Based on the above explanation, the interviewer may ask you some tricky questions like below.

Interviewer Q1: Is it compulsory to declare serialVersionUID as static? why?

Your Answer: Yes, compulsorily serialVersionUID should declare as static because of the below reasons.

  • Deserialization means, constructing or creating an object from the serialized form. Whereas, the main purpose of serialVersionUID is to validate the class version right before deserialization that class's object. At the time of class validation, there is no object created or deserialized. So that's why serialVersionUID should always be static (as we know, the static members get created in the very beginning, when JVM loads the class) and not instance variable, so that JVM can use it to validate the deserialization, without having any object.
  • Static members are class level members and the purpose of serialVersionUID is to maintain the identifier for each class version. And that's why it declared as static, to bound it to class level.

 

Interviewer Q2: static member does not participate in the serialization, then how JVM serializes serialVersionUID which is compulsorily static?

Your Answer: It's true that we cannot serialize static members. But, the serialVersionUID is one and only exceptional case in java. Even though it's static,  but JVM treats it specially and serializes it along with other instance variables. But to get serialVersionUID serialized, it must be declared static, final, and of type long only. Any change in this syntax, won't allow it to be serialized.

                    static final long serialVersionUID


Conclusion

serialVersionUID is the unique identifier, that is serialized along with instance variables in serialization and used at the time of deserialization to validate the class version compatibility.

Hope this article has helped you to understand the serialVersionUID concept better. If you have any questions about this topic you can write it in the comments section. I will try to answer your queries ASAP.

See you in the next post. Till then keep reading.

Comments

Post a Comment

Popular posts from this blog

Can we define explicit constructor for an anonymous inner class?

Image
The precise answer to this question is " NO ". We can not have an explicit constructor for an anonymous inner class. Generally to create a constructor for a class, the first and the main requirement is "Constructor name must be exactly the same as its class name". But in the anonymous inner class concept, we don't have a class name (at least not till the class file for anonymous inner class gets created.) and that's why we can not define its constructor explicitly as we don't know its class name. So, the bottom line is, explicit constructor concept is not applicable for an anonymous inner class. But the drama doesn't end here. As no class exists in the world of java without a constructor (at least one). The same applies to the anonymous inner class as well. But then immediately question comes to the mind "If we can not write an explicit constructor for an anonymous class then how do we have a constructor in it?" Our superhero "Mr. Comp
Read more

Why we can not throw exception from Thread’s run method?

Image
Yes, you heard it right.   We cannot throw checked exceptions from our implemented threads run() method. Because we override Thread class’s or Runnable interface’s run() method and that method does not throw any checked exception and that’s why even we cannot throw checked exception in our overriding run() method (“Rules for method overriding” is a different topic to discuss, that I will cover separately). Now a big question comes to our mind!! Why Thread class’s or Runnable interface’s run() method declared not to throw checked exception??                                                             Before answering the above question, we need to deep dive to understand: how our implemented run() method gets invoked?? I have explained the answer in a separate post (Just to keep this post as short as possible as this is a big topic to discuss). You can check the answer in my below post. https://deepdivejava91.blogspot.com/2020/09/how-run-method-get-invoked-from-our.html
Read more

How does thread's run method get invoked??

Do we invoke run method by calling Thread class’s start() method? The answer is  "YES". We know that when we call Thread class’s start() method it in turns calls our implemented Runnable run() method. Then you would wonder, what is the point of stretching this topic further? But believe me, what we know is the half-truth.                                                                          start() method doesn't call run() method directly. It actually calls the  start0() method, which is a native method present in Thread class. Below is the  Thread class’s start() method snippet.             public synchronized void   start () {          if ( threadStatus != 0)            throw new IllegalThreadStateException();            group .add( this );          boolean started = false ;         try {            start0();            started = true ;        } finally {            try {               if (! started ) {    
Read more