0

So, I have a large project that serializes many things when saving a configuration, and had to do a re-design of a large section of it. Since I had already defined the serialVersionUID field for a lot of classes, I wanted to know which files I needed to re-calculate the UID for.

I couldn't find any post on SO about what properties of a class were used in the calculation of the serialVersionUID (via ObjectStreamClass.lookup(classname) ). I finally found the spot in the spec that defines it. So, this is more of one of those self-answering questions for the sake of saving this small piece of knowledge.

If this is out-of-etiquette (since it is a spec question) please let me know, I'll gladly remove it or whatever is SO-appropriate.

So, what particulars of a class are used when using the Java-built-in algorithm of calculating a serialVersionUID?

Aaron Marcus
  • 153
  • 2
  • 13
  • If you've modified a serializable class, there's generally no need for you to recompute the serialVersionUID and update it. In fact if you do, you will guarantee that new versions of the class will be serialization-incompatible with the old ones. The point of serialVersionUID is to preserve compatibility, even if the class is modified. – Stuart Marks Sep 19 '14 at 15:32
  • Right, but if I am modifying the class, then it is already serialization-incompatible with the old ones, correct? It's not like I can deserialize an object with only 2 fields into an object with 7 fields and it even hope to work. So changing the serialVersionUID seems like a good way of preventing difficult-to-trace tomfoolery? – Aaron Marcus Sep 22 '14 at 16:17
  • Adding or removing fields isn't *necessarily* incompatible. If the class name or serialVersionUID are different, deserialization throws `InvalidClassException`. That's what I mean by "incompatible." If fields are added/removed but the classname and serialVersionUID match, deserialization is well-defined, though it might not make sense for the application. Briefly, fields "missing" from the serial data are filled with default values (zero, null, false). "Extra" fields in the serial data are ignored. Your code can deal with changed fields using `readFields/putFields` or `serialPersistentFields`. – Stuart Marks Sep 22 '14 at 17:56
  • On the other hand, if the changed fields are such that it doesn't make sense at all to make the different versions work from the application's point of view, then changing the serialVersionUID might be the right thing. – Stuart Marks Sep 22 '14 at 17:57
  • Glad my thinking is not crazy then :) It would indeed be rather useless given the changes to be backwards compatible in this project. – Aaron Marcus Sep 22 '14 at 19:20

1 Answers1

0

It's detailed right here in the Java spec!

http://docs.oracle.com/javase/6/docs/platform/serialization/spec/class.html#4100

Does anybody know if it's different based on different implementations/utilities? (Such as via ObjectStreamClass.lookup vs. serialver utility?)

Aaron Marcus
  • 153
  • 2
  • 13