Serialization and Versioning of Classes

[Mohammad Faraziyan]

Hello,

I am writing a program which serializes objects in a file using
ObjectOutputStream and ObjectInputStream. In order to avoid any
deserialization
errors with a new version of my class in the future (e.g. when new
attributes, methods etc are added to the class),
I've defined following line of code in my class:

private static final long serialVersionUID = - 2767605614048989439L;

The serialVersionUID was computed using the "serialver" tool.

The JDK version I'm using is: 1.3.1_06-b01

Now my questions:

1) Is the usage of hard coded serialVersionUID an official java feature
to avoid any class versioning problems in the future?

2) Is this mechanism also supported in future versions of JDK? 1.4, 1.5,
etc?

3) Will the alghorithm for the computation for serialVersionUID change
in the future JDK versions?

4) Has anyone made any negative experiences with it? Which problems
might rise up in the future, if the
serialVersionUID is hard coded?

BR
Mohammad

 

[Thomas Weidenfeller]

1) Is the usage of hard coded serialVersionUID an official java feature
to avoid any class versioning problems in the future?

Yes, it is an official feature.

However, I have the feeling that you do things backwards. By setting an
own ID you declare your class being compatible to some previous version
that had the same ID - either explicitely set, or implicitely
calculated. You don't ensure compatibility to future versions by
setting the UID now.

Of course, setting the UID in a future version does not make that
future version compatible. You have to write the future version so that
it is compatible.

2) Is this mechanism also supported in future versions of JDK? 1.4, 1.5,
etc?

AFAIK there is no attempt to remove it.

3) Will the alghorithm for the computation for serialVersionUID change
in the future JDK versions?

Unlikely, it would break the whole mechanism.

4) Has anyone made any negative experiences with it? Which problems
might rise up in the future, if the
serialVersionUID is hard coded?

It is not necessary to hard-code the UID now. You need to set it in
future versions of the class if you want to tell the VM that the newer
version is compatible with an older on.

If you hard-code the UID now, I would suggest not to use the value from
serialver, but instead use a readable number like the one representing
the current date/time. E.g. "200310301440".

/Thomas

 

[Bent C Dalager]

It is not necessary to hard-code the UID now. You need to set it in
future versions of the class if you want to tell the VM that the newer
version is compatible with an older on.

If you hard-code the UID now, I would suggest not to use the value from
serialver, but instead use a readable number like the one representing
the current date/time. E.g. "200310301440".

I usually use "1" from the start. When a class uses an obviously
serialver-generated number, it just screams at me "we screwed up and
didn't find out about the versioning issue until we got bit by it"

Assuming that you do so from the very start of a class' life, I can't
see any drawbacks to starting at 1 and it's a lot more readable than
other, delibarately obfuscated, uids.

If, at some time in the future, I should decide to deliberately break
backwards compatibility, I'll increase it to 2.

Cheers
Bent D

 

[EJP]

However, I have the feeling that you do things backwards. By setting an
own ID you declare your class being compatible to some previous version
that had the same ID - either explicitely set, or implicitely
calculated. You don't ensure compatibility to future versions by
setting the UID now.

Of course, setting the UID in a future version does not make that
future version compatible. You have to write the future version so that
it is compatible.

No, *this* is backwards, sorry. (1) You should always declare a
serialveruid from the beginning of evolution, to save a *lot* of runtime
computation. (2) Revised classes are always compatible with streams from
prior revisions under deletion and insertion of fields - they are only
incompatible if you incompatibly change a type of an existing field. You
can get a lot more complicated with your own readObject/writeObject
methods if you know what you're doing, but Serialization does handle a
lot of versioning for you for nothing. See the spec.

AFAIK there is no attempt to remove it.

It is a defined feature of Java & cannot be removed without the result
being non-Java.

It is not necessary to hard-code the UID now. You need to set it in
future versions of the class if you want to tell the VM that the newer
version is compatible with an older on.

No, see above.

EJP