[concurrency-interest] ConcurrentHashMapV8

David M. Lloyd david.lloyd at redhat.com
Wed Oct 5 18:31:55 EDT 2011

On 10/5/11 6:11 AM, Doug Lea wrote:
> I'm still contemplating changes in handling null-returns
> in the new compute methods. But in the mean time, here
> is another tiny corner-case issue that is handled differently
> in ConcurrentHashMapV8 than in the existing j.u.c version.
> I consider it just a misfeature-fix, but Joe Bowbeer remains
> nervous about it, so urged me to post and solicit reaction.
> This takes a fair amount of context to set up:
> [...snip...]
> For example,
> you would be surprised and unhappy if you did
> Object[] a = myArrayList.toArray();
> a[0] = 17;
> and then found out that this caused myArrayList.get(0)
> to also now return 17.
> In the case of ConcurrentHashMap, this means that the
> kind of Entry you get for the elements of entrySet.toArray
> should NOT write back to the map you got them from.
> In other words:
> Object[] a = myMap.entrySet().toArray();
> (Entry[])a[0].setValue(17);
> should not change myMap.get(keyFor0) to return 17.

I disagree with this conclusion; these scenarios aren't really the same. 
  The general contract of toArray() is to return an array consisting of 
all the values in the collection - I think interpreting it such that it 
can return copies of the values is a stretch.  I can't think of any case 
where we'd actually copy the values in normal collections; I don't see 
why an entry set should be any different, magical write-through 

For example if I did:

Object[] a = myMap.entrySet().toArray();

I would expect the same result as if I did:

Object[] a = new ArrayList<Entry<Blah,Blah>>(myMap.entrySet()).toArray();

I don't think toArray should be special here.  I think this is the "most 
correct" interpretation of this requirement, and in any case is the one 
I've adhered to whenever developing collection implementations.  I think 
that there should be no difference between the values in a toArray() 
result and the values you'd get back from a set iterator.

More information about the Concurrency-interest mailing list