What is

In practice, this number would be the version of your class. You should change it whenever you add, modify, or remove an attribute of the class.

Serialization

This is used during the process of serializing and deserializing an object / instance of that class.

Basically, serialization is the process where Java takes the value of each attribute and generates a sequence of bytes. Along with this sequence of bytes, go serialVersionUID .

Now deserialization is the inverse, that is, Java takes a sequence of bytes and places it on the attributes of a new object. Before doing this, it checks to see if the serialVersionUID saved is equal to that of the object being created.

In theory, this allows you to save a "photograph" of an object, for example, to a disk file, and then restore the object to the same values later.

The class has changed, and now?

But let's say you save an object to a file, modify your program by modifying the type of an attribute, run the program again and try to read the file for the object.

Something very strange may occur, since Java can not know that your class has been modified since you saved the file unless serialVersionUID is different .

In this case, the expected behavior is that the InvalidClassException exception is thrown, which makes it easier to figure out the problem, but does not solve the situation.

If you need to do custom operations during serialization or deserialization, Java allows you to implement, respectively, the writeObject and readObject methods where you will have full control over the process. See documentation .

Why does Eclipse issue a warning

For an object to be serialized it needs to be marked with the java.io.Serializable interface.

If Eclipse (or some other tool that analyzes the code) finds a class that implements Serializable directly or indirectly, it understands that it is a good practice to specify a serialVersionUID .

This can occur if the class:

• implements Serializable ;
• implements an interface that extends Serializable ; or
• extends a class that implements Serializable

What happens if I ignore it?

If you do not specify a serialVersionUID , but cause the class to implement Serializable , Java will use an automatic mechanism to generate serialVersionUID during class compilation.

The generated value is based on the characteristics of the class according to the Java language serialization specification. However, if you use serialization mechanisms, it is recommended that you specify serialVersionUID , since Java's automatic implementation may vary in some way between different versions or even distributions.

Why use serialization?

The most common scenario for using serialization occurs during communication between different Java processes, for example during remote calls (RPC) or in distributed web applications that share objects in session, where it sometimes occurs that a user's session to be migrated from one server to another if that user's requests are serviced by different servers at different times.

Problems can arise only if the servers are running different versions of the same program, so when objects are transmitted the destination server can not "unpack" the classes received from the source server.

Because of all these issues, it is best to avoid using serialization, either to save objects to disk, remote calls, or even session migrations.

In the cases above, saving objects in a more flexible and independent format, such as JSON or XML, will avoid problems with serialization. For remote calls, prefer a REST API. And to avoid session migration in clusters, do not depend on objects in session, but use stateless services whenever possible.

  

The serialVersionUID is a universal version identifier for a Serializable . In deserialization, this number is used to ensure that a loaded class exactly matches a serialized object. If no match of the object is found, then an InvalidClassException is thrown.

Note: Translated and adapted from: link