Re: [chain2] serialVersionUID
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 MMDD 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: // MMDD date of last change to serialized form. - Jörg - 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
Re: [chain2] serialVersionUID
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 MMDD 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: // MMDD 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. Thanks, Brent - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain2] serialVersionUID
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 MMDD 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: // MMDD 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. 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
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 MMDD 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: // MMDD 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 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
Re: [chain2] serialVersionUID
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 MMDD 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: // MMDD 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-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
Re: [chain2] serialVersionUID
@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 brunodepau...@yahoo.com.br wrote: 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 MMDD 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: // MMDD 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-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
Re: [chain2] serialVersionUID
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 eli...@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 brunodepau...@yahoo.com.br wrote: 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 MMDD 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: // MMDD 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe
Re: [chain2] serialVersionUID
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 MMDD 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: // MMDD 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 (MMDDHHMM) 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
Re: [chain2] serialVersionUID
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 MMDD 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. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain2] serialVersionUID
Thanks Jörg! It sounds like we will need to change them all in chain because we have changed the package name. -Elijah On Mon, Jul 23, 2012 at 10:51 PM, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Elijah Elijah Zupancic wrote: Hi everyone, Now that we have changed the chain API to not be backwards compatible in the 2.0 release, should we change the version number in the serialVersionUID fields as well? It seems to me that would make sense, but I'm a bit of a newbie when it comes to managing their versions. I was wondering if anyone else has experience with regards to best practices? The serialVersionUID of a class has to be changed if its binary layout changes: - the class or an inherited class has been renamed or moved to a different package - the field types of the (inherited) members have been changed or changed between transient/non-transient - the *order* of one of the (inherited) fields have been changed - serialization methods have (writeObject/readObject/writeReplace/readResolve) been added/removed in the class hierarchy in an incompatible way - the implementation of those methods have been changed in an incompatible way Basically, the serialVersionUID has to be changed if you cannot load a .ser file anymore with an instance of that class which was written with the old version. - Jörg - 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
Re: [chain2] serialVersionUID
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. 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 MMDD It's easier then to keep track of changes. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain2] serialVersionUID
Hi Elijah, if you need a introduction to serialization, I recommend to read the corresponding chapters in Effective Java by Josh Blooch [1]. Regards, Benedikt [1] http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683/ref=sr_1_1?ie=UTF8qid=1343119885sr=8-1keywords=effective+java 2012/7/24 Jörg Schaible joerg.schai...@scalaris.com: 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. 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 MMDD It's easier then to keep track of changes. - Jörg - 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
Re: [chain2] serialVersionUID
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 MMDD 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. - Jörg - 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
Re: [chain2] serialVersionUID
Hi everyone, Now that we have changed the chain API to not be backwards compatible in the 2.0 release, should we change the version number in the serialVersionUID fields as well? It seems to me that would make sense, but I'm a bit of a newbie when it comes to managing their versions. I was wondering if anyone else has experience with regards to best practices? Thanks, -Elijah - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain2] serialVersionUID
Hi Elijah Elijah Zupancic wrote: Hi everyone, Now that we have changed the chain API to not be backwards compatible in the 2.0 release, should we change the version number in the serialVersionUID fields as well? It seems to me that would make sense, but I'm a bit of a newbie when it comes to managing their versions. I was wondering if anyone else has experience with regards to best practices? The serialVersionUID of a class has to be changed if its binary layout changes: - the class or an inherited class has been renamed or moved to a different package - the field types of the (inherited) members have been changed or changed between transient/non-transient - the *order* of one of the (inherited) fields have been changed - serialization methods have (writeObject/readObject/writeReplace/readResolve) been added/removed in the class hierarchy in an incompatible way - the implementation of those methods have been changed in an incompatible way Basically, the serialVersionUID has to be changed if you cannot load a .ser file anymore with an instance of that class which was written with the old version. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
