serialVersionUID - can it be ignored?

[Mark Rafn]

Somehow I managed not to specify serialVersionUID in some Serializable
classes, and now have saved data with multiple logically-compatible but
serialVersionUID-incompatible formats.

I have since changed the code to specify a serialVersionUID, which will
prevent this in the future.

Is there any way to write code to read the multiple old versions, which
differ ONLY in serialVersionUID? Basically, I'd really love a subclass of
ObjectInputStream that just doesn't look at this field in objects it reads.

Looking at the ObjectInputStream javadoc, it appears I can subclass it and
write my own readObjectOverride, but it would appear to be quite a bit of
implementation to make it work.

Anyone know an easier way, or have any gotchas if I do it myself?

 

[Tom Hawtin]

Is there any way to write code to read the multiple old versions, which
differ ONLY in serialVersionUID? Basically, I'd really love a subclass of
ObjectInputStream that just doesn't look at this field in objects it reads.

The quickest hack would be to do a search and replace on the data.

I guess you can probably override ObjectStreamClass.readClassDescriptor.
If you call the super on that method, then it will call
ObjectStreamClass.readUTF for the class name, followed by
ObjectStreamClass.readLong. That does rely on implementation specific
details. You could read the data yourself (format is in the specs) and
just return a value from ObjectStreamClass.lookup, or from another
ObjectStreamClass.

Another alternative would be to use ClassLoaders to have two copies of
the class involved. In this case any instance of one class would not be
an instance of the other, so you would have to copy the data across
(probably via an intermediary, as no class can link to both of the
serialisable classes).

Tom Hawtin

 

[Mark Rafn]

The quickest hack would be to do a search and replace on the data.

I was afraid someone would suggest that. I guess I could subclass
ObjectInputStream so that it uses a private FilterInputStream which does
nothing but fixup serialVersionUID in the bytestream. Ick.

I guess you can probably override ObjectStreamClass.readClassDescriptor.

That's promising. I'll see how that goes.

Another alternative would be to use ClassLoaders to have two copies of
the class involved.

No good for me. Once in memory, I'm going to want to pass these around
normally, and having multiple distinct same-named classes gets very hairy.

Thanks for the ideas!