Serialversionuid's role and how idea, Eclipse automatically generates SERIALVERSIONUID

Speaking of Serialversionuid, the first thing to say about serialization.

Serialization:

Serialization can transfer a Java object to a network in a binary stream and can be persisted to a database, file system, and deserialization is a Java object that can be re-constructed as a stream of binary data that was previously persisted in a database or file system.

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.

The role of serialization:

The first is to save a sequence of bytes of Java objects to a hard disk, usually in a file, so that the next time you need it, you can read the information before it.  Second: You can have a sequence of bytes of Java objects transferred across the network.

the implementation of serialization: 1 ), 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 is fully controlled by its own serialization behavior, whereas classes that implement the serializable interface can take the default serialization. There is no method for this interface, just to indicate that the class object can be serialized.   2)   3), deserialization process: Constructs a ObjectInputStream (object flow) object using an input stream (such as: FileInputStream), and then Use the ReadObject (object obj) method of the ObjectInputStream object to read the sequence of bytes from a source input stream, and then deserialize them into an object and return them.

The source code for serializable in Java sources is the following

 Public Interface Serializable {}

Why is it possible to serialize a serializable an empty interface?

The serializable interface is not about decoupling, it's about making the program and the JVM coupled.

The serializable interface is a convention with virtual machines, and the class that implements the serializable interface is like telling a virtual machine to "Let me have the ability to fly", and then the JVM gives your class the ability to fly.

I think there is no difference between the serializable and Public/static/final/int/synchronized keywords, both the program and JVM conventions, or the generalized "interface". You can think of serializable as a Java-language level or a system interface that is a JVM.

Any class that implements the Serializable interface has a static variable that represents the serialized version identifier: private static final long serialversionuid; This value can be specified by the class, or it can be unspecified. If not specified, Java calculates serialversionuid based on class.

Serialversionuid is a version identifier of a serializable class that uses the value of this identity when deserializing to determine whether the object types that are serialized and deserialized are consistent. 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 (invalidclassexception) occurs. When you implement a serializable interface in a class, the editor provides this hint function if you do not have a definition of serialversionuid, which tells you to define it.

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.

If you do not set this value, after you serialize an object, you change the field of the class or the method name, and so on, if you re-serialize the object you want to remove before you can throw an exception, because you change the information in the middle of the class, Serialversionuid is based on the class name, interface name, Member methods and properties are generated to generate a 64-bit hash field, and when the modified class is de-serialized, it is found that the Serialversionuid value of the class is inconsistent with the Serialversionuid value previously saved in the Ask price, so an exception is thrown.

There are two ways to build in eclipse:

One is the default 1L, for example: "Private static final long serialversionuid = 1L;" ；

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 = -8940196742313994740l;".

Note the following points for using Serialversionuid:

1. 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 classes that have not changed in the previous version, you need to explicitly define a variable named Serialversionuid, which is of type long. Serialized entities that do not modify the value of this variable can serialize and crossdress each other.

2. Remember that this field should always be included in a serializable class, even in the first class version, to remind yourself of the importance of this field. Do not change this field value in future versions unless you intentionally change the class so that it is incompatible with the old serialized object.

3. If your class is serialized to the top of the hard disk, you change the field of the category (Increase or decrease or rename), when you deserialize, there will be an exception, which will cause incompatibility problems. But when Serialversionuid is the same, it deserialize the different field with the default value of type, which avoids the incompatibility problem.

4. When our system does not need to serialize classes very often, you can remove these warnings and make the following settings: Window-->preferences-->java, serializable class without The Serialversionuid setting is changed from warning to ignore. Then eclipse compiles the program, and the warning messages disappear. However, if you are developing a large number of classes that require serialization, it is recommended that you revert to the original settings. This will ensure the performance and robustness of the system.

Serialversionuid's role and how idea, Eclipse automatically generates SERIALVERSIONUID