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] Collection 3.0 dependency, release status
Date Mon, 02 Feb 2004 21:33:18 GMT
+0

i'd definitely support this change (but i'm short of energy at the 
moment).

some more comments inline

On 2 Feb 2004, at 18:27, Craig R. McClanahan wrote:

<snip>

> I"m actually inclined to remove the BeanUtils dependency on Collections
> entirely.  The large number of backwards-incompatible API changes 
> causes some
> significant problems for applications that depend on BeanUtils and 
> also on
> Collections.  If we change our dependency, that forces all apps using 
> BeanUtils
> to update their dependency as well.
>
> Technically, there are two sorts of changes this would entail:
>
> * Replace use of FastHashMap with either an inside-beanutils
>   version of it, or some other approach.  FastHashMap came out
>   of BeanUtils in the first place, and we could easily adopt it
>   back as a package private support class, but there have also
>   been some concerns about the thread safety of the locking
>   avoidance techniques used inside, so maybe going to synchronized
>   HashMaps (and paying the performance price) would be safer.

sounds reasonable.

with the new bean instances, i'd prefer to factor out the storage into 
separate registry  plugins. i'd be willing to let the user synchronize 
explicitly (if needed) since the most common use case would be create 
and configure a registry then set it. i think that this use case 
shouldn't need to be synchronized. (though it may possible be necessary 
to synchronize some of the calls from the static methods.)

> * The new BeanPropertyValue stuff uses several Collections interfaces,
>   and we'd need to evaluate what it means to change that.  This is all
>   new code since BeanUtils 1.6, so if we're going to change it, now
>   is the time.

this means BeanPropertyValueChangeClosure, 
BeanPropertyValueEqualsPredicate and BeanPropertyValueTransformer, 
right?

if so, since these are really implementation i'd be very happy to see 
these moved into an optional package with a separate dependency on 
collections. they are useful but not core to beanutils. in some ways 
they have one foot in beanutils and the other in collections.

- 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