Re: [fedora-java] Bug in openjdks TreeMap?

[Jerry James]

2009/5/8 Christoph Höger <choeger(a)cs.tu-berlin.de&gt;

>  Hi,
>
>  I enounter a very odd behaviour of a TreeMap. This is the code fragment:
>
>                         System.err.println("contains: " +
>  state.getIndexMap().containsKey(termString));
>                         for (TerminalString term :
>  state.getIndexMap().keySet())
>                                 System.err.println("KEYS: " + term +
> "==" +
>  termString +":" +
>  term.equals(termString) + " compare: " +
>  state.getIndexMap().comparator().compare(term, termString));
>
>  The TreeMap returned getIndexMap contains mappings from TerminalString
>  to Integer.
>  This is the output:
>
>  contains: false
>  KEYS: redeclare (1581148120) ==redeclare (1581148120) :true compare: 0
>
>  So the key _is_ in that map. It also has the very same hashcode and the
>  comparator returns 0 and equals() is true. But still containsKey returns
>  zero.
>  Any guess why that?
>  
This can happen if the Comparator is not consistent with equals() for EVERY
value of your key type.  It is clear that it is consistent with equals() for
the key you are interested in.  However, the containsKey() method does a
walk of the tree, guided by the comparator.  If the comparator makes it take
a "wrong turn" at some point in the tree, it can wind up looking at a part
of the tree that does not contain the key of interest, and will therefore
tell you that the key is not in the map.  When you call keySet(), you get
all of the keys, regardless of their position in the tree, so then you see
it.

This is probably not of interest to the list, but if you'll send me your
TerminalString code and the comparator you are using in the TreeMap, I'm
happy to take a look.
-- 
Jerry James
http://www.jamezone.org/