I had seen, only the String is used as a key in HashMap.Although the put() method takes Object as a parameter.What is the significant of it.If any other object can also used as a Key or not? Please provide the answers.
-
1@Michael How do you know this is a Java question? – Dec 13 '09 at 11:02
-
5Do you know any other language which has a `HashMap` class with a `put()` method which takes `Object` as parameter? – BalusC Dec 14 '09 at 17:44
6 Answers
Any object that provides a meaningful implementation of hashCode()
is a perfect key candidate in a map: see Understanding the workings of equals and hashCode in a HashMap.
Also, as @Jon mentioned, all keys in your map should be of the same type.
EDIT: Of course, you need to implement both equals()
and hashcode()
. I thought the title of the link to the other question made that clear. But a dumb implementation of hashcode()
will just bring you a degenerate HashMap
which performance is poor.
EDIT2: As @Adrian mentioned in his answer, generics will help you constrain the type of keys and values for the map.
References:

- 1
- 1

- 69,011
- 20
- 139
- 164
-
And, of course, if you override hashCode() you also must override equals(), otherwise your hash map will potentially do some weird things. – Ash Dec 13 '09 at 11:04
-
Nope, only an object that implements **both** equals and hash (or none of both) should be used as key. – akuhn Dec 13 '09 at 11:14
-
@Adrian > it was implied as i'm linking to the other answer... however implementing both equals and hashcode with a dump hashcode implementation will bring you nowhere... – Gregory Pakosz Dec 13 '09 at 11:17
A raw HashMap
will indeed accept any object as key. However, it is good style to specify which kind of keys and values you are going to use in a map
Map<String, Whatever> map = new HashMap<String, Whatever>();
if you do so, the put()
method will only accept strings.
NB: if you choose to use one of your own classes as keys, make sure the class either implements both equals
and hashCode
or none of them!

- 27,477
- 2
- 76
- 91
One probable reason why you see "String" used as hash key quite often is that it is an
immutable class.
Immutable objects make great map keys since one need not worry about their values
being modified once they're in a map or set, which would destroy
map or set's invaraints (Item 15 Effective Java, 2nd Edition)

- 27,947
- 7
- 36
- 45
One of the reason why we generally use String as a key in HashMap is that since String is immutable in Java that allows String to cache its hashcode , being immutable String in Java caches its hash code and do not calculate every time we call hashcode method of String, which makes it very fast as HashMap key.

- 20,708
- 48
- 131
- 198
-
Yes, but this is only true if we are using the same String instance to access the HashMap again, not because of the hashCode(), but because equals() takes O(length of string) time for two Strings that are identical, but not the same instance. – kutschkem Jul 17 '13 at 08:04
-
On my system (many years later) this allows an ideavim `Y` yanked line to be pasted into (say) my terminal outside of IDEA, but doesn't allow a copied string from my terminal to enter my code via an ideavim `p`. Did something change? – alife Oct 17 '22 at 22:42
You haven't shown which platform you're talking about, but I'll assume for the moment that it's Java.
You can use any type for the key in a HashMap
, but assuming you use the full generic version you need to specify that type and then use it consistent. For example, you could use URI as the key type:
HashMap<URI, Integer> hitCountMap = new HashMap<URI, Integer>();
The get
method takes Object as the key parameter type, but you should of course use the same type of key that you've put into the map. See this question for more discussion on that.
-
6URL is perhaps a bad example of a key in a hash map. From the documentation, the hash code is based upon all the URL components relevant for URL comparison. It's slow (as it involves resolving the URL against the name server) so it's probably better to use a URI. That, of course, is a complete aside to this question! – Jeff Foster Dec 13 '09 at 10:52
The key type can be any type, including (for some use-cases) Object. The only technical requirement is that equals(Object)
and hashcode()
are correctly implemented for all classes whose instances might be used as keys. In practice, you also want the semantics of equals(Object)
to be consistent with the intended behavior of the HashMap, across all possible key types / values.
However, if you genuinely do need to use Object as the key type, IdentityHashMap may be a better option. For a start, it doesn't use equals(Object)
or hashcode()
, but uses ==
and the key objects' "identity hash" values.

- 698,415
- 94
- 811
- 1,216