Campbell Ritchie wrote:Ignore it. Then an object can be deserialised with all versions of its .class file.
If you ignore it - that is, if you don't provide an SVUID in the class - then one will be generated for you, based on the non-private attributes of your class. You will continue to get the same generated SVUID only as long as you don't change those parts of the class that are used to generate the SVUID. You can change code inside any method, for example, without changing the SVUID. But if you change the name of any non-private method, or add or remove a non-private method, you will get a new SVUID. Which means the new class file will be incompatible with the old one. This happens even if you never specified anything about the SVUID in the class.
Campbell Ritchie wrote:You can usually only get different SUIDs if you have different versions of the class, which usually means using different JVMs.
A common example where this can occur is if you've got an application that writes serialized data in order to look it up again the next time the application is run. If you update the code base and then restart the application, you can discover that you're no longer able to read the old serialized files.