Re: [hibernate-dev] Re: Hibernate Search: approval for changes, "commit conventions"?
On May 30, 2008, at 02:31, Sanne Grinovero wrote:
2008/5/30 Max Rydahl Andersen <max.andersen(a)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?
Simon's explanation is the reason why I usually leave it out.
That being said, the class marked as "//TODO set a serial number" is
the WorkQueue. That's a left over. It really should have been
LuceneWork which is passed along serialized in JMS (and potentially
other ways of communication).
I have removed the TODO from WorkQueue and added a clear JavaDoc in
LuceneWork
* WARNING: This class aims to be serializable and passed in an
asynchronous way across VMs
* any non backward compatible serialization change should
be done with great care
* and publically announced. Specifically, new versions of
Hibernate Search should be
* able to handle changes produced by older versions of
Hibernate Search if reasonably possible.
* That is why each subclass susceptible to be pass along
have a magic serialization number
* NOTE: we are relying on Lucene's Document to play nice
unfortunately