> every serializable class needs a static final long "serialVersionUID"
> field
Yes, but static fields as a rule are not serialized by default. serialVersionUID is a special static field which is an indication to the serialization mechanism that 'persist the given instance with this version'. Even if a serialVersionUID is not provided, the serialization mechanism generates one based on the class structure / object hash code. Hence it would be a bit misleading stating that static fields are persisted when talking about serialVersionUID.
As long as no changes are made to the class, there is as such no problem ser/deser an object to persistent storage and retrieving from one with a default generated serialVersionUID. The problem arises when you make structural changes to the class which should in no way be treated as a different version [e.g. adding a method which has got nothing to do with ser/deser state of a class instance]. In this case, the serialization fails if a serialVersionUID field was not provided when defining the class.
So to cut long story short, don't think of serialVersionUID as a *static* variable stored to a persistent storage but as an indication to the serialization mechanism to *not* generate a default version number but use the one provided. To support this theory, every field persisted shows up in the serialized file i.e. if an object having instance variables "gogo" and "gaga" are persisted, the serialization file would show "gogo" and "gaga" with some other …