commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [beanutils] PROPOSAL: eliminate core dependency on collections
Date Thu, 06 May 2004 21:38:04 GMT
robert burrell donkin wrote:

> On 6 May 2004, at 21:28, Craig McClanahan wrote:
>> robert burrell donkin wrote:
> <snip>
>>> 2 replace the references to FastHashMap with a private static 
>>> implementation. consider whether to replace this altogether.
>> +1.  Regarding replacement, I'm fine with any approach that lets us 
>> read from the collection without locking (which is the 99.9% use case 
>> for where the Fast* stuff is used in both BeanUtils and in Struts).  
>> In practice, nobody has reported a reproducible bug against the code 
>> in these classes, but I can certainly appreciate how difficult it 
>> would be to accomplish this.
> hmmm...
> if FastHashMap is used in struts as well as beanutils then maybe we 
> should retain this class in the source (as well as the other two)...

It's used in Struts for purposes similar to where it's used in beanutils 
... for mostly-read-only access to configuration collections.

That's not really something that should drive a [beanutils] decision, 
though ... and this is all a temporary measure until we can deprecate 
the bad public API and fix it.  I'm still fine with copying them.

>>> 3 factor out a new bean-collections jar under 
>>> extras/bean-collections containing the (cool) implementations of 
>>> collections stuffs using beanutils bean-magic.
>> I'm not sure I'm parsing this sentence correctly.  Does that mean we 
>> just put the ArrayStack and Buffer and Fast* classes being grabbed 
>> here, instead of in src/java?  If so, +1.  Otherwise, could you 
>> please explain further?
> there are five classes that have direct dependencies on the core of 
> collections:
>  BeanComparator
>  BeanPredicate
>  BeanPropertyValueChangeClosure
>  BeanPropertyValueEqualsPredicate
>  BeanToPropertyValueTransformer
> i'm pretty sure that these have been added since the last release (but 
> i will check that). these all operate on collections of beans using 
> the core collections abstracts and so have real dependencies on 
> collections (3.0).
> i like these classes but i don't think that they are sufficiently part 
> of the core beanutils to justify retaining the collections dependency. 
> so, i think that the best solution would be to for these to be 
> factored out into a separate sub-component (beanutil-bean-collections 
> or something) within the beanutils directory structure with it's own 
> build and it's additional dependency.
> i'd like to think that we'd distribute this as an optional jar within 
> the main beanutils distribution.
> have i explained this better now?
That makes much more sense ... thanks.  I'm +1 on this idea.

> or would it be easier for me to create a branch and commit stuff onto 
> that so that people can take a look...
HEAD branch is fine with me.

> - robert

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

View raw message