DO NOT REPLY [Bug 9571] New: - SoftRefHashMap is all kinds of wonky

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9571>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9571

SoftRefHashMap is all kinds of wonky

           Summary: SoftRefHashMap is all kinds of wonky
           Product: Commons
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Collections
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: pjack@sfaf.org


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.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: DO NOT REPLY [Bug 9571] New: - SoftRefHashMap is all kinds of wonky

[Peter Lynch <pe...@mindspring.com>]

> SoftRefHashMap is all kinds of wonky

Maybe it's late, but that is the funniest bug report title I have seen in a
while.

;-)

-Peter


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>