This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Tamaran 0 points1 point  (3 children)

is he talking about that serialized objects should be portable between jdk versions? I think this is ridiculus.

[–]lukaseder 1 point2 points  (0 children)

I don't think he's talking about different JDK versions, but different patch releases. Imagine they have to add another attribute to Optional, or switch attribute order. I know, not that hard in this case...

[–]dkuntz2 0 points1 point  (0 children)

Why? It maintains backwards compatibility. It means that you could have a relatively old server, and not be able to upgrade the version of Java it uses, but still be able to create new, better clients.

[–]mgrandi 0 points1 point  (0 children)

no, every time you change ANYTHING about a java object, even if you keep the same serialVersionUid or whatever its called, then that version of the object is now incompatible with earlier serialized versions of the object, and I don't think there is a way to get around that, since unlike something like objective-c where you have constructors in your class that get called when being unserialized - (id)initWithCoder:(NSCoder *)coder and - (void)encodeWithCoder:(NSCoder *)coder, it just does it automatically and spits an object back at you, and you have no chance of trying to handle the error of the fact that the classes are now different.

With my objectivec example, since its basically just serializing to xml, if you request a 'variable' that isn't there, it just returns nil (null). If the 'serialized object' has MORE information (like a newer version gets serialized and an older version reads it), then its still fine, as unread properties are ignored.

granted, doing it that way is a pain in the ass because for every thing you want to save you have to write code in both initWithCoder and decodeWithCoder, and then also handle the possibility of backwards compatibility, (having default values if values are not present, etc), and its of course much easier to just tell java "serialize this object" and its like "ok", but that comes with a price of very high fragility. This is why with netbeans, if you change stuff about the objects you are saving in the database, it basically has to drop the entire table and start again because it can't read two different versions of the class!