When I first saw the new 2.0 generics compiler, I was very pleased to see that the signature of Map.get() has changed (since 1.3) from:
interface Map<K,V> { V get(Object obj); }
to:
interface Map<K,V> { V get(K key); }
because it means buggy code like this:
Map<File,Integer> fileSizeMap = new HashMap<File,Integer>();
...
Integer sizeOfFile = fileSizeMap.get("/tmp/foo");
if (sizeOfFile == null) {
System.err.println("File not found in map");
}
(where I have mistakenly called Map.get() with a String rather than a File) will now get a
compiler error rather than a fault raised several months after the application has gone live.
So, as I say, I am very pleased with the new signature for Map.get(), although I would also like to see the following methods changed:
boolean containsKey(Object) -> boolean containsKey(K)
boolean containsValue(Object) -> boolean containsValue(V)
V remove(Object object) -> V remove(K)
However, I just read on http://cag.lcs.mit.edu/~cananian/Projects/GJ/Bugs/v20/map.html that Neal Gafter says that putting Map.get(K) into 2.0 was a mistake, and that it will be put back to Map.get(Object) in the next version.
I do hope I haven't missed something obvious, but keeping these methods with Object parameters seems to me to be a backwards step from the excellent type safety benefits provided by Generics.
Does anyone else agree with me that having get(K) would be beneficial in allowing the compiler to identify bugs that would otherwise only be discovered much later?
Or, could someone explain to me why having get(Object) is preferable, and whether this reason is more important than the type safety issue I identified in my example code above?
Many thanks in advance
Geoff