Re-serialization and deserialization
I noticed that some of my serialized objects stored in Redis have deserialization issues.
This usually happens when I make changes to an object class stored in Redis.
I want to understand the problem so that I have a clear design for a solution.
My question is what is causing the deserialization problems? Could there be a problem with removing public / private property? Perhaps adding new properties? Could you have a problem adding a new function to the class? How about additional constructors?
In my serialized object I have a Map property, what if I changed (updated some properties, added functions, etc.) myObject would cause a deserialization problem?
source to share
what causes deserialization problems?
I would like to give you some background before answering your question,
The serialization framework associates each serializable class with a version number called serialVersionUID, which is used during deserialization to verify that the sender and receiver of the serialized object are loading classes for that object that are serializable. If the receiver has loaded a class for an object with a different serialVersionUID than the corresponding sender class, then deserialization will throw an InvalidClassException.
If the class being serialized does not explicitly declare a serialVersionUID, then the serialization runtime will calculate the default serialVersionUID value for that class based on various aspects of the class. It uses the following class information to calculate the SerialVersionUID,
- Class name.
- Class modifiers, written as a 32-bit integer.
- The name of each interface, sorted by name.
- For each class field, sorted by field name (except private static and private transient fields:
- Field name.
- Field modifiers, written as a 32-bit integer.
- Field descriptor.
-
if a class initializer exists, write the following:
Method name,
Method modifier java.lang.reflect.Modifier.STATIC, written as a 32-bit integer.
Method descriptor, () V.
-
For each non-private constructor, sorted by method name and signature:
Method name,
Method modifiers, written as a 32-bit integer.
Method descriptor.
-
For each non-private method, sorted by method name and signature:
Method name.
Method modifiers, written as a 32-bit integer.
Method descriptor.
So, to answer your question,
Can there be a problem with the disposal of public / private property? Perhaps adding new properties? Could you have a problem adding a new function to the class? How about additional constructors?
Yes, all these default additions / deletions will cause a problem.
But one way to overcome this is to explicitly define SerialVersionUID, this will tell the serialization system that I know the class will evolve (or evolve) over time and not throw an error. Thus, the de-serialization system only reads the fields that are present on both sides and assigns a value. Added fields on the de-serialization side will get their default values. If some fields are removed on the de-serialization side, the algorithm just reads and skips.
Following is the way to declare SerialVersionUID,
private static final long serialVersionUID = 3487495895819393L;
source to share