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

> 2008/5/30 Max Rydahl Andersen <max.andersen@(protected)>:
>>>> 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



_______________________________________________
hibernate-dev mailing list
hibernate-dev@(protected)
https://lists.jboss.org/mailman/listinfo/hibernate-dev