Am 19.08.2011 23:21, schrieb Alan Bateman:
Sebastian Sickelmann wrote:
OK. We need to change the serialversion. But is this enough? May we
break applications out there which serialized
NoSuchMechanismExceptions or extended classes? I have compiled it
with no explicit serialversionUID and started
./serialver javax.xml.crypto.NoSuchMechanismException
to show the generated serialversionUID. The new is 4170396067457259019L.
I don't have time to send a detailed reply on this now but we can't
change the serialVersionUID.
-Alan.
In normal closed Application Development you only ensure to mark the
serialization incompatible and ready.
If you need to store objects most developers are doing custom
xml-serialization (because peak brackets(translated from german term of
abuse for <>) are so sexy :-( ).
I think i know what you mean and how to solve it.
I think you mean somethink like this:
http://download.oracle.com/javase/7/docs/platform/serialization/spec/version.html
I was always interessted into how to make serialized object realy
versioned in a way designed for the jvm.
I will read this tomorrow and try to fix the changed
NoSuchMechanismException.
If i am totally wrong with my guess, this is no problem , than i have
read this specification and know more about a interessting topic. ;-)
-- Sebastian
