This is drifting further and further off topic, but there are some
important points in here..
> SerialVersionUID's do not change each time you compile a class - they
> are calculated by the JVM based on various aspects of the class that may
> affect it's serialization compatibility. So, if you don't change a class
> and you're using the same JVM, the class's calculated serialVersionUID
> will not change between builds.
>
Nobody said they would.... though there are lots of bugs in past JDKs
where it could happen.
> If you declare a serialVersionUID, you should do it in your domain
> classes rather than on Cayenne's generated superclasses
Actually, every class in the ancestry must have a matching
serialVersionUID, not just the base class. Thus, if the Cayenne
classes changed in the modeler, you would have an incompatibility
regardless of the serialVersionUID in the wrapper class. In fact if
your wrappers are empty, the serialVersionUID you declare there is
utterly meaningless.
It is pretty easy to demonstrate this..
The bottom line is that serialization is more than just a somewhat
complex issue. Jakarta Commons is littered with projects that have
serialization issues (commons-fileupload is my favorite example), from
developers who started out by saying serialization is easy and then
designed themselves into a corner.
There's a reason why serialization/externalization (aka RMI) never
really caught on for distributed apps... it is ugly and unnecessarily
complex.. that is why we need the 3T stuff in Cayenne 1.2 :)
Cris
This archive was generated by hypermail 2.0.0 : Tue Feb 14 2006 - 14:00:38 EST