Are static variables serialized in Serialization process

Question

I'm stumbled upon understanding java serialization. I have read in many documents and books that static and transient variables cannot be serialized in Java. We declare a serialVersionUid as follows.

private static final long serialVersionUID = 1L; 

If a static variable was not serialized then, we often face an exception during the de-serialization process.

java.io.InvalidClassException 

in which the serialVersionUID from the deserialized object is extracted and compared with the serialVersionUID of the loaded class.

To my knowledge i think that if static variables cannot be serialized. There is no point of that exception. I may be wrong because I'm still learning.

Is it a myth that "Static and transient variables in java cannot be serialized". Please correct me, I'm in a mess about this concept.

Answer 1

1. Instance Variables: These variables are serialized, so during deserialization we will get back the serialized state.

2. Static Variables: These variables are not serialized, So during deserialization static variable value will loaded from the class.(Current value will be loaded.)

3. transient Variables: transient variables are not serialized, so during deserialization those variables will be initialized with corresponding default values (ex: for objects null, int 0).

4. Super class variables: If super class also implemented Serializable interface then those variables will be serialized, otherwise it won't serialize the super class variables. and while deserializing, JVM will run default constructor in super class and populates the default values. Same thing will happen for all superclasses.

Answer 2

serialVersionUID is a special static variable used by the serialization and deserialization process, to verify that a local class is compatible with the class used to serialize an object. It's not just a static variable as others, which are definitely not serialized.

When an object of a class is first serialized, a class descriptor containing among other things the class name and serial version UID is written to the stream. When this is deserialized, the JVM checks if the serial version UID read from the stream is the same as the one of the local class. If they're not, it doesn't even try to deserialize the object, because it knows the classes are incompatible.