1

Most of the synchronized and concurrent collections like HashTable, ConcurrentHashMap etc do not allow null values. Is there any specific issue with null elements?

GD_Java
  • 1,359
  • 6
  • 24
  • 42
  • Your answer here ;) http://stackoverflow.com/questions/7556357/why-does-hashtable-not-take-null-key – Mik378 Mar 31 '13 at 16:33
  • @Mik378 I have already through the above discussion. This discussion is all about key. But here I am also looking for why null values are not allowed in synchronized and concurrent collection. – GD_Java Mar 31 '13 at 16:44
  • ok :) You should precise it in your post's title – Mik378 Mar 31 '13 at 16:58

5 Answers5

1

HashTable.get(key) method returns null if the specified key is not present in the HashTable. If HashTable allows null as values, there can be two possibilities if I am getting a null from HashTable.get(key) method.

  1. The key is not present in HashTable
  2. The key is present, but the value set was null

It may be confusing for the user of the API. I believe they don't allow null values just to prevent this ambiguity.

Devadas
  • 83
  • 9
1

Hashtable is somewhat obsolete so I won't comment on it. As for ConcurrentHashMap one of the important additions of the API vs. a standard HashMap are a few atomic methods such as putIfAbsent. Javadoc:

Returns the previous value associated with the specified key, or null if there was no mapping for the key

In particular, if the map allowed null keys, the method would be a lot more complicated to use. A typical pattern, where you need to make sure that values can't be overwritten, is:

ConcurrentMap<K,V> map = new ConcurrentHashMap<> ();
V value = map.get(key);
if (value == null) {
    value = new V();
    V previousValue = map.putIfAbsent(key, value);
    if (previousValue != null) { //Here you need to be sure what that means
        value = previousValue;
    }
}
useValue(value);

Another example is how you check if a key is in a HashMap (and you need the return value):

V value = map.get(key);
if (value == null && !map.containsKey(key)) {
}

The problem in a concurrent environment is that the whole thing is not atomic.

See also this post and these comments by the author of CHM.

Community
  • 1
  • 1
assylias
  • 321,522
  • 82
  • 660
  • 783
0

This is a synchronized map that accepts null key and values

    Map m = Collections.synchronizedMap(new HashMap());
Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275
  • thanks for your response but here you are making it synchronized manually. But what I am looking for why it is not the default nature of synchronized and concurrent collections. – GD_Java Mar 31 '13 at 16:39
0

From the 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.

In a nutshell, 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.

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

Specifically, the use of null as a key is handled like this when issuing a .get(key):

(key==null ? k==null : key.equals(k))

Source:Why does Hashtable not take null key?

Community
  • 1
  • 1
Jabir
  • 2,776
  • 1
  • 22
  • 31
  • and why hashtable do not allow null value? – GD_Java Mar 31 '13 at 17:11
  • "To successfully store and retrieve objects from a hashtable, the objects used as keys must implement the hashCode method and the equals method." – Jabir Mar 31 '13 at 17:15
0

When you synchronize it means you will obtain lock on that object or at some portion. If your object is null then how will you decide that in which portion you will obtain lock?

Say in concurrenthashmaps, you can divide it into 16 different locks. Now how will you decide where null will be placed?

Null has no value attached to it, it simply means no object. So to avoid ambiguity its better not to have it.

Lokesh
  • 7,810
  • 6
  • 48
  • 78