commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject Re: [beanutils] commons collection classes
Date Mon, 21 May 2007 10:23:12 GMT
This is a major "broken window", IMHO, and it should be fixed.  Why not
leave the API the way it is and just take out the classes that are
duplicated?  They are in the same packages as are in the commons-collections
jar file.  I understand that it causes a dependency on commons collections
(which is big), but at least the user knows what exactly they're getting
rather than playing classloader bingo.  Also, the dependency is a
conditional one.  You only need collections if you're using these specific
classes.  There are probably not too many users of these classes anyway.  I
would venture to say that there are probably not too many projects using
beanutils that aren't using collections anyway (once you start playing with
commons libraries, you can't stop; they're addictive).

On 5/19/07, Stephen Colebourne <> wrote:
> Torsten Curdt wrote:
> > On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote:
> >> I suggest marking the offending methods as deprecated for the 1.x
> >> series, and schedule them for removal in the 2.x series.
> >
> > Well, then let's create a 2.x branch and do a release without the
> > classes *now*. No problem with that. Then it is communicated and people
> > can choose. But doing *nothing* just because of binary compatibility is
> > silly.
> Doing nothing because of binary incompatibility is not silly, its
> essential. Commons has to be far more extreme than almost any other OSS
> project on this point.
> In fact, I contend that commons is now in such a position that we can't
> make incompatible changes even in major version number releases.
> > Especially as no one *has* to upgrade libraries. And checking
> > release notes if you do can't hurt if you upgrade.
> Users are forced to upgrade all the time, and thats why they require
> backwards compatibility.
> For example, if project A is complied against the old [beanutils] jar,
> while project B is compiled against the new [beanutils] jar, then it is
> impossible to use both project A and project B together. You cannot
> physically upgrade the jar file to the one B needs, because A needs the
> old one.
> The only solutions to this at present are
> -  for the 2.x series to have a different package name, including 'v2'
> - to force the user to play with class loaders, so they can load two
> different versions of the same class
> In summary, I suggest we all just let this one be. This isn't causing
> major pain IMO. The lesson should be to not have dependencies between
> commons projects wherever possible.
> Stephen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message