Re: HashMap get/put
Wojtek wrote:
If I have the following:
HashMap<MyKey,MyValue> map = new HashMap<MyKey,MyValue>();
MyKey myKey = new MyKey();
Then I can put in a value by:
map.put(myKey, new MyValue() );
The compiler enforces the use of these two types.
However to do a get I can do the following and the compiler does not
complain:
map.get(myKey); // this is right
map.get(myKey.toString()); // this is wrong yet legal
map.get(new Long(20)); // this is wrong yet legal
All of these are legal according to the compiler. Why is it that the
compiler does not enforce type checking on the get()?
Or rather, why does the spec not say get(K key) instead of
get(Object
o)
http://java.sun.com/javase/6/docs/api/java/util/HashMap.html#get(java.lang.Object)
I can picture (vaguely) looking something up with an object that's
equal to the original key but not of the same type. This makes at
least some sense with HashMaps, since it's possible, for objects T1 a
and T2 b, where T1 and T2 are any types at all, that a.equals(b) and
a.hashCode() == b.hashCode().
TreeMap is weirder:
Map<Integer, String> m = new TreeMap<Integer,String>();
m.put(2, "foo");
String val = m.get("bar");
This compiles just fine, but results in
Exception in thread "main" java.lang.ClassCastException:
java.lang.Integer
at java.lang.String.compareTo(String.java:90)
at java.util.TreeMap.compare(TreeMap.java:1093)
at java.util.TreeMap.getEntry(TreeMap.java:347)
at java.util.TreeMap.get(TreeMap.java:265)
at WeirdMap.main(WeirdMap.java:11)
Since a String can't even be compared to the Integer keys.
Actually, it strikes me as odd that String.compare() is called rather
than Integer.compare(). I suppose that if you want precise control
over how comparisons are done, you need to pass in your own
Comparator.