The 11th chapter of effective Java serialization

"Encode an object into a byte stream", known as serializing the object (serializing); The opposite process is called deserialization (deserializing), and once the object is serialized, its encoding can be passed from one running virtual machine to another, or stored on disk, for later use in the deserialization of a device. Serialization technology provides a standard line-level (Wire-level) object representation for remote communication, as well as a standard persisted data format for the JavaBeans component structure.

74th: The serializable interface is implemented with caution

cost One: sacrificing flexibility
The biggest cost of implementing the Serializable interface is. Once a class is published, it greatly reduces the flexibility of ' changing the implementation of this class '. If a class implements the Serializable interface. Its byte-stream encoding (or, in the serialized form, the serialized form) becomes part of its exported API. Once this class is widely used, it is often necessary to always support this serialization form as if you had to support all the other parts of the exported API.

Serialization can limit the evolution of a class. An example of this limitation is the unique identifier of the stream (stream unique
identifier), usually it is also known as the sequence version uid (serial version UID). Each serializable class has a unique identification number associated with it. If you do not explicitly specify the identification number in a long field named Serialversionuid private static final, the system automatically invokes a complex procedure based on that class, resulting in the identification number at run time. This automatically generated value is affected by the class name, the name of the date it implements, and the name of all public and protected members. If you change this information in any way, for example, by adding a less important tool method, the automatically generated sequence version UID will also change. Therefore, if you do not declare an explicit sequence version uid, compatibility will be compromised and cause invalidclassexception exceptions at run time.

Cost II: Security Vulnerabilities
The second cost of implementing serializable is that it increases the likelihood of bugs and security holes appearing. Typically, objects are created using constructors, and the serialization mechanism is an object creation mechanism other than a language (extralinguistic
Mechanism). Whether you accept the default behavior or override the default behavior, the deserialization mechanism, deserialization, is a "hidden constructor" with the same characteristics as other constructors. Because there is no explicit constructor in the deserialization mechanism, it is easy to forget to make sure that the deserialization process must also ensure that all "constraints established by a real constructor" are guaranteed. And does not allow an attacker to access internal information for objects that are in the process of being constructed.

value class or collection class can consider implementing Serializable
Implementing the Serializable interface is not a very easy decision to make. It provides some tangible benefits: if a class is going to be added to a frame, and the framework relies on serialization for object transmission or persistence, it is necessary for this class to implement the Serializable interface. Based on experience, value classes such as date and BigInteger should implement serializable, and most of the collection classes should. A class that represents an activity entity, such as a thread pool, should not implement serializable generally.

Classes designed for inheritance should implement the serializable interface as little as possible, and the user's interface should inherit as little as possible from the serializable interface.

75th: Consider using a custom serialization format

If the default serialization form is not considered appropriate first, do not accept it rashly.

Regardless of which serialization format you choose, declare an explicit sequence version uid (serial version UID) for each serializable class you write. This prevents the serial version UID from becoming a potential source of incompatibility.

The 11th chapter of effective Java serialization