Description of serialVersionUID in Java and the difference between the two generation methods, serialversionuid

Description of serialVersionUID in Java and the difference between the two generation methods (reproduced), serialversionuid

Reprinted from: http://blog.csdn.net/xuanxiaochuan/article/details/25052057

 

SerialVersionUID:
To maintain version compatibility during serialization, that is, during version upgrade, deserialization still maintains the uniqueness of objects.
There are two generation methods:
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 attribute. For example:
Private static final long serialVersionUID = xxxxL;
For its definition, see the JDK documentation: http://download.oracle.com/javase/1.5.0/docs/api/java/io/Serializable.html

In Eclipse, there are two ways to add SerialVersionUid quickly.

Add default serial version ID:
Adds a default serial version ID to the selected type
Use this option to add a user-defined ID in combination with custom serialization code if the type did undergo structural change since its first release.

Add generated serial version ID:
Adds a generated serial version ID to the selected type
Use this option to add a compiler-generated ID if the type didnot undergo structural change since its first release.

One is 1L, and the other is to generate a large number. What are the differences between the two types?

It seems that the class of each class is different. It seems that the SerialVersionUid has a certain association between classes. In fact, neither of them can be seen from the JDK documentation. You only need to ensure that the SerialVersionUid can be changed for different versions of the same class based on compatibility requirements.

For the first type, you need to know which conditions are compatible and which ones are not compatible at all. Reference: http://java.sun.com/j2se/1.4/pdf/serial-spec.pdf

You can retain the old version number when it is compatible. If it is incompatible or you want to make it incompatible, You can manually increase the version number.

1-> 2-> 3 .....

The second method is the hash value generated based on the class structure. Adding or removing an attribute or method may change this value. I think this method applies to such scenarios:

The developer thinks that a new version number needs to be generated after each class modification and does not want to be backward compatible. The operation is to delete the original serialVesionUid declaration statement and then generate it automatically.

I personally think it is simple to use the first one. The second method can ensure that the version number is changed after the class structure is changed each time, but it still needs to be manually generated, instead of modifying the class. It will prompt you to update the SerialVersionUid, so although it looks cool, it is actually confusing.