The explanation of Serialversionuid in Java and the difference between the two ways of Generation (reproduced)

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

Serialversionuid Effect:
Serialization preserves the uniqueness of the object in order to maintain version compatibility, that is, deserialization while the version is being upgraded.
There are two ways to build:
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 = XXXXL;
Refer to the JDK documentation for its definition: http://download.oracle.com/javase/1.5.0/docs/api/java/io/Serializable.html

In eclipse, there are two ways for us to quickly add serialversionuid.

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, one is to generate a large number, what is the difference between these two?

It seems as if this class of each class is different, it appears that the serialversionuid has some kind of association between the classes. In fact, both can be, from the JDK document also do not see this. We just have to make sure that in the same class, different versions will change the SERIALVERSIONUID according to compatibility.

For the first, you need to know what is compatible and which are incompatible. Reference Document: Http://java.sun.com/j2se/1.4/pdf/serial-spec.pdf

On a compatible basis, you can keep the old version number, if it is incompatible, or if you want it to be incompatible, increment the version number manually.

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

The second approach is to generate a hash value based on the structure of the class. Adding or subtracting a property, method, etc. can cause this value to change. I think this is the way to apply this scenario:

Developers think that each time the class is modified to generate a new version number, do not want backward compatibility, the operation is to delete the original SERIALVESIONUID declaration statement, and then automatically generated.

Personally, the general adoption of the first type on the line, simple. The second can be guaranteed to change the class structure after each change in the version number, but still to be generated manually, not modify the class, you will be prompted to update the Serialversionuid, so although it looks cool, in fact, people are very confused.

The explanation of Serialversionuid in Java and the difference between the two ways of Generation (reproduced)