My understanding is that this is a version control mechanism used in serialization/deserialization of objects to/from external sources (e.g. xml files, databases) to classes. Presumably this concerns mostly J2EE (server) programming.

"In anticipating the need to evolve a serializable class, Java serialization provides a serialVersionUID, also called suid,
in the ObjectStreamClass for version control. suid is used to inform the Java serialization mechanism which version of
the class is compatible with this serialized object. However, the importance of this field is often overlooked,
resulting in release incompatibility."

Every class implementing Serializable or extending a class that implements Serializable has a class version number generated by the compiler unless you specify the version number using serialVersionUID. This is useful when you serialize objects on the disk or across the network. In the first scenario you can imagine a "disconnect" between the serialized object on the disk and the class who tries to reload it. The instance can be written on the disk by one version of the class and loaded by a new version of the class let say after an upgrade. The same is true for the network scenario, the class sending can be at a different version than the class receiving.
If your class is not involved in one of these two scenarios, then just declaring the serialVersionUID = 1L is enough. If you actually use the serialization mechanism then you have to do more work in order to ensure your code doesn't break when you change the Serializable classes. This will involve implementing your own version of readObject and writeObject methods:

By the way, the format of the serialVersionUID value is up to you. Eclipse can generate a random number for you but it is better to use something simple like 1L, 2L etc or something like 20080504L. It is always better to have a controlled format.