What is the purpose of the serialVersionUID in the J2SE's Source Code?

[res7cxbi]

This question is self-explanatory

Just wondering why some of the creators of Java put this seemingly
useless long type number in their source code.

 

[SMC]

This question is self-explanatory

Just wondering why some of the creators of Java put this seemingly
useless long type number in their source code.

The idea is that if you change the class you change the serialVersionUID
(for classes that implement Serializable).

This is helpful when you've serialised an object of one version at some
point (like persisting and object to disk), and then deserialise it and
attempt to cast it into the new version of the object. The id's will
mismatch and you get an exception. A crude version safety mechanism.

 

[Roedy Green]

This question is self-explanatory

see http://mindprod.com/jgloss/serialization.html#SERIALVERSIONUID

 

[Roedy Green]

This question is self-explanatory

Just wondering why some of the creators of Java put this seemingly
useless long type number in their source code.

quoting from
http://mindprod.com/jgloss/serialization.html#SEIRALVERSIONUID

You can think of serialVersionUID as a primitive mechanism to record
which version of a class was used to create any particular historical
serialised file. Unfortunately, there is no tool to summarise a
mysterious serial file, telling you which classes it uses and which
versions of them. Hint, hint... If you try to read the file and you
guess incorrectly, it just blows up.

 

[Roedy Green]

Just wondering why some of the creators of Java put this seemingly
useless long type number in their source code.

here is more than you wanted to know about serialVersionUID . Your
answer is buried in there, as well as some other question you have
asked or are about to ask.

It is probably best to assign your own serialVersionUID for each
class:

static final long serialVersionUID = 3L;

This must change if any characteristics of the pickled Object change.
If you don't handle it manually, Java will assign one based on hashing
the code in the class. It will thus change every time you make a very
minor code change that may not actually affect the pickled Objects.
This will make it more difficult to restore old Object streams.

Note it is spelled serialVersionUID not SERIALVERSIONUID as is
traditional for static final constants.

You sometimes see bizarre, what appear to be random, numbers chosen
for the serialVersionUID. This is just a programmer freezing an
automatically generated serialVersionUID, because he forgot to assign
a sensible version 1 number to get started.

Not only should the base serialisable class get a serialVersionUID,
but also could each subclass get its own. That way you can
individually track which Objects are no longer consistent with the
class definition. The serialVersionUID does not have to be globally
unique. Think of it as a version number for tracking changes to the
code in a particular class independently of changes in its base class.
I just increment the serialVersionUID by one each time I modify a
class in a way that would change its serialisation characteristics
e.g.
Add a field.
Rename a field.
Change the type of a field.
Change the name of the package or class.
Delete a field
I don't increment when I:
reorder the fields.
add a method.
change the signature of a method.
rename a method.
Change or add a static field.

I am not sure it if is necessary to increment the serialVersionUID of
every subclass when a field in a class changes. If you find out,
please let me know.

You can think of serialVersionUID as a primitive mechanism to record
which version of a class was used to create any particular historical
serialised file. Unfortunately, there is no tool to summarise a
mysterious serial file, telling you which classes it uses and which
versions of them. Hint, hint… If you try to read the file and you
guess incorrectly, it just blows up.

To partly get around this problem, at the head of the serialized file,
as a separate Long, I write out the serialVersionUID of the key class
of the file. There, it is easily accessible as an identifier to how
old the serialised file is. It is automatically up to date. You can
also write a similar file type identifier Long as the very first
field.

 

[Stefan Schulz]

I am not sure it if is necessary to increment the serialVersionUID of
every subclass when a field in a class changes. If you find out,
please let me know.

If the field is exposed to the subclass (via protected, package-private
or public access), they you need to change the serialVersionUID. If the
field is private, i am honestly not sure either, but given the way
serialization works, it might just work.

 

[EJP]

If the field is exposed to the subclass (via protected, package-private
or public access), they you need to change the serialVersionUID. If the
field is private, i am honestly not sure either, but given the way
serialization works, it might just work.

You don't need to change the serialVersionUID of *any* class if the
change falls within the Serialization Versioning rules (#5.6.2).

 

[Roedy Green]

change falls within the Serialization Versioning rules (#5.6.2).

this is not covered in the JLS. Which document are you referring to.

 

[Lasse Reichstein Nielsen]

this is not covered in the JLS. Which document are you referring to.

Probably the Java Object Serialization Specification. The section number
matches the 1.5.0 version.
<URL:http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serial-title.html>

/L

 

[EJP]

Probably the Java Object Serialization Specification. The section number
matches the 1.5.0 version.
<URL:http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serial-title.html>

That's the one. Serialization isn't mentioned anywhere in the JLS that I
can see except under arrays. It's described briefly in the JPL # 15.7.5.

It's a common misperception, or urban myth, that you should change the
serialVersionUID with every class change. In fact this is exactly what
you should *not* do. Otherwise you are likely to get stuck some time
with unusable persistences, if you use Serialization for persistence.
Read the Serialization forum on the Java Developer Connection for
numerous horror stories.

You don't even need to use serialver, as the serialVersionUID doesn't
need to be unique, and it only needs to match the original default
serialVersionUID of the class (before you put the serialVersionUID in)
*if* you have ever deployed the class in that form. If you put
serialVersionUID in at the beginning of the class's life, it can be 0,
1, &c.

If you can manage to keep your class serialization-compatible via
extensions to the readObject/writeObject method, or the serializable
fields feature, there is never any need to change the serialVersionUID.