commons-dev mailing list archives

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


>________________________________
> From: Benedikt Ritter <beneritter@gmail.com>
>To: Commons Developers List <dev@commons.apache.org> 
>Sent: Thursday, 26 July 2012 3:28 PM
>Subject: Re: [chain2] serialVersionUID
> 
>2012/7/26 sebb <sebbaz@gmail.com>:
>> On 26 July 2012 18:29, Brent Worden <brent.worden@gmail.com> wrote:
>>> On Thu, Jul 26, 2012 at 3:48 AM, sebb <sebbaz@gmail.com> wrote:
>>>> On 25 July 2012 07:54, Jörg Schaible <Joerg.Schaible@scalaris.com>
wrote:
>>>>> sebb wrote:
>>>>>
>>>>>> On 24 July 2012 09:11, Jörg Schaible <Joerg.Schaible@scalaris.com>
wrote:
>>>>>>> Hi Elijah,
>>>>>>>
>>>>>>> Elijah Zupancic wrote:
>>>>>>>
>>>>>>>> Thanks Jörg!
>>>>>>>>
>>>>>>>> It sounds like we will need to change them all in chain because
we
>>>>>>>> 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
really
>>>>>>> required.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>>> However, if you consider a change, I'd like to propose to use
everywhere
>>>>>>> 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
was
>>>>>> added, or code was updated.
>>>>>>
>>>>>> The danger with using the date is that maintainers may update the
id
>>>>>> 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).
>
>Benedikt

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.

-Bruno


>
>>> Thanks,
>>>
>>> Brent
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>


Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com

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


Mime
View raw message