commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [BeanUtils] Collection 3.0 dependency, release status
Date Mon, 02 Feb 2004 18:27:11 GMT
Quoting robert burrell donkin <>:

> On 29 Jan 2004, at 20:11, David Graham wrote:
> > --- "Shapira, Yoav" <> 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"
> >
> >
> > 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


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

View raw message