serialVersionUID

[Eitan M]

Hello,

In some implementations I need to declare something like :
private static final long serialVersionUID = nnnn;



can the "nnnn" be by some hot-keys (Eclipse 3.3),

or should I make a number manually ?



Thanks

 

[Mike Schilling]

Hello,

In some implementations I need to declare something like :
private static final long serialVersionUID = nnnn;



can the "nnnn" be by some hot-keys (Eclipse 3.3),

or should I make a number manually ?

It can be anything you like. There's a program that comes with the JDK,
called "serialver", which will calculate for you the number that the JRE
would use if you didn't specify serialVersionUID explicitly. This is
valuable only if you're trying to keep compatibility with previous versions
of your class. Otherwise, you might as well start with 1, and increment the
number if you ever change the class incompatibly.

 

[Roedy Green]

can the "nnnn" be by some hot-keys (Eclipse 3.3),

or should I make a number manually ?

think of it as a class version number. When you change the layout of
the class, bump it up by one. See
http://mindprod.com/jgloss/serialization.html#SERIALVERSIONUID
for details.

I find it works best when you manually manage it.

 

[Esmond Pitt]

think of it as a class version number. When you change the layout of
the class, bump it up by one.

We've discussed this many times before, but I cannot see the point of
this practice. All that it does is change a *possible* serialization
exception arising out of a *possible* serialization incompatibility into
a *definite* serialization exception.

I personally leave it strictly alone, unless and until I get the
StreamCorruptedException or whatever exception it is that indicates the
incompatiblity. *Then* I have a think about what to do about it.

 

[Roedy Green]

I personally leave it strictly alone, unless and until I get the
StreamCorruptedException or whatever exception it is that indicates the
incompatiblity. *Then* I have a think about what to do about it.

The reason is you will get false incompatible streams. The algorithm
for default serial UIDs includes things that have nothing to do with
the stream format.

The danger of the practice is you will fail to change the
serialVersionUID when you HAVE changed the format.

 

[Thomas Hawtin]

The reason is you will get false incompatible streams. The algorithm
for default serial UIDs includes things that have nothing to do with
the stream format.

Even the version of javac used can change the generated serialVersionUID.

Tom Hawtin

 

[Esmond Pitt]

The reason is you will get false incompatible streams. The algorithm
for default serial UIDs includes things that have nothing to do with
the stream format.

I am talking about your recommendation to bump the serialVersionUID when
you change the class. You are now apparently talking about not providing
a serialVersionUID at all. This is not the same thing.

The danger of the practice is you will fail to change the
serialVersionUID when you HAVE changed the format.

I don't know what practice you're talking about here, but there is no
requirement to change the serialVersionUID when you have changed the
format in a compatible way, and little requirement to do so when you've
changed it in an incompatible way: all you're doing in that case is
changing one exception into another.

The danger of the practice you recommended is that you are quite likely
to introduce a gratuitous incompatibility.

Can we stick to the topic please?

 

[Esmond Pitt]

Even the version of javac used can change the generated serialVersionUID.

As the algorithm is very tightly specified in the Serialization
Specification and the JVM specification I find this rather difficult to
believe. I'm aware that GNU Java gets it wrong but I've never found any
evidence to suggest that GNU Java is Java in any useful way.

 

[Thomas Hawtin]

As the algorithm is very tightly specified in the Serialization
Specification and the JVM specification I find this rather difficult to
believe. I'm aware that GNU Java gets it wrong but I've never found any
evidence to suggest that GNU Java is Java in any useful way.

But the things it depends upon are less well specified. For instance,
according to section 4.6 of the serialization specification, <clinit> is
included in the hash. IIRC, if you target 1.4 you need <clinit> for
..class constants; if you target 1.5 the ldc instruction takes on that
roll. There are a number of bugs in the bug parade on the subject.

Again from section 4.6 of the serialization specification:

"Note - It is strongly recommended that all serializable classes
explicitly declare serialVersionUID values, since the default
serialVersionUID computation is highly sensitive to class details
that may vary depending on compiler implementations, and can thus
result in unexpected serialVersionUID conflicts during
deserialization, causing deserialization to fail."

http://java.sun.com/javase/6/docs/platform/serialization/spec/class.html

Tom Hawtin

 

[Mike Schilling]

I don't know what practice you're talking about here, but there is no
requirement to change the serialVersionUID when you have changed the
format in a compatible way,

In fact, there's good reason not t do that.

anlittle requirement to do so when
you've changed it in an incompatible way: all you're doing in that
case is changing one exception into another.

That is, changing it into an exception whose meaning is obvious rather than
obscure. I consider that desirable.

 

[Mark Thornton]

But the things it depends upon are less well specified. For instance,
according to section 4.6 of the serialization specification, <clinit> is
included in the hash. IIRC, if you target 1.4 you need <clinit> for
..class constants; if you target 1.5 the ldc instruction takes on that

It also depends on synthetic methods and the names of these aren't
specified at all.

 

[Mike Schilling]

It also depends on synthetic methods and the names of these aren't
specified at all.

It seems fairly silly to me that it depends on methods at all; why isn't it
based purely on the names and types of non-transient instance fields, that
is, the things that are going to be serialized? (And *not* their order, and
*not* their protection.)

 

[Roedy Green]

I don't know what practice you're talking about here, but there is no
requirement to change the serialVersionUID when you have changed the
format in a compatible way, and little requirement to do so when you've
changed it in an incompatible way: all you're doing in that case is
changing one exception into another.

The danger of the practice you recommended is that you are quite likely
to introduce a gratuitous incompatibility.

I explain fully at
http://mindprod.com/jgloss/serialization.html#SERIALVERSLIONUID

I seemed completely obvious to me you would not increment the id for a
compatible change. That is why you use it, to avoid spurious changes
when the format did not really change.

Was anyone else confused?

 

[Mike Schilling]

I explain fully at
http://mindprod.com/jgloss/serialization.html#SERIALVERSLIONUID

I seemed completely obvious to me you would not increment the id for a
compatible change. That is why you use it, to avoid spurious changes
when the format did not really change.

Was anyone else confused?

Not I, but I've been dealing with this sort of problem since long before
Java was still called Oak.

 

[Esmond Pitt]

Was anyone else confused?

Well obviously *I* was confused. Could it be this statement:

 

[Roedy Green]

Well obviously *I* was confused. Could it be this statement:

I have changed that at your insistence, but I write for the newbie
not he professor. The newbie will stay out of trouble if they assume
any change will get them in trouble.

If they start imagining they can predict when and when a change is
relevant and when not, they will soon be in hot water.

 

[Esmond Pitt]

I have changed that at your insistence, but I write for the newbie
not he professor.

I do not understand this. I didn't 'insist' on anything: I only pointed
out a self-contradiction in your page. What you do about that and who
you write it for is up to you.

The newbie will stay out of trouble if they assume
any change will get them in trouble.

So why not apply that philosophy to the serialVersionUID as well?

 

[Roedy Green]

I do not understand this. I didn't 'insist' on anything: I only pointed
out a self-contradiction in your page. What you do about that and who
you write it for is up to you.

I get several requests for changes every day. Yours about the rudest I
have received. Of course that does not count the death threats and
other abuse about the political parts of the site.

 

[Esmond Pitt]

I get several requests for changes every day. Yours about the rudest I
have received.

You have received no requests from me for changing that part of your
site. You've received a request for changing another part of your site
which gratuiously misrepresents of my work. To which you haven't
responded either publicly or privately.

Of course that does not count the death threats and
other abuse about the political parts of the site.

In other words this non-existent communication didn't threaten you with
death, and wasn't the rudest you have received.

Your point?