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


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?

<snip>


have i explained this better now?

That makes much more sense ... thanks. I'm +1 on this idea.

great


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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to