commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne (JIRA)" <>
Subject [jira] Reopened: (COLLECTIONS-103) SoftRefHashMap is all kinds of wonky
Date Thu, 13 Jul 2006 22:34:30 GMT
     [ ]
Stephen Colebourne reopened COLLECTIONS-103:

> SoftRefHashMap is all kinds of wonky
> ------------------------------------
>          Key: COLLECTIONS-103
>          URL:
>      Project: Commons Collections
>         Type: Bug

>  Environment: Operating System: All
> Platform: All
>     Reporter: Paul Jack
>      Fix For: 2.1

> Many methods in SoftRefHashMap do not conform the the java.util.Map 
> specification.  After you populate a SoftRefHashMap using its put or putAll 
> method, it transforms the values into SoftReferences.  The get() method 
> correctly re-translates the SoftReferences back into the actual object values, 
> unless they've been garbage collected.
> However, the entrySet() collection view does NOT perform this reverse 
> translation; iterating over an entry set gives you Map.Entry with SoftReference 
> values.  Since the equals() and hashCode() methods rely on iterating over the 
> entry set, equals() and hashCode() are broken in SoftRefHashMap.
> Also, it's odd that after I put(key,value), containsValue(value) will return 
> true, yet I won't be able to find the value in the entry set.
> Also, invoking setValue() on a Map.Entry in the entrySet will correctly update 
> the map with a new value; however, the old value is not returned as per the Map 
> specification.
> Also, the values() and entrySet() collection views are not backed by the map; 
> alterations to the map are not reflected in any existing values() or entrySet() 
> collection views.
> Also, containsKey(Object) is wierd.  If I put(key,value), and the value is 
> subsequently garbage collected, containsValue(value) will return false, yet 
> containsKey(key) will still return true.
> Creating a values() collection view creates hard references to the map's 
> values, essentially ruining the point of the class (so long as the values() 
> collection view exists, the map does not function as a memory-aware cache).
> Finally, iterating over keySet() and entrySet() is wonky.  Mappings might have 
> been removed by the garbage collector, but the iterators will still return an 
> object for the mapping.  So keySet()'s iterator will return keys for values 
> that aren't there anymore, and entrySet()'s iterator will return Map.Entries 
> with keys that map to null instead of values.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message