>> 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
