This question is an exact duplicate of:
http://stackoverflow.com/questions/888335/why-generate-long-serialversionuid
Ironically, answered by Michael Bogswardt as well.
Michael Bogswardt's answer to generating a serialVersionUID got me thinking. Is there any reason to generate a proper serialVersionUID like eclipse and IDEA (or just plain serialver)? Or is plugging in a 1L just as good?
Once you write a number (any number) in there, it's your responsability to bump it when you make compatibility-breaking changes to the class (e.g. changing a JavaDoc doesn't break it, adding a property definitely does).
If you avoid specifying a serialVersionUID, javac will put there something unique like the hash of the class.
When does it matter? When you serialize stuff to disk and want to load it later with a different version of your program. Or when two instances which may be of different versions need to exchange serialized data over the wire.
If you don't use actual serialization and your class is Serializable just because it inherits that interface, then avoiding a serialVersionUID is the easiest and most safe thing to do. Same if you do serialize but don't really need to be compatible with the past, also in that case avoiding the value is the safest thing to do.
If, on the other hand, you need to load stuff produced with past revisions (either remotely or by yourself, from a long-forgotten file on disk) then you need to have that value and take much care to bump the number when (and only when) you do actually break the compatibility.
ADDED after second comment (by Robin):
Doesn't answer the actual question.
Err, right. I guess that's a: no as far as I know the actual number means nothing, it only has to be different from all previous value it had in previous times, when it is no more compatible with them.
Also, you should always declare a serialVersionUID for your Serializable classes
As a general suggestion, I think avoiding it is a better solution: most of the time you don't need to talk with JVM of different vendors, you don't need to de-serialize data from long past or actually need that compatibility check, most of the times serialized object are very short-lived.
Of course that can be very different for different projects and when you do have long-lived serialized object, well, you have to take the burden of defining those UID, and maintaining them correctly.
But as an absent UID means "fail fast, catch errors", while using 1L (or any other constant number) usually means "the class changes, you didn't remember to update it, problems arise later", then as a general suggestion, I think the first is a better default.
The only use of a "real" serialVersionUID is for backword compatibility. If it is a new class, use whatever numbering system you want.
Personally I think using a simple number scheme will make it easier to read and compare changes of that number between versions. The hash value creating by the tooling is fine for a machine, but not human friendly. A simple one up numbering scheme works great for both, after all, the machine doesn't care one way or the other.