commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [chain2] serialVersionUID
Date Thu, 26 Jul 2012 20:10:23 GMT
Hi Elijah,

> I think that the date can work because we rarely update the ids.

+1

> In the end, I will change all of the ids to whatever format that we
> decide on. Do we want to have a vote or something about this?

not required IMHO, it can stay as you already modified them - maybe
just put a note/comment as a reminder for future committers.

As a 0.02 cents margin note: there are better serialization methods in
the place of default Java serialization, guess who's still using that
last one...

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Jul 26, 2012 at 9:16 PM, Elijah Zupancic <elijah@apache.org> wrote:
> @Benedikt - This reply isn't addressed to you I just replied to your
> message to continue the thread.
>
> Wow, folks. I had no idea that the serialization id would be such a
> big deal. I jumped the gun and checked in ids done in the date format
> because it sounded like a good enough solution. I really don't have an
> opinion on what approach that we use as long as we all agree on it.
>
> I think that the date can work because we rarely update the ids.
> Furthermore, all that matters is that a given id has been incremented
> from the last id.
>
> In the end, I will change all of the ids to whatever format that we
> decide on. Do we want to have a vote or something about this?
>
> Thanks,
> -Elijah
>
> On Thu, Jul 26, 2012 at 11:52 AM, Bruno P. Kinoshita
> <brunodepaulak@yahoo.com.br> wrote:
>>
>>
>>>________________________________
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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