"DeltaTang", please take a moment to read our
display name policy and then
edit your display name to have a first and last name, separated by a space. Thanks.
As for the question - note that FastHashMap is not a class "Delta" is writing; rather it comes from
Jakarta Commons BeanUtils. As far as I know most (all?) of the Jakarta Commons stuff is written for pre-5.0 code. I agree ConcurrentHashMap is a better choice, but BeanUtils assumes you may not have access to it. (Though in this case one could probably use
Doug Lea's earlier ConcurrentHashMap.)
[Warren]: My comment on observing it is: it clones the entire map every time an element is added? That doesn't seem very "fast" to me. It isn't, in general, but it does make read operations a little faster because they're now unsynchronized. So if reads are much, much more common than writes, this may be faster than a synchronized HashMap or Hashtable. I expect that it's fairly rare to find a situation where "FastHashMap" is actually faster, and even rarer that it's
significantly faster. But it's possible, at least in theory.
[Delta]: my question is : why it uses shallow copy here? Well, a shallow copy is generally (always?) faster than a deep copy, and I don't see any reason why we'd need a deep copy here. In fact using a deep copy would break the contract of the Map - when you get() an object from it, ythe object would not == the original object you put into the map. The API says get() returns
the value put into the Map; it doesn't return a
copy of the value.
[Delta]: Can someone show me the mechanism of the FastHashMap? thanx. You're already looking at the source code, so I guess I don't understand the question.
[ May 21, 2005: Message edited by: Jim Yingst ]