Java Serializable Interface Implementation issues

JavaBeans

To understand the serializable interface, first understand the basic JavaBeans. JavaBeans provides us with the simplest Java class entities that accompany the business to and fro in the application. JavaBeans is a special class in Java that can encapsulate multiple objects into an object (bean). The feature is serializable, providing a parameterless constructor that provides getter methods and setter methods to access the properties of the object. The "Bean" in the name is the usual term for reusable software components for Java.

JavaBeans Advantages:
(1) The bean can control whether its properties, events, and methods are exposed to other programs.
(2) The bean can receive events from other objects, or it can produce events to other objects.
(3) There is software available to configure the Bean.
(4) Bean properties can be serialized for later reuse.

JavaBeans Specification:

To become a JavaBean class, you must follow specific specifications about naming, constructors, methods. With these specifications, you have the tools to use, reuse, replace, and connect JavaBeans. The specifications are as follows:

(1) There is a public non-parametric constructor.
(2) Attributes can be accessed through get, set, is (can override get, use on Boolean properties) methods, or other methods that follow a specific naming convention.
(3) serializable.

JavaBean Example:

Note: The above is using the default Serialversionuid and will be warned because this does not meet the Java performance requirements.

Serializable

The Java class enables its serialization functionality by implementing the Java.io.Serializable interface. Classes that do not implement this interface will not be able to serialize or deserialize any of their states. All the subtypes of a serializable class are themselves serializable. The serialized interface has no methods or fields and is used only to identify the semantics of serializable. To allow the serialization of a subtype of a non-serializable class, you can assume that the subtype is responsible for saving and restoring the state of the super-type common (public), protected (protected), and (if accessible) package fields. A subtype is assumed to have this responsibility only if the subclass of the subtype extension (the parent class) has an accessible parameterless constructor to initialize the state of the class. If this is not the case, it is an error to declare that a class is a serializable class. This error will be detected at run time. During deserialization, the fields of the non-serializable class are initialized using the class's public or protected parameterless construction method. A serializable subclass must have access to a parameterless construction method. The fields of the serializable subclass are restored from the stream.

Serialversionuid

The serialization runtime is associated with each serializable class using a version number called Serialversionuid, which is used during deserialization to verify that the sender and receiver of the serialized object have loaded a serialization-compatible class for the object. If the serialversionuid of the object's class that the recipient loads differs from the version number of the corresponding sender's class, deserialization will cause invalidclassexception. A serializable class can explicitly declare its own serialversionuid by declaring a field named "Serialversionuid", which must be a static (static), final (final) long field:

If the serializable class does not explicitly declare Serialversionuid, the serialization runtime calculates the default Serialversionuid value for the class based on the various aspects of the class, as described in the Java (TM) object serialization specification. However, it is strongly recommended that all serializable classes explicitly declare the SERIALVERSIONUID value, because the default serialversionuid is highly sensitive to the details of the class and may vary depending on the compiler implementation. This can lead to unexpected invalidclassexception during deserialization. Therefore, to ensure consistency of serialversionuid values across different Java compilers, the serialization class must declare an explicit SERIALVERSIONUID value. It is also strongly recommended to use the private modifier to display the declaration Serialversionuid, if possible, because this declaration applies only to declaring the class immediately-the Serialversionuid field is not useful as an inherited member.
Classes that implement the Java.io.Serializable interface are serializable. Classes that do not implement this interface will not be able to serialize or deserialize their any state.
All subclasses of a serialized class are themselves serializable. This serialized interface has no methods and no fields, and is used only to identify the semantics of serialization. Allows the serialization of a subtype of a non-serialized class, the subtype can assume the state responsible for saving and restoring the domain of the parent type's public, protected, and (if accessible) package. As long as the class (that is, the parent class) has a parameterless constructor that initializes its state, the subtype can assume the above duties; if the class does not have a parameterless constructor, it is an error to declare a serializable class in this case. This error will be detected at run time.

Any type that implements the serializable interface can be saved to a file or sent to another location as a data stream over the network. You can also use pipelines to transfer to other programs in your system.

Provide a case

As shown in the two methods below, there is no problem with the substance of the Sortingqualitycollection object (JavaBean) that they pass on:

When the program is running, both the save and update methods can succeed, but the status of always returning is false, which is puzzling, after debug found that using spring AOP use is not successful, and the most direct error is to report that the Cglib resource does not exist. It is doubtful that the program executes successfully update and INSERT statements are also printed in the background, the database is correctly recorded, because the return of false causes the business process in the program can never go down.

Contrast process: see if the Data object and database fields are consistent, and whether the JavaBean is canonical. But it was useless to finish these things, and then the problem could only be locked on the JavaBean. JavaBean is generated by the tool, Serialversionuid as follows:

Then regenerate the Serialversionuid, the new Serialversionuid as follows:

Rerun the program, the program executes successfully, it is obvious that Serialversionuid statement is very important, it is best to manually generate after writing JavaBean, and display the declaration.

Java serializable interface implementation issues