Java: Warning questions about implements Serializable

About Myeclips hints the serializable class XXX does not declare a static final serialversionuid field of type long warning

When we use eclips/myeclips, this warning will appear, such as when using Hibernate, automatically generate the corresponding class of the table, there is this hint. What is this for?

This does not matter with the JDK version, which is the functionality that Eclipse provides.
You dot it warning the icon two eclipse will be given automatically, if you don't like it, you can turn it off,
Potential programming problems, error/warnings, compiler, preferences, windows
Change the warning of serializable class without serialversionuid to ignore.

In fact, if you don't consider the compatibility issue, then turn it off.
In fact, it is good to have this function. As long as any class is actually serializable this interface,
If you do not join Serialversionuid,eclipse will give you warning tips,
This serialversionuid to make the category serializable compatible.

Consider, if today your class serialized is stored in the hard disk,
But then you changed the field of the category (Increase or decrease or rename).
When you deserialize, there will be exception. This will make the problem of incompatibility.

But when Serialversionuid is the same, it deserialize the different field with the default value of type.

This avoids the problem of incompatibility.

================================================================

"Ohters"

Warning for "The Serializable class XXXXXXXX does not declare a static final seriaversionuid field of type Long"

The system always prompts you for three quick solutions:

1.add Default serial version ID

2.add generated serial version ID

3.add "suppress Warnings" ' servial ' to XXXXXXXX

First, preface

Serialversionuid, in short, is intended to serialize object versioning and is compatible with each version when deserializing. If this value is modified in the new version, the new version is incompatible with the old version, and the invalidclassexception exception is thrown when deserializing. If the modification is small, such as simply adding a property, we want backward compatibility, the old version of the data can be preserved, then do not have to modify; if we delete a property, or change the inheritance of the class, it is necessarily incompatible with the old data, then we should manually update the version number, that is, Serialversionuid.

Refer to the JDK documentation for its definition: http://download.oracle.com/javase/1.5.0/docs/api/java/io/Serializable.html

Second, the question

1. What happens if Serialversionuid is not explicitly set?

As explained in the JDK documentation, we recommend that we explicitly declare it, because if we do not declare it, the JVM will automatically generate a value for us, but this value is not consistent with the compiler's implementation, so it is possible to deserialize the Times Invalidclassexception exception in different JVM environments.

... it is strongly recommended this all serializable classes explicitly declare SERIALVERSIONUID values, since the default Serialversionuid computation is highly sensitive to class details the may vary depending on compiler implementations ...

2. What is the difference between two kinds of serialversionuid?

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.

Reference:

1. A better note about Serialvesionuid:

Http://www.mkyong.com/java-best-practices/understand-the-serialversionuid/

2.serialVesionUid related Discussions

http://stackoverflow.com/questions/888335/why-generate-long-serialversionuid-instead-of-a-simple-1l

3.compiler-generated ID Generation algorithm

http://java.sun.com/javase/6/docs/platform/serialization/spec/class.html#4100

Other Related questions:

Hibernate persistence, which generally refers to persisting data to a database, is not directly related to serialization.

Hibernate Pojo also does not require the implementation of the serializable interface, however, as a system extension, the PO should be implemented serializable interface, because if these objects need to be cached to disk, or used in a distributed environment, it must be serialized, The most common examples are ehcache, Memcached. Both the object in key and value must be a serialized object.

PS: Original Address http://hi.baidu.com/wojiubaibudu/blog/item/67aeb196eba8837e55fb968b.html

Java: Warning questions about implements Serializable