java serialization version

http://c2.com/cgi/wiki?AlwaysDeclareSerialVersionUid

This is one of the JavaIdioms... You're making a class serializable. So you make it implement the Serializable interface. Now declare: private static final long serialVersionUID = 1;
If you don't define serialVersionUID, the system will make one by hashing most of your class's features. Then if you change anything, the UID will change and Java won't let you reload old data. You can get around this later by figuring out what hash value the system used for the old class and installing it by hand - it will be some random number like: private static final long serialVersionUID = -403250971215465050L;
This isn't a big problem, but it's ugly, prone to typos and it won't compress well. You gain nothing by postponing the declaration. You might as well use a value of 1 from the beginning. Plain and simple.
I feel fairly strongly about this, but that's due to an aesthetic sense that other people may not share. It hurts me to have 8 random bytes in the file when they could be 7 nice clean 0s and a 1. SerialVersionUIDs live forever. It doesn't seem right for them to preserve the accident of the original class feature hash. That data will be irrelevant after the class's first revision.
It took me a while of reading through the Serialization docs to come to this maxim. Then I wished someone had stated it upfront. I'm curious as to what other people do. -- DaveHarris
This idiom matches what we did - we defined a simple uid for all our classes, too. We made it the date - since we were inexperienced and had never used serialization before, we didn't know if we would ever change the uid, but if we did, we wanted to be able to say "all objects stored before this date won't file in": private static final long serialVersionUID = 19981017L;
-- StanSilver
To make the idea (as I'm understanding it) explicit: There is no need to worry about reading in the wrong class of object, just the wrong version of the object's class. Therefore, don't worry about IDs that distinguish classes, just IDs that distinguish incompatible versions of a class. Is that the idea? -- KielHodges
Not quite. It's that the default notion of incompatible versions is typically too strict. If you add a field, it changes the default serialVersionUID which prevents you loading old data, even though that's probably a benign change.