Map.get(K) and Map.get(Object)

Question

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

Answer 1

Gafter wrote:
The reason the argument type is Object and not K is that existing code depends on the fact
that passing the "wrong" key type is allowed, causes no error, and simply results in the
key not being found in the map.But "existing code" does not use Generics, and therefore as with all other non-generic code, the authors of that code can choose to either leave it as it is (in which case their Maps will become Map<Object,Object> and Map.get() will then take an Object), or to upgrade it to Generics, and take advantage of the helpful compiler messages that may highlight some design flaws in the original code.
In Jakarta Commons Collections (this is "existing code"), there's a class MultiHashMap which extends HashMap. When you call MultiHashMap.put(someKey, someValue) it appends someValue to an ArrayList that gets stored as the value in the HashMap. However when you call MultiHashMap.get(someKey), it returns a Collection of values, rather than just a single value.
If they try to upgrade MultiHashMap to Generics, they are going to come up with a problem: they would be needing something like this:
    public class MultiHashMap<K,V> extends HashMap<K,V> {
        public V put(K key, V value) { ... }
        public Collection<V> get(K key) { ... }
    }which of course is not allowed, since Map<K,V>.get() returns V, not Collection<V>.
Now, I don't hear anyone saying: This "existing code" relies on Map.get() returning an Object, so in Generics we're going to make Map.get() return Object rather than V.
No, instead we (correctly) say: That MultiHashMap code was wrong to abuse the flexibility provided by the use of Object as the return value of Map.get(), and if it wishes to use Generics, it will either need to become MultiHashMap<K,Object>, or if it insists on being MultiHashMap<K,V>, it will not be allowed to extend HashMap.
I really don't see the problem in using Generics (and a typesafe Java Collections API) as a means of highlighting problems in existing code. As I said before, existing code will continue to work as before, because List will become List<Object> and Map will become Map<Object,Object>.
This is no worse than "accidentally" trying to get() with a key of the right
type but the wrong value. Since none of these methods place the key into the
map, it is entirely typesafe to use Object as the method's parameter.Suppose for a moment that when String.endsWith() was first written, it took an Object parameter instead of a String. If I were to say to you: This method needs to change its parameter from Object to String, would you tell me that that there's no need to make the change, because a String can only ever end in a String, and so it is entirely typesafe to use Object as the method's parameter?
Geoff