Personally im against the serialization ids, it becomes too much of a pain
to maintain.
yes thats why we removed them.
But i have to say that really maintaining them is not that big of a
problem, because mostly you want them to stay equal
So that they are still being able to deserialize as much as possible,
I also don't get why the default one is so volatile why is that?
Because in my eyes the only thing that is importand are the non static
fields of a class.
Because that is youre data memory footprint of a instance.
But the default one when it is generated does keep track of anything,
methods innerclasses
And for example doing this:
Class clz = MyClass.class;
Is also a serial change.. (because of the generated code)
That is why i do prefer serial id's if you really need it, And you only
need it when you want to upgrade
a live system..
So if we all (or the majority) are saying we want full/better support of
upgrading wicket in an live environment
(Session are being able to restore them after the upgrade) then i think
we need to reintroduce them
You shouldn't need a serialization id unless you're jumping
between JVMs.
No this is as far as i know not the case.
Jumping between jvm's (the runtime onces) are perfectly doable i think
It is more a question which javac compiler is used
For example the exact same code that is compiled by javac and by eclipse
will throw serialization exceptions when talking to each other.
johan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
