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