Java serializable interface Implementation problem __java

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 applications. JavaBeans is a special class in Java that encapsulates multiple objects into an object (bean). The feature is serializable, providing an parameterless constructor that provides getter methods and setter methods to access the properties of the object. The "Bean" in the name is the idiom used for reusable software components in 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 generate events for other objects.
(3) There is software available to configure the Bean.
(4) The Bean's properties can be serialized for later reuse.

JavaBeans Specification:

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

(1) There is a public parameterless constructor.
(2) Properties can be accessed by get, set, are (which can be substituted for get, used on Boolean properties), 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 it does not meet the Java performance requirements.
Serializable

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

Serialversionuid

The serialization runtime uses a version number called Serialversionuid that is associated with each serializable class, which is used during deserialization to verify that the sender and receiver of the serialized object loaded the serialization-compatible class for the object. If the serialversionuid of the class of the object loaded by the recipient 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 that is named "Serialversionuid" (the field must be static (static), final (final) long field):

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

Any type can be saved to a file as long as the serializable interface is implemented, or sent to another place as a stream of data over the network. You can also use pipelines to transfer to other programs in your system. provide a case

As shown below in the two methods, there is no problem with the substance of the problem in their passing Sortingqualitycollection object (JavaBean):

The Save and update methods can execute successfully while the program is running, but it is confusing to find that the return state is always false, and it is hard to see that using spring AOP after debug is not a success, and the most direct error is that the Cglib resource does not exist. Very confused, the program executed successfully the statement of the update and insert is also printed in the background, the database is correctly recorded, because the return of false results in the program business processing can not be carried out.

Contrast procedure: View whether the data object and database fields are consistent, and whether the other JavaBean are specification. But these things still do not help, then the problem can only be locked on the JavaBean. JavaBean is generated by tools, Serialversionuid as follows:

The Serialversionuid is regenerated and the new Serialversionuid is as follows:

Rerun the program, the successful execution of the program, this shows that Serialversionuid's statement is very important, preferably after writing JavaBean manually generated, and display the declaration.