Why does the serialVersionUID field exist?

问题:

It has baffled me from the launch of the Serializable interface why I have to incorporate this field in all of my classes. I understand that this interface needs a unique identifier to mark the class but why cant they generate this at run-time. For instance they could generate it using an MD5 hash of the fully-qualified class name or a similar methodology used to handle duplicates in their rare occurrence (Which is, I'm sure, what eclipse does when asked to generate the id anyway).

So what I'm asking (no this post isn't just a rant against the standard library) is exactly how the serialization field is used by the framework?

The reason I would like to know because I am going to try to create an Aspect (in AspectJ or other language) that will add the serialVersionUID field using an MD5 hash and is able to handle collisions in a way that is acceptable to the API.

I will post the results if I can get it working.

回答1:

There is no requirement to have the serialVersionUID field. If you don't provide one, Java will generate one based on the fields and methods of your class.

The reason why you might want to specify serialVersionUID is to prevent the value from changing when methods are changed, which doesn't impact the serialized binary. Consider the class:

public class Person implements Serializable {
    private String name;
    public String getName() {
        return name;
    }
}

No serialVersionUID was specified. If you run serialver Person it returns:

Person:    static final long serialVersionUID = 3793453319058452486L;

Now you decide to add a method but leave the fields the same.

public class Person implements Serializable {
    private String name;
    public String getName() {
        return name;
    }
    public Object foo() {
        return "bar";
    }
}

The serialized binary is still fully compatible with the old version, but the serialVersionUID is different:

Person:    static final long serialVersionUID = -6188734029437600310L;

With a different serialVersionUID, deserializing will result in a serialVersionUID mismatch error. The workaround is declare your own serialVersionUID by setting it to any value (I set it 1L), and changing it whenever the fields have changed.

Also see this related question "What is a serialVersionUID and why should I use it?" for a more detailed discussion.

回答2:

why I have to incorporate this field in all of my classes

You don't.

why cant they generate this at run-time

They do, unless you provide it yourself.

I am going to try to create an Aspect (in AspectJ or other language) that will add the serialVersionUID field using an MD5 hash

That would be pointless. You don'understand what it's for. Generating it at runtime is what already happens by default, so your proposal adds no value. The value comes in specifying it at compile time so as to absorb minor class changes that don't actually break object versioning compatibility. You can't accomplish that via AOP. It is a coding decision.

回答3:

The Serializable interface

This interface exists in the java.io package. This is implemented to protect the minor changes and is implemented to enable the user to write and save the objects at runtime. This interface is implemented by all the swing components because the developer can extend them so that JVM could find the new version of the component ie., Your class.

SerialVersionUID

The serialVersionUID is used as a version control in a Serializable class. If you do not explicitly declare a serialVersionUID, JVM will did it for you automatically, based on various aspects of your Serializable class, as describe in the Java(TM) Object Serialization Specification

回答4:

As @Steve Kuo mentioned, it's not required to have the serialVersionUID field.

It is frustrating, since it is not enforced as part of the contract for an Object to be serializable, about half the developers on our team do it, and the other half don't. The majority that do usually just set private static final long serialVersionUID = 1L; (though some developers like to use it as an opportunity to try their hand at coming up with pseudorandom Longs ...)

That having been said, I have always understood it to be a rudimentary attempt at versioning Serializable objects.

Let's say we have:

public class PersonDTO implements Serializable {

    private static final long serialVersionUID = 1L;

    private String firstName;
    private String lastName;

    // Appropriate getters/setters of course
}

and later we were to add a new field, private String middleInitial.

If we were to bump the serialVersionUID to 2, we could use that to indicate that the class has changed, and older already-serialized instances of PersonDTO with serialVersionUID cannot be deserialized with this modified class definition.