commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject RE: [beanutils] PROPOSAL: eliminate core dependency on collections
Date Fri, 07 May 2004 05:12:16 GMT

> -----Original Message-----
> From: robert burrell donkin
> []
> Sent: Thursday, May 06, 2004 12:15 PM
> To: Jakarta Commons Developers List
> Subject: [beanutils] PROPOSAL: eliminate core dependency on collections
> PROPOSAL: eliminate the core dependency on commons-collections

No doubt I'm sounding like a broken record and/or a lone voice in the
wilderness, but I really don't like the whole idea of cloning classes from
one Commons component into some other package to "eliminate a dependency".

Commons came into being so that people could *share* implementations, and
*avoid* cloning them. When classes are cloned, you no longer get the
benefits of bug fixes coming from a common component, advances in the design
of common components, more eyes looking at the classes in the context of a
component whose purpose is well-defined, etc.

When a developer needs to add functionality to an ex-client of a component
like Collections, they might clone another class. Before long, people will
lose track of how many cloned classes there are, and there will be so many
hidden potential dependencies that it would make a whole lot more sense to
depend on the original package, but it just won't occur to people to do that
any more.

I'm not going to -1 this, because it seems clear that there is support for
it, but frankly I just don't understand the mentality that says it's a good
thing to *not* share components that were designed from the get-go to be
shared. Bizarre.

Martin Cooper

> rationale - this will not only eliminate a sizable dependency for many
> products depending on beanutils but also reduce chances of
> compatibility issues with the various versions of collections.
> 1 add org.apache.commons.collections.ArrayStack and
> org.apache.commons.collections.Buffer source to beanutils (these are
> required by the public API)
> 2 replace the references to FastHashMap with a private static
> implementation. consider whether to replace this altogether.
> 3 factor out a new bean-collections jar under extras/bean-collections
> containing the (cool) implementations of collections stuffs using
> beanutils bean-magic.
> i've made a start on this work (so if anyone has any reasonable
> objections, now would be a very good time to state them :) but i'd be
> willing to change if anyone comes up with any improvements to this
> plan.
> - robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message