[jira] Issue Comment Edited: (COLLECTIONS-332) ListOrderedMap not respecting underlying list

["Tom Parker (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COLLECTIONS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743065#action_12743065 ] 

Tom Parker edited comment on COLLECTIONS-332 at 8/13/09 8:43 PM:
-----------------------------------------------------------------

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.

{code:java}
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;
{code}

...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]


      was (Author: thpr):
    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.