If a class is Serializable, but there is no serialVersionUID field, then
Java makes up its own UID for the class. This changes if the fields
or methods change. So a tiny change to the class can result in serialisation failure.
If you give a serialVersionUID field in the class, and it is the same as one being read from a stream, Java will attempt to populate the object with the values from the stream. Any fields present in the stream, and missing in the class, will be ignored. Any fields present in the class, and missing in the stream, will be defaulted (normal Java rules apply).
Normally, the actual value of serialVersionUID does not matter all that much. You could use 1 for all classes. However, that would pretty much defeat all the checking, so might not be advisable.
One approach is to find out the UID of the first version of your class, when it doesn't have a serialVersionUID field, set serialVersionUID to that value, and leave it at that value forever. Or, at least, until you make changes that mean that old serialised streams really can't be read.
Another approach (what I usually do) is just to make up a random number in my head, when I first write the class.
If you have to read streams that were written before you added a serialVersionUID field,
you should set your serialVersionUID to the value in the stream (assuming there's just one value, else you're stuck).