IdentityHashMap and expectedmaxsize

Question

I have been going through documentation of IdentityHashMap. That class has a constructor which takes expectedmaxsize.

public IdentityHashMap(int expectedMaxSize);

Internally, Java uses expectedmaxsize to calculate capacity as shown below:

// Compute min capacity for expectedMaxSize given a load factor of 2/3
int minCapacity = (3 * expectedMaxSize)/2;

On exploring further I found that user is expected to pass a good value of expectedmaxsize so that IdentityHashMap is not resized as more elements are added.

Compare this with HashMap, with its constructor accepting initialCapacity:

 public HashMap(int initialCapacity)

…and another constructor which accepts loadfactor and initialcapacity:

   public HashMap(int initialCapacity, float loadFactor) 

…and here is HashMap there is no such guideline regarding initialcapacity.

So clearly there is a difference in the way size of internal array is managed in HashMap and IdentityHashMap. I don't understand why do we have this difference? Why can't IdentityHashMap provide a constructor same as HashMap?

Answer 1

As JB Nizet says, the difference in the respective constructor APIs is due to "second thoughts" by the designers on what was easiest for programmers to understand. (The old way exposes aspects of the internal design unnecessarily.)

So clearly there is a difference in the way size of internal array is managed in HashMap and IdentityHashMap.

That is an incorrect inference, and in fact it is not true. If you look carefully at the respective code for HashMap and IdentityHashMap the initial sizing and resizing code is different, but the logic is basically the same. An initial array size is determined based on the parameters, and then the array is doubled in size when a threshold is reached. (That is my reading of the code ... but you can check it yourself using the links above.)

The reason that stuff is left out of the javadoc for IdentityHashMap is that it is no longer needed. In the HashMap case, the material had to be there so that the programmer knew what the constructor parameters meant. Simplifying the constructor parameters meant that they didn't need to explain this. So (I presume) they decided to treat the actual resizing mechanism as an "implementation detail" and not make it part of "the contract".

Answer 2

IdentityHashMap dates from JDK 1.4, whereas HashMap dates from JDK 1.2. In the meantime, the authors of the Java Collections Framework probably realized that passing an expected max size is much more natural, frequent and developer-friendly than passing a capacity.

But passing a capacity or a max size is basically the same thing :

max size = capacity * load factor.