Q:

What means 1L serialVersionUID? When could I use this default value 1L?

There are 3 ways to define the serialVersionUID :
1. private static final long serialVersionUID = 1L; (Default)
2. private static final long serialVersionUID = -8940196742313994740L; (Generated)
3. Don't define serialVersionUID and let the JVM define it at runtime. @Lance Java

But I don't understand the first way!
I have seen it already, that somebody defines "serialVersionUID=1L" for all java-classes in source code.
What is the meaning? Is that useful?
If all classes have the same serialVersionUID 1L, is there no problem?

A:

What is the meaning? Is that useful?

Yes. The point of serialVersionUID is to give the programmer control over which versions of a class are considered incompatible in regard to serialization. As long as the serialVersionUID stays the same, the serialization mechanism will make a best effort to translate serialized instances, which may not be what you want. If you make a semantic change that renders older versions incompatible, you can change the serialVersionUID to make deserializing older instances fail.

If all classes have the same serialVersionUID 1L, is there no problem?

No - the serialVersionUID is per class.

A:

This is explain here:

The serialVersionUID is a universal version identifier for a Serializable class. Deserialization uses this number to ensure that a loaded class corresponds exactly to a serialized object. If no match is found, then an InvalidClassException is thrown.

From the javadoc:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:

Useful Links

java.io.Serializable
Why should I bother about serialVersionUID? (StackOverflow)
serialVersionUID in Java Serialization

A:

Yes, I've seen code that defined serialVersionUID like that too.  I think it is a bad idea.
In this context there is only one "distinguished" value for the serialVersionUID field; i.e. zero ... 0L.  Zero means "compute the version id at runtime by applying the standard algorithm" based on the actual class that you are serializing / deserializing.  That means that whenever your code's effective serialization signature changes, the serialization / deserialization code will use a different version id.  From a (big picture) type safety perspective, this is the safest thing to do, though it is also somewhat inefficient, and protentially more fragile.

What is the meaning? 

The 1L has no special meaning.  It is just a number that will match 1L as the "other" version id. 
To my mind, you are better off either using 0L, or a version number that was (at some point) generated using the standard algorithm.

If you use 0L, then you get definite deserialization exceptions if classes change in ways that could be source of problems.  If you need this, it is a good thing.
On the other hand you use a generated version id, you (the programmer) can make your own decision about when to regenerate the id.  And when you do decide to regenerate, the id will only change if the class signature has changed.  (If classes representation etc hasn't changed, the regenerated signature should be identical to the original one!)  And when the id does change, you can think about whether to add custom methods ('readObject', etc) to deal with the incompatibility.
However, if you use 1L, you can't tell if the version id needs to change without checking your code history, and comparing the old / new versions of the classes ... back as far as you need to.

Is that useful?

It depends on what you consider "useful" to mean.  If you think it is a good thing to hard wire the version id to "trust me, it is ok", then 1L is useful.

My recollection is that some versions of Eclipse offer 1L as one of the possible auto-corrections for a missing serialVersionUID field warning.  That is probable where the instances you see have come from.

