[ACCEPTED]-Java serialization, UID not changed. Can I add new variables and method to the class?-serialization
If you hard-code the SerialVersionUID of 8 a class, (to 1L, usually), store some instances, and 7 then re-define the class, you basically 6 get this behavior (which is more or less 5 common sense):
- New fields (present in class definition, not present in the serialized instance) are assigned a default value, which is null for objects, or the same value as an uninitialized field for primitives.
- Removed fields (not present in class definition but present in the serialized instance) are simply ignored.
So the general rule of thumb 4 is, if you simply add fields and methods, and 3 don't change any of the existing stuff, AND 2 if you're OK with default values for these 1 new fields, you're generally OK.
Wow, a lot of bad information.
Java serialization 24 is +very+ robust. There are a very well 23 defined set of rules governing backwards 22 compatibility of objects with the same uid 21 and different data. the basic idea is that 20 as long as you don't change the the type 19 of an existing member, you can maintain 18 the same uid without data issues.
that said, your 17 code still needs to be smart about handling 16 classes with potentially missing data. the 15 object may deserialize correctly, but there 14 may not be data in certain fields (e.g. if 13 you added a field to the class and are deserializing 12 an old version of the class). if your code 11 can handle this, than you can probably keep 10 the current uid. if not, then you should 9 probably change it.
in addition to the pre-defined 8 rules, there are advanced usage scenarios 7 where you could even change the type of 6 existing fields and still manage to deserialize 5 the data, but that generally only necessary 4 in extreme situations.
java serialization 3 is very well documented online, you should 2 be able to find all this information in 1 the relevant sun/oracle tutorials/docs.
Want to define few point to highlight the 8 changes which impacts serialization. Below 7 you will find the link to Oracle Java Docs 6 for more details.
Incompatible changes to 5 classes are those changes for which the 4 guarantee of interoperability cannot be 3 maintained. The incompatible changes that 2 may occur while evolving a class are:
- Deleting fields
- Moving classes up or down the hierarchy
- Changing a nonstatic field to static or a nontransient field to transient
- Changing the declared type of a primitive field
- Changing the writeObject or readObject method so that it no longer writes or reads the default field data or changing it so that it attempts to write it or read it when the previous version did not.
- Changing a class from Serializable to Externalizable or vice versa.
- Changing a class from a non-enum type to an enum type or vice versa.
- Removing either Serializable or Externalizable.
- Adding the writeReplace or readResolve method to a class, if the behavior would produce an object that is incompatible with any older version of the class.
Link 1 from where the above information is taken http://docs.oracle.com/javase/7/docs/platform/serialization/spec/version.html#6678
This only matters if you let Java generate 7 a default UID for your class. It uses the 6 actual members and methods of the class 5 to generate it, thus making it invalid once 4 you change the class structure. If you provide 3 an UID for your class then this only matters 2 if you need to deserialize older versions 1 of your class from a file and such.
More Related questions