commons-dev mailing list archives

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

On 6 May 2004, at 22:38, Craig McClanahan wrote:
> 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.

what's driving me is wanting to clean up the dependency issues for 
downstream beanutils customers (such as struts). IMHO that struts needs 
FastHashMap is a reasonable litmus test. it makes me inclined to think 
that a copied version (packaged under org.apache.commons.collections) 
should be included as part of the public API. (rather than a private 

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


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

HEAD it is then

- robert

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

View raw message