Le 06/08/2011 19:00, Phil Steitz a écrit :
On 8/6/11 5:21 AM, Jörg Schaible wrote:
Sébastien Brisard wrote:

Hi,
I've just realized that many classes I've submitted do not define
serialVersionUID, which raises a warning. I have to say that it's
something I've never done myself, but I'd like to avoid the committers
the burden of inserting this. What's the rule for chosing this number?
(sorry for the silly question).
I started to use YYYYMMDD e.g. to day I would take 20110806L. It gives me a
hint when the number was chosen resp. binary compatibility was last broken.

Sounds reasonable.  Most of the earlier classes in [math] use the
ids generated by the JDK utility serialver.   I think Eclipse will
do that automatically, which is fine by me.  I am also OK with

I use eclipse for this.

I like Jörg suggestion too but have one question: is there a problem if two different classes have the same id ? They will differ by fully qualified class name, of course, but is it sufficient ?


Jorg's suggestion or James' (though in the latter case, I would
favor 42l - even though I am 42R ;).   The important thing is to put
something there and change it when a serialization incompatible
change is made to the class.

+1, despite I am lazy on this and change the number sometimes even if the changes are compatible. I also never tried to set up deserialization that would be aware of both past and current versions, as it would really be a nightmare to maintain

Luc


Phil

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to