On 28 December 2017 at 22:50, Stephen Colebourne <scolebou...@joda.org> wrote: > On 28 December 2017 at 19:49, Gary Gregory <garydgreg...@gmail.com> 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
