It is often seen that there is a long string in the class, such as the private static final long Serialversionuid = -4667619549931154146l, the number declaration.
These are actually serializing this class, so why serialize it? Follow the network and JDK instructions below to learn:
Understanding:
Serialversionuid used to indicate compatibility between different versions of a class
Simply put, the serialization of Java verifies the consistency of the version by judging the serialversionuid of the class at run time. When serializing, 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.
When an entity (class) that implements the Java.io.Serializable interface does not explicitly define a variable named Serialversionuid, which is of type long, the Java serialization mechanism automatically generates a serialversionuid as a serialized version comparison based on the compiled class In this case, only the class generated by the same compilation will generate the same serialversionuid.
If we do not want to compile to force the software version, that is, the entity that implements the serialization interface is compatible with the previous version, the class that does not change, it is necessary to explicitly define a variable named Serialversionuid, type Long, Serialization entities that do not modify the value of this variable can be serialized and crossdress with each other.
Another disadvantage of not explicitly defining this property value is that it is not conducive to the porting of programs between different JVMs. Because different compilers implement this property value, the calculation strategy may be different, resulting in the fact that the class does not change, but because the JVM is different, there is a phenomenon that cannot be correctly deserialized due to incompatible class versions.
description of the JDK about the serializable interface:
The public interface Serializable class enables its serialization functionality by implementing the Java.io.Serializable interface. Classes that do not implement this interface will not be able to serialize or deserialize any of their states. All the subtypes of a serializable class are themselves serializable. The serialized interface has no methods or fields and is used only to identify the semantics of serializable.
To allow the serialization of a subtype of a non-serializable class, you can assume that the subtype is responsible for saving and recovering the state of the super-type, public, protected (protected), and (if accessible) package fields. A subtype can be assumed to have this responsibility only if the class with the subtype extension has an accessible parameterless constructor to initialize the state of the class. If this is not the case, it is an error to declare that a class is a serializable class. This error will be detected at run time.
During deserialization, the fields of the non-serializable class are initialized using the class's public or protected parameterless construction method. A serializable subclass must be able to access the parameterless construction method. The fields of the serializable subclass are recovered from the stream.
When traversing a drawing, you may encounter objects that do not support the Serializable interface. In this situation, the notserializableexception is thrown and the class that identifies the non-serializable object is identified.
If the serializable class does not explicitly declare Serialversionuid, the serialization runtime calculates the default Serialversionuid value for the class based on the various aspects of the class, as described in the Java (TM) object serialization specification.
Butstrongly recommendAll serializable classes explicitly declare the SERIALVERSIONUID value because the calculation of the default serialversionuid is highly sensitive to the details of the class, and varies depending on the compiler implementation, which can cause unexpected Invalidclassexception. Therefore, to ensure consistency of serialversionuid values across different Java compilers, the serialization class must declare an explicit SERIALVERSIONUID value.
Alsostrongly recommendUse the private modifier to display the declaration Serialversionuid, if possible, because such a declaration applies only to the direct declaration class-The Serialversionuid field is not useful as an inherited member. An array class cannot declare an explicit serialversionuid, so they always have a default computed value, but the array class does not have a requirement to match the Serialversionuid value.
a way to generate Serialversionuid is documented below:
1. Open the class in the IDE tool (this class already implements the Serializable interface)
2. Before looking for a class, there is a yellow bulb, click the light bulb.
3. A list of error prompts appears, click Add Generated serial Version Id again, and the Serialversionid will appear in the class;
Introduction and application of the serialized serializable interface in Java