commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@gmail.com>
Subject Re: [chain2] serialVersionUID
Date Thu, 26 Jul 2012 20:18:22 GMT
2012/7/26 Bruno P. Kinoshita <brunodepaulak@yahoo.com.br>:
>
>
>>________________________________
>> 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,
>

Hi

>
> 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.
>

There are no stupid questions, only stupid answers! ;)

>
> 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.
>

Depends on the case. If you you are changing a field you have to
consider if that affects serialization. So you would have to change
the svid if objects serialized in an older version can not be
serialized back.
If you move the class to another package you have broken any
compatibility. So it doesn't really matter. Would be better to change
the svid to make this fact explicit. But from a technical point of
view it is not needed (correct me, if I'm wrong here)

>
> 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?
>

On my projects I'm using a layout that with a higher prescision
(YYYYMMDDHHMM) so that case rarely happens. In the case you described,
I would simply set the svid to 20120728.

Again I recommend reading the chapters about serialization in
effective java. Josh Blooch can explain it a lot better than I can ;)

HTH
Benedikt

>
> 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
>

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


Mime
View raw message