dl at cs.oswego.edu
Sat Oct 8 06:30:17 EDT 2011
On 10/07/11 16:52, Bob Lee wrote:
> On Wed, Oct 5, 2011 at 6:11 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
> To me, fixing the mis-feature is more important
> than retaining pure compatibility for a usage
> that probably didn't do what people expected anyway.
> But if you've ever done anything relying on the old j.u.c
> behavior, could you let us know? Thanks!
> Is it correct to assume that "fixing" CHM.entrySet().toArray() requires more
> work on our part?
I'm not sure what you mean. The fix in V8 is to use non-write-through
Entry objects in entrySet.toArray to avoid unwanted side effects in
The problematic use case is very rare, if it even exists.
In a google code search for the combination on ConcurrentHashMap,
entrySet, toArray, and setValue, I didn't see any. (Although
there are other possible ways to this encounter it.)
But because it is rare, it is a good idea to avoid surprises
when people do encounter it.
If you'd like to avoid the write-through side-effects without this
fix in existing CHM, you'd need to copy the elements of
entrySet().toArray() one by one into AbstractMap.SimpleEntry
(or some similar class) objects.
More information about the Concurrency-interest