Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 11530 invoked from network); 3 Jun 2002 06:12:02 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Jun 2002 06:12:02 -0000 Received: (qmail 3539 invoked by uid 97); 3 Jun 2002 06:12:11 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 3521 invoked by uid 97); 3 Jun 2002 06:12:11 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 3493 invoked by uid 50); 3 Jun 2002 06:12:10 -0000 Date: 3 Jun 2002 06:12:10 -0000 Message-ID: <20020603061210.3492.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 9571] New: - SoftRefHashMap is all kinds of wonky X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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: For additional commands, e-mail: