Serialization in J2SE (3)

When to accept the default java serialization behavior
First, you need to understand the default serialization behavior of java. java saves all information about the object. That is to say, in some cases, those that do not need to be saved are also saved. Generally, we only need to save the logical data. You can use the key word transient to mark the data that does not need to be saved.
The following is an example:
Import java. io .*;
Public class Serial implements Serializable {
Int company_id;
String company_addr;
Transient boolean company_flag;
}
Then the company_flag field will not participate in serialization and deserialization, but you also add the responsibility for its initial value. This is also one of the common problems caused by serialization. Serialization is equivalent to a public constructor that only accepts data streams. This object constructor is out of the language. However, it is still a form of constructor. If your class cannot be initialized in other ways, you need to provide additional readObject methods. First, the normal deserialization is performed, and then the fields marked by transient are initialized.
When it is not suitable, using java's default serialization behavior may affect the speed. The worst case is that it may cause overflow. In the implementation of some data structures, various circular references are often filled, while java's default serialization behavior does not understand your object structure, the result is that java tries to save the object state through an expensive "graph traversal. It is conceivable that it is not only slow but may also overflow. In this case, you must provide your own readObject to replace the default behavior.
Compatibility problems
Compatibility has always been a complex and troublesome issue.
Not compatible:
First, let's take a look at what we should pay attention to if we aim to avoid compatibility. There are many scenarios where there is no compatibility. For example, war3 won't be able to read the previous replays whenever the version is upgraded.
Compatible, that is, version control. java uses a UID (stream unique identifier) to control it. This UID is implicit and is calculated by class name, method name, and many other factors, in theory, it is a one-to-one ing relationship, which is unique. If the UID is different, deserialization cannot be implemented and InvalidClassException will be obtained.
When we want to generate a new version (the implementation is not changed) and discard the previous version, we can achieve it through the explicit famous UID:
Private static final long serialVersionUID = ????;
You can create a version number, but do not repeat it. In this way, the old version will get InvalidClassException during deserialization. We can catch this exception in the old version and prompt the user to upgrade the new version.
Maintain compatibility when the changes are not significant (a special case of downward compatibility ):
Sometimes your class adds irrelevant non-private methods, but the logic field does not change, you certainly want the old version and the new version to maintain compatibility, the method is also implemented through an explicit famous UID. Let's verify it.