commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <>
Subject Re: [chain2] serialVersionUID
Date Thu, 26 Jul 2012 18:52:34 GMT

> From: Benedikt Ritter <>
>To: Commons Developers List <> 
>Sent: Thursday, 26 July 2012 3:28 PM
>Subject: Re: [chain2] serialVersionUID
>2012/7/26 sebb <>:
>> On 26 July 2012 18:29, Brent Worden <> wrote:
>>> On Thu, Jul 26, 2012 at 3:48 AM, sebb <> wrote:
>>>> On 25 July 2012 07:54, Jörg Schaible <>
>>>>> sebb wrote:
>>>>>> On 24 July 2012 09:11, Jörg Schaible <>
>>>>>>> Hi Elijah,
>>>>>>> Elijah Zupancic wrote:
>>>>>>>> Thanks Jörg!
>>>>>>>> It sounds like we will need to change them all in chain because
>>>>>>>> have changed the package name.
>>>>>>> Well, since they are all different objects now, the Java runtime
will not
>>>>>>> try to match them anyway, so it is for this special case not
>>>>>>> required.
>>>>>> +1
>>>>>>> However, if you consider a change, I'd like to propose to use
>>>>>>> a constant that reflects the day of change:
>>>>>>> servialVersionUID = 20120724L; // format YYYYMMDD
>>>>>>> It's easier then to keep track of changes.
>>>>>> +0
>>>>>> Ideally the svuid is only changed when necessary.
>>>>>> I don't think the id should be updated just because a new method
>>>>>> added, or code was updated.
>>>>>> The danger with using the date is that maintainers may update the
>>>>>> whenever the source is updated.
>>>>> I did not say that.
>>>> I know; but the fact that the id is a date may (mis)lead maintainers
>>>> into updating it too often.
>>>> If we do decide to use the day, maybe it should have a comment such as:
>>>> // YYYYMMDD date of last change to serialized form.
>>>>> - Jörg
>>> Since the serialized form will never change without a release, the
>>> svuid could also be aligned to the component version.
>> Yes, but the same issue applies: it may not be necessary to change the
>> svuid for each new version.
>> This is particularly true of patch releases.
>I really don't see an issue here. People who have commit access know
>what they do and their commits get reviewed by the ML. People who
>don't have commit access will get a double review. First from the
>person who applies a patch and then from the ML. I like Jörgs approach
>(and I have adopted it for my work).

Hi all, 

I'm no specialist in Java serialization, but I have one question (that may be stupid so I
apologize in advance :-) about using a date as svuid. 

Say that someone from Japan (GMT +9) commits a class to [functor] using svuid 20120727 at
00:30 AM. Then some 12 hours later I (based in Brazil, GMT -3) find a bug in his class, modify
a field or move the class to some other package. 

Then I would have to update the svuid, but as in my current timezone the svuid is 20120727
too, I would have to take some action, like waiting until the next day, increase the time
precision (+ timezone?) or ask here in the mailing list for help. What would be the correct
action in situations like this? 

And as I'm very lazy, I really like using the Eclipse feature to generate the svuid automagically
(I believe it uses JDK serialver tool), but with some practice I could get used to using any
other standard adopted by a project too :-)

Just my 0.02 cents. Hope that helps.


>>> Thanks,
>>> Brent
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Bruno P. Kinoshita

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message