Why Does Concurrenthashmap Prevent Null Keys and Values

Why does ConcurrentHashMap prevent null keys and values?

From the author of ConcurrentHashMap himself (Doug Lea):

The main reason that nulls aren't allowed in ConcurrentMaps
(ConcurrentHashMaps, ConcurrentSkipListMaps) is that ambiguities that
may be just barely tolerable in non-concurrent maps can't be
accommodated. The main one is that if map.get(key) returns null, you
can't detect whether the key explicitly maps to null vs the key isn't
mapped. In a non-concurrent map, you can check this via
map.contains(key), but in a concurrent one, the map might have changed
between calls.

Why does Hashmap allow a null key?

One interpretation of your question:

why hashmap allowed [only] one null key?

Ask yourself: if HashMap allowed more than one null key, how would the map object distinguish between them?

Hint: there is only one null value.

---

Alternative interpretation of your question

why hashmap allowed [a] null key?

Because it is useful in some circumstances, and because there is no real semantic need to disallow it^{1, 2}.

By contrast, with TreeMap null keys are disallowed because supporting them would be difficult given the implications of orderings involving null.

• Given that the specified semantics for Comparable is to throw NPE.
• Comparator is allowed to order null, but it is not required to. And many common implementations don't.

So if null was allowed with TreeMap, then the behavior of a map could be different depending on whether a Comparator or a Comparable is used. Messy.

---

^{1 - At least, that was the view when they specified HashMap in Java 1.2 back in 1998. Some of the designers may have changed their minds since then, but since the behavior is clearly specified it cannot be changed without messing up compatibility. It won't happen ...}

^{2 - Support for null keys requires some special case code in HashMap which at least adds complexity to the implementation. It is not clear if it is a performance overhead for HashMap, since there would still need to be an implicit test for a null keys even if null keys were not allowed. This is most likely down in the noise.}

Java - Reasons for Allowing null as a HashMap Key?

From the JDK 1.2 Java Collections API Change Summary (not sure where to find the official version on Oracle's website):

Added null-key support to HashMap. This was done for consistency with
TreeMap and the late, unlamented ArrayMap, and because customers
requested it. Now all of our general-purpose collection
implementations accept null keys, values and elements.

Joshua Bloch and Doug Lea disagreed on this, and this caused problems for concurrent hash maps.

Why Hashtable does not allow null keys or values?

Hashtable is the older class, and its use is generally discouraged. Perhaps they saw the need for a null key, and more importantly - null values, and added it in the HashMap implementation.

HashMap is newer, and has more advanced capabilities, which are basically just an improvement on the Hashtable functionality. When HashMap was created, it was specifically designed to handle null values as keys and handles them as a special case.

Edit

From Hashtable JavaDoc:

To successfully store and retrieve objects from a Hashtable, the
objects used as keys must implement the hashCode method and the equals method.

Since null isn't an object, you can't call .equals() or .hashCode() on it, so the Hashtable can't compute a hash to use it as a key.

---

Related Topics