Changing serialVersionUID of objects serialized in a file.
For myResearch project I have created an application that saves it's data by placing its objects in an ArrayList and then serializing the ArrayList to file.
Up untill now it has been going swimmingly over 18 months. However, I am now for seemingly no reason encountering versioning errors when my app tries to de-serialise the objects. This happens for classes that I have not modified in any way.
I know now that I should manually set the serialVersionUID of my objects to overcome this in the future.
However, my core quesion is:
Can I change the serialVersionUID of the objects in the ArrayList of the serialized file. Otherwise I have to rebuild over 100 program save files.
Kind Regards,
Andrew.
# 2
And you have the solution back to front. Don't change the file, just set the serialVersionUID of your current classes to whatever the serialization exception tells you it is expecting.
I imagine you serialized them without any serialVersionUID. If they already had one when serialized, you must have already changed it in your source code, which is the last thing you should do when you already have serialized instances. There's an extensive urban mythology about changing serialVersionUIDs when you change the class and it is all complete nonsense.
ejpa at 2007-7-11 23:49:07 >
# 3
I have fourty two objects that get serialised.
They all have serialVersionUID like -6011647393756382469
You suggestion will not be a very elegent solution, as the numbers are meaningless.
Is it possible to de-serialise an object, change its serialVersionUID and then save it again.
Then I can give my classes more meaningfull serialVersionUID's and maintain compatibility with my files.
Andrew.
Message was edited by:
Scottie_UK
# 4
> They all have serialVersionUID like
> -6011647393756382469
>
> You suggestion will not be a very elegent solution,
> as the numbers are meaningless.
I do not know what you're talking about. SerialVersionUID numbers are meaningless. They are cryptographic functions of the class signature. They are not intended to be meaningful to anybody but the Serialization subsystem. If you're using them for some other purpose, you're breaking a cardinal rule of computing - a field should not be used for more than one purpose. Don't.
In any case the solution I gave is by a long chalk the most practical.
> Is it possible to de-serialise an object, change its
> serialVersionUID and then save it again.
Why on earth would you go to all this useless bother when you already have a solution?
ejpa at 2007-7-11 23:49:07 >
# 5
Well now wait. The serialVersionID is meant to track the version id of the object so that if you change the class footprint (IE make the serialized version invalid) it is will not deserialize. This prevents a broken instance from being created.
The short answer to your question is yes, but the why is kind of important and involves overriding the read and / or writeObject methods.
# 6
> if you change the class footprint (IE make the serialized version invalid)
But, laddie, changing the class footprint doesn't necessarily make the serialization invalid!
The versioning facilities built into serialization can cope with many kinds of class changes.
The only time you should change the serialVersionUID is when you want to make existing serializations invalid. When you don't, as here, all you need to do is adjust the read/writeObject methods if necessary: which it only is if you've gone outside what Serialization's versioning can handle.
I strongly recommend you familiarize yourself with this first before you inventing wheels.
ejpa at 2007-7-11 23:49:07 >
