commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject [digester] remove denpendency? (Was: Re: [BeanUtils] Collection 3.0 dependency, release status)
Date Mon, 02 Feb 2004 18:37:28 GMT
Quoting "Craig R. McClanahan" <craigmcc@apache.org>:

> Quoting robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>:
> 
> > On 29 Jan 2004, at 20:11, David Graham wrote:
> > 
> > > --- "Shapira, Yoav" <Yoav.Shapira@mpi.com> wrote:
> > >>
> > >> Hi,
> > >> I see the BeanUtils 1.7-dev already depends on commons collections
> > >> 3.0-dev and builds OK.  Can we update the dependency to collections 
> > >> 3.0
> > >> (final)?
> > >>
> > >> What's left to be done for the BeanUtils 1.7 release?
> > >
> > > Personally, I'd like to see this enhancement added before the release:
> > >
> > > "Add BeanFactory for dynamic factories"
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=18087
> > >
> > > There has been some positive feedback on this list about adding it.  I
> > > could do this myself if the BeanUtils committers still think it's a 
> > > good
> > > idea.
> > 
> > i'm still ambivalent.
> > 
> > if craig has no strong feelings against then i suppose that there's an 
> > argument that since there are people who think the code's useful it 
> > might as well go in. i would be happier to hear craig's opinions on 
> > this one before it gets committed.
> > 
> 
> I"m actually inclined to remove the BeanUtils dependency on Collections
> entirely.  The large number of backwards-incompatible API changes causes
> some
> significant problems for applications that depend on BeanUtils and also on
> Collections.  If we change our dependency, that forces all apps using
> BeanUtils
> to update their dependency as well.
> 
> Technically, there are two sorts of changes this would entail:
> 
> * Replace use of FastHashMap with either an inside-beanutils
>   version of it, or some other approach.  FastHashMap came out
>   of BeanUtils in the first place, and we could easily adopt it
>   back as a package private support class, but there have also
>   been some concerns about the thread safety of the locking
>   avoidance techniques used inside, so maybe going to synchronized
>   HashMaps (and paying the performance price) would be safer.
> 
> * The new BeanPropertyValue stuff uses several Collections interfaces,
>   and we'd need to evaluate what it means to change that.  This is all
>   new code since BeanUtils 1.6, so if we're going to change it, now
>   is the time.
> 
> > - robert
> 
> Craig
> 

For the record, I feel the same way about removing the collecions dependency in
Digester as well.  For that case it's pretty easy ... the only class used is
ArrayStack, and could be easily replaced by an internal utility class.

Craig


---------------------------------------------------------------------
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