What makes two keys equal in a HashMap?

[aaronfude]

Hi,

I have always assumed that HashMap.get(obj) looks for the key that
key.compareTo(obj) == 0. But apparently, that is not the case:

public static class GoodAsKeys implements Comparable {
private int myInt;

public GoodAsKeys(int inInt) { myInt = inInt; }

public int compareTo(Object inObject) {
return myInt - ((GoodAsKeys) inObject).myInt;
}
}

public static void main(String[] args) {
GoodAsKeys a = new GoodAsKeys(5);
GoodAsKeys b = new GoodAsKeys(5);

HashMap map = new HashMap();
map.put(a, "World");
System.out.println(map.get(b));
}

This program prints out "null". What have I missed here?

Many thanks in advance!

Aaron

 

[Ingo R. Homann]

Hi aaron,

Hi,
...
This program prints out "null". What have I missed here?

Reading the doku and recognizing that you must overwrite equals() and
hashCode()!

Ciao,
Ingo

 

[Thomas Hawtin]

I have always assumed that HashMap.get(obj) looks for the key that
key.compareTo(obj) == 0. But apparently, that is not the case:

Wouldn't be much of a *hash* map then, would it?

TreeMap uses Comparable/Comparator.

Tom Hawtin

 

[Mike Schilling]

Hi,

I have always assumed that HashMap.get(obj) looks for the key that
key.compareTo(obj) == 0. But apparently, that is not the case:

No, it looks for the key such that key.equals(obj) is true.

 

[George Cherry]

Hi,

I have always assumed that HashMap.get(obj) looks for the key that
key.compareTo(obj) == 0.

You don't understand the basic idea of a hashed collection.
I suggest you grab an introductory computer science book
and read about hash functions, hash buckets, and hash tables.
Then you'll understand why compareTo() is not germane, but
hashCode() and equal() are. You need compareTo() for a
TreeMap, but not for a HashMap. You need to override
hashCode() and equal() for a HashMap but not for a TreeMap.

George W. Cherry

 

[Jean-Baptiste Nizet]

You need to override

hashCode() and equal() for a HashMap but not for a TreeMap

In fact, if you want to obey the general contract for the Map
interface, you have to implement equals in a way that is consistent
with compareTo. And if you want to obey the general equals/hashCode
contract, you have to implement hashCode so that two equal objects have
the same hashCode.
A TreeMap will not use the equals and hashCode methods, and will work
if they are not defined or defined inconsistently, but it's a good idea
to have them implemented right.

JB.

 

[Dale King]

No, it looks for the key such that key.equals(obj) is true.

To be entirely precise it's actually:

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

It also requires that if the key is non-null that:

key.hashCode() == obj.hashCode()

but that is required by the contract of equals anyway.

 

[Mike Schilling]

To be entirely precise it's actually:

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

Right you are. This sort of thing is needed so often, there should really
be a method on Object

public static boolean Object equals(Object a, Object b)
{
return a == null ? b == null : a.equals(b);
}

..NET has one.

 

[Dale King]

Right you are. This sort of thing is needed so often, there should really
be a method on Object

public static boolean Object equals(Object a, Object b)
{
return a == null ? b == null : a.equals(b);
}

..NET has one.

The way HashMap does it is that if you pass null it actually replaces it
with a singleton object called NULL_OBJECT. It therefore gets a real
equals and hashCode method that can be called.

 

[Mike Schilling]

The way HashMap does it is that if you pass null it actually replaces it
with a singleton object called NULL_OBJECT. It therefore gets a real
equals and hashCode method that can be called.

Sure, but that's not always feasible.