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