I am not an expert on serialization, and it's been a long time since I
looked into it.
By a strange coincidence, the only cayenne project I wrote involving
serialization is the legacy Cayenne 1.2 app I am doing maintenance on
this week, after having not touched it in four or more years.
However, a quick google on the subject turns up these facts:
-- SerialVersionUID seems to matter on the generated subclass,
especially since this is where all of the state of CayenneDataObject
exists. But I can only infer this -- I cannot find a specific
statement. [1] [2]
- Having no SerialVersionUID is better than having a wrong or
unmaintained SerialVersionID since by default "the serialization
runtime will calculate a default serialVersionUID value for that class
based on various aspects of the class". [1]
- The default SerialVersionUID is only "bad" in that different JVM
runtimes may not return the same UID. Here is a simpler methodology
for generating a SerialVersionUID than building it ourselves which
should do what is necessary, so long as two compile processs do not
return the same value for a specific changed class.
Class cl = generatedClass.getClass();
long uid = ObjectStreamClass.lookup(cl).getSerialVersionUID();
The value of uid will be the same as the value printed out by
'serialver'. [3]
And this value would in turn be the same value used by the runtime
serialization.
[1] http://download.oracle.com/javase/1,5.0/docs/api/java/io/Serializable.html
[2]
http://java.sun.com/javase/technologies/core/basic/serializationFAQ.jsp#serialsuper
[3] http://www.jguru.com/faq/printablefaq.jsp?topic=Serialization
On Tue, Oct 4, 2011 at 5:48 AM, Durchholz, Joachim
<joachim.durchh...@hennig-fahrzeugteile.de> wrote:
> Are generated classes ever instantiated via new?
> If not, SerialVersionUID does not serve any useful purpose, it's the
> programmer-written subclass that gets asked for the SerialVersionUID.
> In that case, it may help to declare the generated classes abstract. Abstract
> classes cannot be deserialized, so the compiler should not complain.
>
> An aside note:
> Adding @SuppressWarnings might not be the best way to go, most warning names
> are not standardized and hence differ between compilers.
> I'm not sure whether "serial" is a standardized warning. I think it isn't but
> don't know the reference doc to use for checking.
>
> Regards,
> Jo
>
