[hibernate-dev] Re: Hibernate Search: approval for changes, "commit conventions"?

[Sanne Grinovero]

2008/5/30 Max Rydahl Andersen <max.andersen at redhat.com>:
>>> 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
>

Thanks a lot Max for clarifying,
your 2 cents are valuable.

I knew about the requirement to change the UID, but really hadn't a
clue about the default behaviour:
I thought it was "unspecified" and I really dislike that word.
I agree with you it looks like safest to generally skip it, still I
was curious about the comment
"//TODO set a serial number" : someone thinks we need one, and
probably knows better than me.

Could it be useful (or do you have any requirement) to maintain
compatibility across "some" (please define) versions?

thanks,
Sanne