This class obeys the same functional specification asMy question for whomever chose the name of this class: Why the bloody hell did you call it ConcurrentHashMap and not ConcurrentHashtable?!?!Hashtable
, and includes versions of methods corresponding to each method ofHashtable
. [...] LikeHashtable
but unlikeHashMap
, this class does NOT allownull
to be used as a key or value.
Tuesday, May 29, 2007
java.util.concurrent.ConcurrentHashtable
The J2SE 1.5.0 java.util.concurrent.ConcurrentHashMap API states:
Subscribe to:
Post Comments (Atom)
3 comments:
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
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.
> 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...
Post a Comment