[ https://issues.apache.org/jira/browse/COLLECTIONS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743065#action_12743065 ]
Tom Parker commented on COLLECTIONS-332: ---------------------------------------- Per my note to the commons user list, I was hoping for either updated docs or a code change, but I think one of the two would be good. Looking for a code change, I agree casting is nasty and would recommend against it... it's very ugly to get all cases correct. For example, a TreeMap sorted in case insensitive order also breaks ListOrderedMap because it also fails to use .equals(). Before this is turned into a documentation bug or feature request, I'd like to note a potential solution simply depends upon how much of a performance hit one is willing to take. {quote} Object result = getMap().remove(key); for (Iterator<Object> it = insertOrder.iterator(); it.hasNext();) \{ if (!getMap().containsKey(it.next())) \{ //This respects equality as defined by the underlying map it.remove(); \} \} return result; {quote} ...would seem to be universal (if slower since it effectively trades a .equals() for a .containsKey() call) [and yes, getMap() should be extracted to a local variable] > ListOrderedMap not respecting underlying list > --------------------------------------------- > > Key: COLLECTIONS-332 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-332 > Project: Commons Collections > Issue Type: Bug > Components: Map > Reporter: Tom Parker > Priority: Minor > Attachments: ListOrderedMapTest.java > > > When decorating either CaseInsensitiveMap or IdentityMap (and I believe this > will impact any java.util.TreeMap built with a non-.equals() Comparator), > ListOrderedMap responds inconsistently with the underlying map. The ordering > seems to be operating off .equals() rather than the actual contents of the > underlying map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.