You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Stephen Colebourne (JIRA)" <ji...@apache.org> on 2006/07/14 00:30:30 UTC
[jira] Updated: (COLLECTIONS-103) SoftRefHashMap is all kinds of
wonky
[ http://issues.apache.org/jira/browse/COLLECTIONS-103?page=all ]
Stephen Colebourne updated COLLECTIONS-103:
-------------------------------------------
Bugzilla Id: (was: 9571)
Fix Version: 2.1
> SoftRefHashMap is all kinds of wonky
> ------------------------------------
>
> Key: COLLECTIONS-103
> URL: http://issues.apache.org/jira/browse/COLLECTIONS-103
> 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:
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