Hehe, a valid point sir, it's rather rude to ask a question and then not
post the answer, so my apologies.

A possible explanation is as follows :

If the method signature of Map.get would be get(K key) there is no way to
pass anything but an object of type K to this method at run-time because the
code wouldnt compile (generics, after all, is a compile time wizardry). In
most circumstances this is actually a good thing, but sometimes you want to
check if there's a value in your map with key object X without really caring
(or wanting to care) if that object X is actually of type K. If the method
signature was as i suggested this code wouldnt compile, and would thus force
an explicit instanceof check or checked cast at all points where you use
get/containsKey/etc. methods.

Now i should point out that it probably could be argued that such strictness
is actually a good thing since it reduces the possibility of type bugs, but
i guess the guys at Sun opted for flexibility.

As far as i'm aware changing the method signatures to include generics does
not break legacy code, so that shouldnt be the reason. Also, methods like
AbstractMap.equals(Object o) could still be implemented since a Map<K, V> t
= (Map<K, V>)o; is allowed even if o is not of Map<K, V>. I'm having a
discussion on the Java forums regarding the reason last cited, a lot of
people believe it is mostly due to that reason that Objects rather than Ks
are used in such method signatures.

If i'm missing something please let me know, but currently i'm just assuming
it's simply flexibility.

- Remon