Re: [beanutils] Toward 2.0.0
Hi, > Am 28.12.2017 um 20:49 schrieb Gary Gregory : > > Hi All, > > - BeanUtils now has a new package o.a.c.beanutils2. > - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), > which caused the above. > > What more do we want before releasing 2.0.0? > > Updating from BU 1.x to 2.x should be "simple" for now: Just update your > imports. > > Thoughts? See my comment on the other thread. What about the BeanUtils rewrite we have in the Sandbox? > > Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Toward 2.0.0
On 28 December 2017 at 22:50, Stephen Colebourne wrote: > On 28 December 2017 at 19:49, Gary Gregory wrote: >> Hi All, >> >> - BeanUtils now has a new package o.a.c.beanutils2. >> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), >> which caused the above. >> >> What more do we want before releasing 2.0.0? >> >> Updating from BU 1.x to 2.x should be "simple" for now: Just update your >> imports. > > This can make things far worse for end users. If jar file A updates to > v2.0 but jar file B does not, an application C that depends on A and B > cannot pass the output of [beanutils] around. Instead, it gets the > same class names repeated twice, and horrid conversion code. While I > understand the jar hell problem fully, I'm not sure that package > renaming the whole jar is really any better - its just a different > kind of hell. At least it's possible to write bridging code should it be necessary. And any problems are immediately obvious. Whereas if two incompatible jars are on the classpath, there's no way to ensure which version of a class will be loaded. And problems may not always appear until the worst possible moment. Other things being equal (see below), I would rather have a situation with a messy solution than a situation with none. > If only one class exposes one problem return type in a method that not > everyone uses, it seems _on balance_ better to change the method > without changing the package names. The bump to v2.0 would still be a > sufficient indication of the potential compatibility issue (rarely hit > in reality). However, if the method in question is a vital part of the > main API, it might be worth changing the package name. > > In other words, I think the presumption that all breaking changes > require a package name change is damaging - the package name change > should be an action of last resort. I agree that some changes that break strict compatibility may sometimes be permissible. If the change only affects an esoteric or non-recommended use of the API then it's probably better to keep the existing package. However that assumes there is a work-round for any users who are affected. > Stephen > > - > 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: [beanutils] Toward 2.0.0
On 28 December 2017 at 19:49, Gary Gregory wrote: > Hi All, > > - BeanUtils now has a new package o.a.c.beanutils2. > - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), > which caused the above. > > What more do we want before releasing 2.0.0? > > Updating from BU 1.x to 2.x should be "simple" for now: Just update your > imports. This can make things far worse for end users. If jar file A updates to v2.0 but jar file B does not, an application C that depends on A and B cannot pass the output of [beanutils] around. Instead, it gets the same class names repeated twice, and horrid conversion code. While I understand the jar hell problem fully, I'm not sure that package renaming the whole jar is really any better - its just a different kind of hell. If only one class exposes one problem return type in a method that not everyone uses, it seems _on balance_ better to change the method without changing the package names. The bump to v2.0 would still be a sufficient indication of the potential compatibility issue (rarely hit in reality). However, if the method in question is a vital part of the main API, it might be worth changing the package name. In other words, I think the presumption that all breaking changes require a package name change is damaging - the package name change should be an action of last resort. Stephen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Toward 2.0.0
On 28 December 2017 at 22:02, Dave Brosius wrote: > beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data > structure in it's own interface. That went away in commons collections 4, > and so i modified the beanutils 4 interface to use ConcurrentHashMaps. Thus > the need for a package rename. I see. So it's not just a case of changing imports. If any user code has used that part of the interface, it will have to be changed. > > > On 12/28/2017 04:56 PM, sebb wrote: >> >> On 28 December 2017 at 19:49, Gary Gregory wrote: >>> >>> Hi All, >>> >>> - BeanUtils now has a new package o.a.c.beanutils2. >>> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), >>> which caused the above. >>> >>> What more do we want before releasing 2.0.0? >>> >>> Updating from BU 1.x to 2.x should be "simple" for now: Just update your >>> imports. >> >> Surely there must be some other breaking changes otherwise there would >> be no need to change the package name? >> >>> Thoughts? >>> >>> Gary >> >> - >> 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: [beanutils] Toward 2.0.0
beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data structure in it's own interface. That went away in commons collections 4, and so i modified the beanutils 4 interface to use ConcurrentHashMaps. Thus the need for a package rename. On 12/28/2017 04:56 PM, sebb wrote: On 28 December 2017 at 19:49, Gary Gregory wrote: Hi All, - BeanUtils now has a new package o.a.c.beanutils2. - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), which caused the above. What more do we want before releasing 2.0.0? Updating from BU 1.x to 2.x should be "simple" for now: Just update your imports. Surely there must be some other breaking changes otherwise there would be no need to change the package name? Thoughts? Gary - 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: [beanutils] Toward 2.0.0
On 28 December 2017 at 19:49, Gary Gregory wrote: > Hi All, > > - BeanUtils now has a new package o.a.c.beanutils2. > - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), > which caused the above. > > What more do we want before releasing 2.0.0? > > Updating from BU 1.x to 2.x should be "simple" for now: Just update your > imports. Surely there must be some other breaking changes otherwise there would be no need to change the package name? > Thoughts? > > Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[beanutils] Toward 2.0.0
Hi All, - BeanUtils now has a new package o.a.c.beanutils2. - BeanUtils now depends on Apache Commons Collection 4 (instead of 3), which caused the above. What more do we want before releasing 2.0.0? Updating from BU 1.x to 2.x should be "simple" for now: Just update your imports. Thoughts? Gary
