On May 30, 2008, at 02:31, Sanne Grinovero wrote:
2008/5/30 Max Rydahl Andersen <[EMAIL 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
