2012/7/26 Bruno P. Kinoshita <brunodepau...@yahoo.com.br>: > > >>________________________________ >> From: Benedikt Ritter <benerit...@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 <seb...@gmail.com>: >>> On 26 July 2012 18:29, Brent Worden <brent.wor...@gmail.com> wrote: >>>> On Thu, Jul 26, 2012 at 3:48 AM, sebb <seb...@gmail.com> wrote: >>>>> On 25 July 2012 07:54, Jörg Schaible <joerg.schai...@scalaris.com> wrote: >>>>>> sebb wrote: >>>>>> >>>>>>> On 24 July 2012 09:11, Jörg Schaible <joerg.schai...@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-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 >> >> >> >> > > > Bruno P. Kinoshita > http://kinoshita.eti.br > http://tupilabs.com > > --------------------------------------------------------------------- > 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
