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:
> For example,
> you would be surprised and unhappy if you did
> Object a = myArrayList.toArray();
> a = 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();
> 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