Facts: Serialization

1.      Transient and static fields are ignored in serialization.

After de-serialization transient fields and non-final static fields will be null.

Final static fields still have values since they are part of the class data.

2.      Serialization uses ObjectOutputStream.writeObject(object) and ObjectInputStream.readObject()  by de-serialization.

3.      Exception to handle:

Serialization:  IOException;

De-serialization: IOException, ClassNotFoundException.

ClassNotFoundException: The de-serializaed class type must be in the classpath.

4.      Uninitialized non-serializable, non-transient instance fields are tolerated.

Uninitialized : When adding “private Thread thread;”, no error in serializable.

However Initialized, “private Thread thread = new Thread();” will cause exception:

Exception in thread "main" java.io.NotSerializableException: java.lang.Thread at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.writeObject(Unknown Source) at com.howtodoinjava.demo.serialization.DemoClass.writeOut(DemoClass.java:42) at com.howtodoinjava.demo.serialization.DemoClass.main(DemoClass.java:27.

5.      Serialization and de-serialization can be used for copying and cloning objects.

It is slower than regular clone, but can produce a deep copy very easily.

6.      If I need to serialize a Serializable class Student, but one of its super classes is not Serializable, can Employee class still be serialized and de-serialized?

Yes, provided that the non-serializable super-class has a no-arg constructor, which is invoked at de-serialization to initialize that super-class.

7.      You must be careful while modifying a class implementing java.io.Serializable.

If class does not contain a serialVersionUID field, its serialVersionUID will be automatically generated by the compiler.

Different compilers, or different versions of the same compiler, will generate potentially different values.

8.      Computation of serialVersionUID is based on not only fields, but also on other aspect of the class like implement clause, constructors, etc.

So the best practice is to explicitly declare a serialVersionUID field to maintain backward compatibility.

If you need to modify the serializable class substantially and expect it to be incompatible with previous versions, then you need to increment serialVersionUID to avoid mixing different versions.