Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

class versioning  RSS feed

 
kiri
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I know that a serialVersionUID must be added to all subsequent versions of a class to maintain backwards compatibility. How would one handle the case where second version of the class did not specify a serialVersionUID to deserialize a serialized first version of the class.
I'm getting a "local class incompatible" error message due to different serialVersionUID values. That ones seems to come from the java serialization manager and cannot be overriden.
TIA
 
clio katz
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i've read a suggestion that you can just hard-code the serialversionuid of the first class into the second class. have you tried this?
 
kiri
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes, that would work. unfortunately the constraint is that the second class version cannot be modified. has anyone tried using custom loaders?
 
clio katz
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
now i'm curious...
is your final objective to
(1) permanently bootstrap [non-modifiable-class#2] so that it works with [serialized-class#1] objects, or
(2) do a one-time bootstrap to access [serialized-class#1-objects] with [non-modifiable-class#2]?
?
i'm asking because of your classloader question - your questions imply that you can't modify either class, but you can write code to work with them. can you be more explicit?
 
kiri
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the scenario is:
current application uses/loads permanently [non-modifiable-class#2]. the app needs to be able to restore serialized forms of [serialized-class#1]. currently it fails dues to mismatch of serialVersionUID. what I was thinking is at restore time if an incompatible exception is caught to load the class#1 via a custom loader, deserialize it and then invoke an assign method on class#2 passing the deserialized object as argument. would this work?
if I understood correctly your question this falls under case 1)
 
clio katz
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sounds tricky. given this 'black box' approach, there aren't many guarantees.
first concern would be that you're *sure* that your de-ser exception is *not* due to a platform issue (different compiler, compiler version, etc)
that said, .. in theory, you should be able to do this, providing you have .class files for at least class#1 ... (so you can get the serialversionuid that you'll need to deserialize it).
if there's a way to skip this step, i don't know what it might be [a custom loader workaround could be a lot of fruitless work if class1 is substantially "an unknown"]
but if you have .class files for either/both classes, you could try a quick hack like
1) bootstrap code: incorporate a Serializable class1/2 sub-class with the prior definition of class1 serialversionuid into your bootstrap code


2) catch de-ser exception,
3) try de-ser again with your bootstrap class

However, if you are considering writing a custom loader as a true bootstrap loader (to manage runtime loading of class(es) etc) *because* this is the only point where you can implement new code ... before i attempted that, i would try reverse-engineering the existing class resources - there may be other alternatives like writing a separate thread to monitor, lock, and convert the class2 obj into something readable by class1 ... or arranging the classpath to load your wrapper-logic before class2
rev engineering w reflection/introspection etc sb much easier than writing and testing a custom classloader for full app
 
Marilyn de Queiroz
Sheriff
Posts: 9080
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
kiri and clio cat,
Welcome to JavaRanch!
We ain't got many rules 'round these parts, but we do got one. Please change your display name to comply with The JavaRanch Naming Policy.
Thanks Pardners! Hope to see you 'round the Ranch!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!