13

Possible Duplicate:
What are the reasons why Map.get(Object key) is not (fully) generic

This method and a number of other methods in the Map interface are not generic. Almost anywhere a key value is expected as a parameter, it accepts Object instead, namely remove, get and containsKey.

Any idea as to why they made this decision. My assumption is that it was done to support legacy code, but to me, I think that is a weak position.

Can anyone provide me a specific reason why it would be preferable to accept Object here instead of KeyType.

Community
  • 1
  • 1
Kevin Dolan
  • 4,952
  • 3
  • 35
  • 47

1 Answers1

11

The objects used to retrieve/remove/check for existance of a given key need not necessarily be of the same type as the object used to store it (= the key).

It needs to be equal and return the same hashCode as the key, but nothing in the spec says that it must be of the same type.

That fact is rarely used and most of the time you'll retrieve the values with the same keys (or at least objects of the same types) as the ones you use to store them.

But since that was a supported use case in the "old" HashMap, it needs to be supported in the generics version as well.

Note that all methods that keySet() uses the specific type, as it's sure to return exactly the objects used as keys when put() was called.

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • Ah, very well. Thanks for answering. I suppose that makes a bit of sense. I guess you could search by Integers a mapping that uses Doubles as keys... – Kevin Dolan Jan 13 '11 at 08:04
  • 1
    @Kevin: that specific exampe won't work, because `Integer` and `Double` don't have compatible `equals()` implementations. – Joachim Sauer Jan 13 '11 at 14:50