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

[Emmanuel Bernard]

On  May 30, 2008, at 02:31, Sanne Grinovero wrote:

> 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?


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