commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject RE: [beanutils] PROPOSAL: eliminate core dependency on collections
Date Fri, 07 May 2004 13:02:31 GMT

--- Martin Cooper <martinc@apache.org> wrote:
> 
> 
> > -----Original Message-----
> > From: robert burrell donkin
> > [mailto:robertburrelldonkin@blueyonder.co.uk]
> > 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".

I agree with you that this is a complete hack and a generally bad idea but
what seems to have been lost in the discussion is that this is a
*temporary* solution.  The cloned classes will only exist for one release
so the API can be deprecated.  

IMO, there is absolutely no reason for Digester, BeanUtils, Validator, or
most other commons component to have a dependency on Collections. 
Removing this dependency will benefit many projects that just want to use
BeanUtils without dragging around a large and mostly unused Collections
jar.

David

> 
> 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.
> >
> > PLAN:
> >
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message