commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COLLECTIONS-103) SoftRefHashMap is all kinds of wonky
Date Thu, 13 Jul 2006 22:47:30 GMT
     [ http://issues.apache.org/jira/browse/COLLECTIONS-103?page=all ]

Stephen Colebourne updated COLLECTIONS-103:
-------------------------------------------

    Bugzilla Id:   (was: 9571)
        Version: 2.0

> SoftRefHashMap is all kinds of wonky
> ------------------------------------
>
>          Key: COLLECTIONS-103
>          URL: http://issues.apache.org/jira/browse/COLLECTIONS-103
>      Project: Commons Collections
>         Type: Bug

>     Versions: 2.0
>  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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message