Eclipse issues warnings when a serialVersionUID
is missing.
The serializable class Foo does not declare a static final serialVersionUID field of type long
What is serialVersionUID
and why is it important? Please show an example where missing serialVersionUID
will cause a problem.
Don't bother, the default calculation is really good and suffice for 99,9999% of the cases. And if you run into problems, you can - as already stated - introduce UID's as the need arrise (which is highly unlikely)
Field data represents some information stored in the class. Class implements the
Serializable
interface, so eclipse automatically offered to declare theserialVersionUID
field. Lets start with value 1 set there.If you don't want that warning to come, use this:
First I need to explain the serialization.
Serialization allows to convert the object to stream,for sending that object over the network OR Save to file OR save into DB for letter usage.
There are some rules for serialization.
An object is serializable only if its class or its superclass implements the Serializable interface
An object is serializable (itself implements the Serializable interface) even if its superclass is not. However, the first superclass in the hierarchy of the serializable class, that does not implements Serializable interface, MUST have a no-arg constructor. If this is violated, readObject() will produce a java.io.InvalidClassException in runtime
All primitive types are serializable.
Transient fields (with transient modifier) are NOT serialized, (i.e., not saved or restored). A class that implements Serializable must mark transient fields of classes that do not support serialization (e.g., a file stream).
Static fields (with static modifier) are Not serialized.
When Object is Serialized JAVA Runtime Associates the serial version number that is called the serialVersionID.
Where we need serialVersionID : During the deserialization to verify that sender and receiver are compatible with respect to serialization.If receiver loaded the class with different serialVersionID then deserialization will end with InvalidClassCastException.
A serializable class can declare its own serialVersionUID explicitly by declaring a field named “serialVersionUID” that must be static, final, and of type long:.
Let's try this with an example.
Create Serialize Object
Deserializ the object
NOTE: Now change the serialVersionUID of the Employee class and save:
And execute the Reader class. Not to execute the Writer class and you will get the exception.
You can tell Eclipse to ignore these serialVersionUID warnings:
In case you didn't know, there are a lot of other warnings you can enable in this section (or even have some reported as errors), many are very useful:
and many more.
If you want to amend a huge number of classes which had no serialVersionUID set in the first place while maintain the compatibility with the old classes, tools like IntelliJ Idea, Eclipse fall short as they generate random numbers and does not work on a bunch of files in one go. I come up the following bash script(I'm sorry for Windows users, consider buy a Mac or convert to Linux) to make amending serialVersionUID issue with ease:
you save the this script, say add_serialVersionUID.sh to you ~/bin. Then you run it in the root directory of your Maven or Gradle project like:
This .lst includes the list of java files to add the serialVersionUID in the following format:
This script uses the JDK serialVer tool under hood. So make sure your $JAVA_HOME/bin is in the PATH.
Each time an object is serialized the object is stamped with a version ID number for the object's class.This ID is called serialVersionUID and it is computed based on information about the class structure. Suppose you made an Employee class and it has version id #333 (assigned by JVM),Now when you will serialize the object of that class (Suppose Employee object), JVM will assign UID to it as #333.
Consider a situation - in the future you need to edit or change your class and in that case when you modify it, JVM will assign it a new UID (Suppose #444). Now when you try to deserialize the employee object, JVM will compare serialized object's (Employee object) version ID(#333) with that of the class i.e #444(Since it was changed). On comparison JVM will find both version UID are different and hence Deserialization will fail. Hence if serialVersionID for each class is defined by programmer itself. It will be same even if the class is evolved in future and hence JVM will always find that class is compatible with serialized object even though the class is changed. For more Info you can refer chapter 14 of HEAD FIRST JAVA.