Mike Duigou mike.duigou at
Tue Dec 10 16:51:15 UTC 2013

On Dec 10 2013, at 01:06 , Paul Sandoz <paul.sandoz at> wrote:

> On Dec 10, 2013, at 5:14 AM, Martin Buchholz <martinrb at> wrote:
>> Hmmm... it was time that I studied Map.forEach....  I see you convert to
>> ISE to CME ...
>> (Synchronized maps (like Hashtable) do not implement ConcurrentMap.  Is
>> that a bug?)
>> Imagine a third party implementation of a synchronized map (again, like
>> Hashtable).  Its existing methods are synchronized, but in jdk8 it inherits
>> Map.forEach (not ConcurrentMap.forEach, because like Hashtable, it does not
>> implement ConcurrentMap) and so might throw CME even though its
>> implementation may never throw this and its entrySet may be designed for
>> concurrent traversal.
> Are you assuming the iterators of the collection views of the third party implementation would be weakly consistent? if so would expect that implementation to implement ConcurrentMap.

This observation suggests that we should describe this characteristic in the ConcurrentMap specification.

>> Another argument - before jdk8, whether a Map also implemented
>> ConcurrentMap was mostly symbolic, and could not affect behavior.  Users
>> could add "implements ConcurrentMap" purely for its documentation value.
>> Where possible, we should try to preserve that property.
>> Oh, and seriously, should Hashtable implement ConcurrentMap today?  It
>> appears to implement all of its methods in a thread-safe way.
> Not sure Hashtable should implement ConcurrentMap. 
> While the Hashtable methods are synchronized the collection views will fail fast on modification (one of the few cases where CME is explicitly used with concurrent access in mind :-) ). Although it is not explicitly called out I think the likely expectation is (well, my expectation is) that a ConcurrentMap provides weakly consistent iterators.

I agree that the iterator behaviour for Hashtable (and of Collections.synchronizedMap) falls short of what one would expect of a ConcurrentHashMap.


More information about the core-libs-dev mailing list