serialization/deserialization mechanism

Question

Say, I have a class X which has a field value, that is,

class X implements Serializable {
    private int value;
    // ...
}

Further it has getters and setters not displayed here. This class is serialized. At the deserialzation, end same class has value field and access specifier is public. Further, this class does not have getters and setters. So, my questions are:

1. Does deserialization fail in case the access specifier of the field changes OR some or all of the methods go missing in the class at the deserialization end?
2. What is the mechanism by which fields are assigned their values during deserialization?

Answer 1

Some good links The Java serialization algorithm revealed

1) does deserialization fail in case the access specifier of the field changes OR some or all of the methods go missing in the class at the deserialization end ?

Serialization happens using Using Reflection

Java Detects the changes to a class using the

private static final long serialVersionUID

The default involves a hashcode. Serialization creates a single hashcode, of type long, from the following information:

• The class name and modifiers

• The names of any interfaces the class implements

• Descriptions of all methods and constructors except private methods and constructors

• Descriptions of all fields except private, static, and private transient

The default behavior for the serialization mechanism is a classic "better safe than sorry" strategy. The serialization mechanism uses the suid, which defaults to an extremely sensitive index, to tell when a class has changed. If so, the serialization mechanism refuses to create instances of the new class using data that was serialized with the old classes.

2) what is the mechanism by which fields are assigned their values during deserialization ?

Answer 2

The real details can be read in the Java Object Serialization Specification.

To answer your questions:

1. Serialization has a basic sanity check to see if the serialization ends use the same version of a class: the serialVersionUID member must be equal. Read the section Stream Unique Identifiers to know more about it. Basically, it's a static value which you can either manage yourself by declaring it on your class, or let the compiler generate one for you. If the compiler generates it, ANY change to a class will result in a change of serialVersionUID and hence will make the deserialization fail if the ends do not have exactly the same classes. If you want to avoid this, declare the variable yourself and update it manually when a change to the class' member variables does make classes incompatible.

2. The Java Virtual Machine does a lot of the magic here, it can access all internal state directly without the need for getters (fields marked transient or static aren't serialized though). Also, while the Serializable interface doesn't specify any methods to implement, there are a number of 'magic methods' which you can declare to influence the serialization process. Read section "The writeObject Method" and onwards to know more. Be aware though that you should use these sparingly as they might confuse any maintenance developers!