• Post Reply Bookmark Topic Watch Topic
  • New Topic

java 1.4 serializable incompatibilities  RSS feed

 
Chris Shepherd
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I'm having a problem moving to java 1.4 from 1.3. We have an app that I wrote in 1.3 thats saves stuff to file via an ObjectStreamField like this...

Then I use the writeObject and readObject to fill it or pull stuff out.
The problem is this. I keep getting this error.
java.io.InvalidClassException: javax.swing.AbstractListModel; local class incompatible: stream classdesc serialVersionUID = 2622425607724314306, local class serialVersionUID = -3285184064379168730
I'm almost positive its coming from the DefaultListModel in the object that uses the ObjectStreamField that I listed above. We already have save files out in "the wild" and changing to 1.4 will break them all unless I can find a way to get around this issue. I need 1.4 for some new stuff we are trying to do, so I would really rather find a fix than to go back to 1.3.

Thanks for any help you guys can give...
Chris
 
jason adam
Chicken Farmer ()
Ranch Hand
Posts: 1932
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wonder if this is somewhat related to using ObjectOutputStream. If you create a class, and instantiate an object for that class, and write the object to a file, it gets a UID associated with that object's class. If you make a change to the class, and recompile, you will find that you can no longer read the old object back from the file because it is no longer associated with the same UID that was originally written.
Appears the same situation might be happening here. The change from the class implementation from 1.3 to 1.4 is causing the stuff written to not be recognized. One of the biggest pains I've experienced with writing objects to a file, you're pretty much stuck with the implementation you wrote with.
Only way I've known to fix something like this is pulling the data from the file using an object of the original class, basically "copying" the data into a new object of the new class, and then rewriting. I'd love to hear of another way.
 
Chris Shepherd
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well there is actually a way to move your own objects from one version to the next easily. All you have to do is set your object's SUID in the declaration part of your object like this

That 100 is just a number I picked. As long as your current SUID matches the past ones you used, you won't get errors. So by setting it to something you won't change, your object will always carry forward with no problems.
When you change something(add a variable that you want saved, change the type of a variable) you just have to accomodate the change in your readObject and writeObject methods. Since the SUID is still the one you set it to, there are no errors in matching it to older versions of your object.
If you'll notice in my first post I put in a "version" variable. When you add a method to your object, your java defined SUID will change(and screw up all those saved files), but since we set it manualy, it will stay the same and won't break things. Since adding a method doesn't affect what you want saved, you just leave the object "version" as it was. If, however, you wanted to change a

to a

you just have to change the version number in your object and then check for it in your readObject method like this

This is getting long, so I'll stop, but its very handy for moving your own objects forward after making changes.
My problem is with changes that Sun must have made to their AbstractListModel... I guess I need to change my object so it doesn't rely on the ListModel objects. And there's the answer for my question, heyhey ..
Thanks for rubber ducking for me.
[ June 05, 2002: Message edited by: Chris Shepherd ]
[ June 05, 2002: Message edited by: Chris Shepherd ]
 
jason adam
Chicken Farmer ()
Ranch Hand
Posts: 1932
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cool, didn't know about setting the SUID manually, that will save me a huge amount of headaches in the future! Thanks for the info.
Rubber ducking you? Not familiar with the term, and it brings back unsettling memories of Sesame Street from when I was a kid. Ernie's "Rubber ducky, you're the one. Makes bathtime so much fun..." *shivers*
 
Chris Shepherd
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
well actually, that didn't fix my problem... I checked out the change file on 1.4 and Sun says that serialization from 1.3 will be broken and they suggest setting the SUID in your objects to carry forward. They don't mention what we should do about their objects that have changed...
I am having to write a conversion program to rewrite all the "wild" save files out there to the new save format which will only include primitives, strings, and primitive/String arrays. I'm hoping Sun doesn't screw those up in future versions. Its a pain, but it has to be done or I'm stuck with 1.3 forever... might as well get it over with now while the customers kind of expect some issues since the program is brand new.
But typically yes, setting the SUID on your objects really saves you time and effort. I *think* you can even use setting the SUID without rewriting the readObject and writeObject methods as long as you don't change any variables. Its really gotten cleaner for me tho by using my own. I always know exactly whats getting saved.
Oh yeah, rubber ducking is just sitting there and nodding wisely while I explain my problem. Sometimes in explaining the problem I can find the solution...
[ June 06, 2002: Message edited by: Chris Shepherd ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!