Tuesday, May 29, 2007

java.util.concurrent.ConcurrentHashtable

The J2SE 1.5.0 java.util.concurrent.ConcurrentHashMap API states:
This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable. [...] Like Hashtable but unlike HashMap, this class does NOT allow null to be used as a key or value.
My question for whomever chose the name of this class: Why the bloody hell did you call it ConcurrentHashMap and not ConcurrentHashtable?!?!

3 comments:

Christian Ullenboom said...

Because a Hashtable is already synchronized not as HashMap. And Concurrent-Concurrent-Map makes no sense :-) But a ConcurrentHashMap is much fast in concurrent environments than Hashtable and a wrapper via Collections.synchronizedMap().

Chris

Pussinboots said...

Sorry, but that's a nonstarter. Yes, Hashtable is one of those lingering, poorly designed, synchronized classes. But, ConcurrentHashMap acts like Hashtable with exceptions that it includes additional concurrency aids and is much more efficient at dealing with concurrent modification & access. These properties are typical of java.util.concurrent.*. So a better name would be java.util.concurrent.ConcurrentHashtable as this would correctly suggest both the interface (Hashtable) and its ability to deal with concurrency.

V Peti said...

> So a better name would be java.util.concurrent.ConcurrentHashtable as this would correctly suggest both the interface (Hashtable)
The interface of ConcurrentHashMap is Map (and ConcurrentMap). (Hashtable is not even an interface).

The rationale as I see it, by the way, is that Hashtables are old, and the new collections framework should be used instead. Now, there was HashMap, but if you just wanted a drop-in replacement for hashtable, you had to surround it with synchronized blocks, and here comes the ConcurrentHashMap...