Or as in my case, "Learn from your blunders."  I'd tried
to write a Map with case-insensitive Strings as keys:

    Map<String,Thing> map = new HashMap<String,Thing>() {
       public Thing put(String key, Thing value) {
           return super.put(key.toLowerCase(), value);
       }
       public Thing get(String key) {
           return super.get(key.toLowerCase());
       }
    }

... and then I got splinters in my fingers from scratching
my head over why it didn't work.  After the penny dropped,
I changed the second method to

       public Thing get(Object key) {
           if (key instanceof String)
               key = ((String)key).toLowerCase();
           return super.get(key);
       }

... and things worked a whole lot better.  (The `if' isn't
necessary, but given my state of confusion at the time it's
perhaps forgivable.)  Having been through this, I am now
"Once burned, twice shy."

Putting the response before the stimulus.
What is "top-posting?"
Please don't top-post.

    Of course put() is parameterized, because it needs to ensure
that you don't insert a String key into a Map that expects only
Integers.  But get() doesn't need to be so picky: If you search
that Map for an entry with the key "Mongo", get() reports that
no such entry exists.  Nothing odd about that, is there?

    Consider this pre-generics situation: I've got a Map

    Map squares = new HashMap();

... and I populate it with some data

    for (int n = 0;  n < 10;  ++n)
       squares.put(new Integer(n), new Integer(n*n));

Now I make some queries:

    Integer value1 = (Integer)squares.get(new Integer(5));
    Integer value2 = (Integer)squares.get(new Integer(42));
    Integer value3 = (Integer)squares.get("Mongo");

The first query returns a reference to an Integer with the
value 25.  The second returns null because the Map has no
entry with the key 42.  And the third returns null because
the Map has no entry with the key "Mongo".  What difference
is there between the second and third outcomes?  None; they
both declare "key not found," and there's an end on't.

    Remember, too, that generics are a compile-time hint and
not a run-time enforcement.  By ignoring enough warnings you
can in fact put a String key and a BigDecimal value into a
Map<Integer,Integer> -- and if you were to do so, and then
turn around and search for the String key, shouldn't get()
find the BigDecimal for you?

    I imagine that the design decisions might have been made
differently if generics had been part of Java from the start
and if they were backed up by run-time enforcement.  But for
whatever reason that's not the way things have turned out.

thufir wrote:

Bird's-eye view of the Java Map, from that link:

Some scripting languages, including Java EE's own Expression Language (EL),
depict maps as associative arrays: ${ranches ["BelongaMick"]}.

The "<K, V>" in the interface are the key and value types, respectively.  Any
two object types can be associated in a Map.

 Map <String, Entity> namedEntities = new HashMap <String, Entity> ();
 namedEntities.put( "Mjolnir", new MagicHammerEntity( "Mjolnir", "Thor" ) );