>> 3)//TODO set a serial number
>> May I auto-generate a serialVersionUID for classes were missing,
>> or do you have some special policy about them I should be aware of?
>
> I never understood that part of Java, you are free to go :)

Please just remember that just because tools (like eclipse and others) warns about a missing serialversionUID it
does not mean it should be there. Simon Kicthing described it well in HBX-444:

"When you declare a serialVersionUID you're also declaring that you are aware of all the issues regarding serialising one version of a class and reimporting the serialized data into a different version of the class, and are promising to update the serialVersionUID whenever you make an *incompatible* change to the class.

However most people don't have a clue what is and what is not a serialization-incompatible-change to a class. In this situation I think the default behaviour (which is that the serialization mechanism declares incompatibility if *any* change occurs to the class) is much safer than having an auto-generated serialVersionUID on the class resulting in potientially corrupted objects on deserialization."

Just my 2 cents...
-max
_______________________________________________
hibernate-dev mailing list
hibernate-dev@(protected)
https://lists.jboss.org/mailman/listinfo/hibernate-dev