RFR 8005704: Update ConcurrentHashMap to v8 (original) (raw)

Doug Lea dl at cs.oswego.edu
Wed May 29 13:11:30 UTC 2013


On 05/28/13 15:07, Mike Duigou wrote:

Hi Chris & Doug;

- I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type particularly for newKeySet(). Why not return Set? The additional methods don't seem to offer much that's desirable for the newKeySet() case.

Since we don't have a ConcurrentSet interface, people are reduced to instanceof checks to see if they have a concurrent one. But without exposing the class, they couldn't even do this, so complained. This will arise more frequently with j.u.streams.Collectors.

- I am reluctant to deprecate contains(Object) here unless we deprecate it in Hashtable as well. I recognize that this has been a source of errors (https://issues.apache.org/bugzilla/showbug.cgi?id=48755 for one example). Is it time to deprecate it there as well?

Sure, but why bother. Anyone still using Hashtable is not going to care if they get more deprecation warnings :-)

- I think there could be more complete description of the parallelismThreshold and interaction with common pool. i.e. does "maximal parallelism" mean one thread per element or "size() / getCommonPoolParallelism()". Some advice for choosing in-between values would be good unless "1" is the best advice for cases where you just don't know. It would be a shame to see people shooting themselves in the foot with this.

Changed to:

I'd rather not explicitly mention here any particular values for people to try, since any number we might put is likely to be misused. Sometime, we should write up a little how-to document about tuning parallelism separately.

-Doug



More information about the core-libs-dev mailing list