Why removing the variable from the object's class during deserialization doesn't throw an Exception?

Question

Why removing the variable from the object's class during deserialization doesn't throw an Exception? What does the "incompatible" changes mean in Serialization then? I have also changed the field of the class from non-static to static which according to Java Specifications

is incompatible.

Answer 1

Why removing the variable from the object's class during deserialization doesn't throw an Exception?

Because it isn't supposed to. See the Object Versioning Specification, #5.6.1 :

"Deleting fields - If a field is deleted in a class, the stream written will not contain its value. When the stream is read by an earlier class, the value of the field will be set to the default value because no value is available in the stream. However, this default value may adversely impair the ability of the earlier version to fulfill its contract."

and

"Changing a nonstatic field to static or a nontransient field to transient - When relying on default serialization, this change is equivalent to deleting a field from the class. This version of the class will not write that data to the stream, so it will not be available to be read by earlier versions of the class. As when deleting a field, the field of the earlier version will be initialized to the default value, which can cause the class to fail in unexpected ways."

Nothing there about throwing exceptions.

Answer 2

• I got such doubt in an RPC call, and I seemed to have found the answer.
• I added two fields and changed one field type of a class in the server-side , then the client-side calls a method which returns the old version class. First, I got an exception for the unmatched filed type, so I fixed this but leave the added fields, it works well, it confused me.
• Then I came here, I haved read the specification :
  • 5.6.1 Incompatible Changes - Deleting fields
  • 5.6.2 Compatible Changes - Adding fields
  • They talk about the same thing - the serialized byte codes do not contain the field of the deserializing object, while our codition is that the serialized byte codes contains some fileds but the deserializing object does not.
• As I understand :
  • From the consideration of design, such deserialization feature is very useful especially in an RPC call, serialization function should contain it.
  • Deep into the principle, deserialization instantiates an object of the client-side class(old version) and sets values of its fields(probabaly uses reflect to got a value of a field from the serialized byte codes), the redundant field in the serialized byte codes sits silently with no visiting.