Re: [beanutils] PROPOSAL: eliminate core dependency on collections

[Craig McClanahan]

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

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]