Serialization: a process which converts a Java instance into a bunch of bytes, so it can be stored in disk/database or transferred through network.
Deserialization: the opposite of Serialization, in which a Java instance is extracted and recovered from disk/database/network.
To make the Serialization and Deserialization work for a Java class, you only need to implement Serializable in most cases.
In the following example, we will create a class called
Address, serialize it using
WriteObject and deserialize it using
WriteObject to Serialize
C:\address.ser, you can change it to another path if you use Linux or Mac**OS.
readObject to Deserialize
C:\address.ser. And you can see from the console that we have obtained the serialized data in
Street : wall street Country : united states
The whole process is illustrated as follows.
What happened in the background was that Java serialized each field in
country) into disk and read it when the deserialization was done. But does Java know how to serialize/deserialize
country? Yes, because they are of type String, which also implements Serializable, and Java has its own rules to convert a String instance into a stream of bytes, so they can be written into disk.
Everything seems to be working fine, right? No, because you forgot to add
Address. The correct version is this.
serialVersionUID? and why should I add it? Basically
serialVersionUID is simply a number that is written into disk along with the serialized instance. And in the process of deserialization, Java checks whether the serialized
serialVersionUID is the same as the one declared in class. If not, an exception will be thrown and deserialization will fail. It is used to make sure the serialized instance is compatible with the current class.
serialVersionUID can be set manually by the programmer with any number, or you can generate one using serialver provided by Oracle.
Java will generate one for you based on class name, implemented interfaces, etc. But this is highly discouraged. Quote from Oracle doc:
It is strongly recommended that all serializable classes explicitly declare
serialVersionUIDvalues, since the default
serialVersionUIDcomputation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected
serialVersionUIDconflicts during deserialization, causing deserialization to fail.
For example, if you don’t set
serialVersionUID manually, Java may generate a
serialVersionUID = 12345 for you in the process of serialization. However, the deserializing program may use a different JVM and the
serialVersionUID it gets may be
123456, which is different because of different calculation algorithms. Then the program finds that the two
serialVersionUIDs don’t match and throws an exception to tell the user that the deserialization fails.
You should update
serialVersionUID when some incompatible fields are added to the class and it’s no longer possible to be support the old version.
That’s it. Below are some links that I found helpful when I was writing the article.