Serialversionuid in Java

The serialization mechanism for Java is to validate version consistency by judging the serialversionuid of the class at run time. When deserializing, the JVM compares the serialversionuid in the stream that is transmitted to the serialversionuid of the local corresponding entity (Class), and if the same is considered consistent, it can be deserialized, otherwise the serialized version inconsistency exception will occur.

Eclipse in the Serializable class XXXXXX does not declare a static final serialversionuid field of type long appears such a warning handling method.

When using the program's add default Serial version ID fix, Eclipse adds: private static final long serialversionuid = 1L;

When using the program's add generated Serial version ID fix, Eclipse adds: private static final long serialversionuid = XXXXL;

In fact, the specific reason for this problem is related to this serialversionuid in serialization.

Serialversionuid is used to indicate compatibility between different versions of a class. There are two ways to build:

One is the default 1L, for example: private static final long serialversionuid = 1L; (corresponding to fix Method 1)

One is to generate a 64-bit hash field based on the class name, interface name, member method, and property, for example:
Private static final long serialversionuid = XXXXL; (corresponding to repair method 2)

In the JDK, you can use the Serialver.exe tool under the Bin directory of the JDK to generate this serialversionuid value, and for Test.class, execute the command:
Serialver Test the JVM (Java Virtual machine) generates a hash field.

Comparing the value of this hash field to the field value generated in Method 2, it is visible that using the serialver directive in CMD generates a hash field based on the class name, interface name, member method, and property.

The following is a discussion of why the Serialversionuid property needs to be overloaded in Java classes.

When two processes are communicating remotely, each other can send various types of data. Regardless of the type of data, it is transmitted over the network in the form of a binary sequence. The sender needs to convert the Java object to a sequence of bytes to be transmitted over the network, and the receiver needs to revert the byte sequence back to the Java object.

The process of converting a Java object to a sequence of bytes is called serialization of an object.

The process of reverting a sequence of bytes to a Java object is called deserialization of the object.

There are two main uses for serialization of objects:

1) The object's byte sequence is permanently saved to the hard disk, usually stored in a file;

2) A sequence of bytes that transmits an object over the network.

Java.io.ObjectOutputStream represents an object output stream, and its writeobject (object obj) method serializes the Obj object specified by the parameter and writes the resulting sequence of bytes to a target output stream.

Java.io.ObjectInputStream represents an object input stream, and its readobject () method reads a sequence of bytes from a source input stream, deserializes them into an object, and returns them.

Only objects of classes that implement the serializable and Externalizable interfaces can be serialized. The Externalizable interface inherits from the serializable interface, and the class that implements the Externalizable interface controls the serialization behavior entirely by itself, whereas classes that implement the serializable interface can take the default serialization method.

Any class that implements the Serializable interface has a static variable that represents the serialized version identifier: private static final long serialversionuid;

The default value of the Serialversionuid class is entirely dependent on the implementation of the Java compiler, and compiling with different Java compilers for the same class may lead to different serialversionuid and possibly the same. To improve the independence and certainty of serialversionuid, it is strongly recommended that the definition serialversionuid be displayed in a serializable class, giving it a definite value. There are two ways to explicitly define SERIALVERSIONUID:

1) On some occasions, you want different versions of the class to be serializable compatible, so you need to ensure that different versions of the class have the same serialversionuid, and in some cases, you do not want different versions of the class to be serializable compatible. It is therefore necessary to ensure that different versions of the class have different serialversionuid.

2) When you serialize a class instance and want to change a field or add a field without setting serialversionuid, any changes will result in the inability to deserialize the old instance and throw an exception when deserializing. If you add serialversionuid, the newly added or changed field value will be set to the initialization value (the object is null, the base type is the corresponding initial default value) when the deserialization is old, and the field is deleted without setting.

When the system does not need to serialize the class, you can remove these warnings, do the following settings: Window-->preferences-->java, will serializable class without The Serialversionuid setting is changed from warning to ignore. Then eclipse compiles the program, and the warning messages disappear.

The web site in the struts architecture often has javax.servlet.ServletException:BeanUtils.populate errors, but the local run is all right, and the only thing that could be problematic is that the server ran several websites, Are the same architecture, wondering if the Web container has shared the Java classes between several projects, considering that many classes have defined the Serialversionuid field and then tried to delete the serialversionuid of a class, the result is that the operation on that class is back to normal. A simple look at the information on the Internet, the feeling is that Tomcat to serialize all classes, because of our several projects a lot of Java classes are copied and pasted, so many classes of serialversionuid are the same value, So tomcat would treat classes of the same class name in different projects as the same class, causing this strange error.

Solution:
Each project with the same name Serialversionuid changed to a different, not directly copied and pasted over.

Serialversionuid in Java