Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 1.3.1
-
Fix Version/s: None
-
Component/s: Converters
-
Labels:None
Description
According to the XStream site, in the FAQ for "How does XStream deal with newer versions of classes?", it says "If a new field is added to the class, deserializing an old version will leave the field uninitialized."
However, if the new field has the same name as a superclass' private field, then upon deserialization, the new field is initialized with the parent's field's original value, and the parent's field is left uninitialized.
Attached is a unit test demonstrating the bug.
There's no way to handle this situation automatically. XStream writes normally an additional attribute for the "hidden" field and without it, it has to assume that the name is unambiguous. You may try to "omit" the new field reading the old XML.