commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [beanutils] PROPOSAL: eliminate core dependency on collections
Date Thu, 06 May 2004 21:20:41 GMT
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)...

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

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

- robert


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