You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2004/02/01 14:47:20 UTC
Re: [BeanUtils] Collection 3.0 dependency, release status
On 29 Jan 2004, at 20:11, David Graham wrote:
> --- "Shapira, Yoav" <Yo...@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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils] Collection 3.0 dependency, release status
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
+0
i'd definitely support this change (but i'm short of energy at the
moment).
some more comments inline
On 2 Feb 2004, at 18:27, Craig R. McClanahan wrote:
<snip>
> 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.
sounds reasonable.
with the new bean instances, i'd prefer to factor out the storage into
separate registry plugins. i'd be willing to let the user synchronize
explicitly (if needed) since the most common use case would be create
and configure a registry then set it. i think that this use case
shouldn't need to be synchronized. (though it may possible be necessary
to synchronize some of the calls from the static methods.)
> * 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.
this means BeanPropertyValueChangeClosure,
BeanPropertyValueEqualsPredicate and BeanPropertyValueTransformer,
right?
if so, since these are really implementation i'd be very happy to see
these moved into an optional package with a separate dependency on
collections. they are useful but not core to beanutils. in some ways
they have one foot in beanutils and the other in collections.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester] remove denpendency? (Was: Re: [BeanUtils] Collection 3.0 dependency, release status)
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 2 Feb 2004, at 18:37, Craig R. McClanahan wrote:
<snip>
> 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.
sounds good to me
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[digester] remove denpendency? (Was: Re: [BeanUtils] Collection 3.0 dependency, release status)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting "Craig R. McClanahan" <cr...@apache.org>:
> Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
>
> > On 29 Jan 2004, at 20:11, David Graham wrote:
> >
> > > --- "Shapira, Yoav" <Yo...@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
Re: [BeanUtils] Collection 3.0 dependency, release status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting robert burrell donkin <ro...@blueyonder.co.uk>:
> On 29 Jan 2004, at 20:11, David Graham wrote:
>
> > --- "Shapira, Yoav" <Yo...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org