Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 11149 invoked from network); 25 Feb 2004 17:08:17 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 25 Feb 2004 17:08:17 -0000 Received: (qmail 85365 invoked by uid 500); 25 Feb 2004 17:08:05 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 85298 invoked by uid 500); 25 Feb 2004 17:08:04 -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 85256 invoked from network); 25 Feb 2004 17:08:04 -0000 Received: from unknown (HELO exchange.sun.com) (192.18.33.10) by daedalus.apache.org with SMTP; 25 Feb 2004 17:08:04 -0000 Received: (qmail 1964 invoked by uid 50); 25 Feb 2004 17:08:30 -0000 Date: 25 Feb 2004 17:08:30 -0000 Message-ID: <20040225170830.1963.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 27231] New: - Change to HashEntry inner class of AbstractHashedMap X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.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=27231 Change to HashEntry inner class of AbstractHashedMap Summary: Change to HashEntry inner class of AbstractHashedMap Product: Commons Version: unspecified Platform: All URL: http://bblfish.net/java/collections/ OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Collections AssignedTo: commons-dev@jakarta.apache.org ReportedBy: henry.story@bblfish.net The way the AbstractHashedMap class is currently written it is not as extensible as it could be. The HashEntry static inner class is abstract. By slightly refactoring it to an inner interface one can get a lot more mileage out of it. This change has minimal impact on four other classes from the map package. Two extra classes which I will submit as a seperate patch (should I do this before this one is accepted?) that use this inner interface are a HashedSet and a WeakHashedSet. Both of these classes are adapters of a subclass of the changed AbstractHashedMap. The HashEntry interface essentially hides the representation of the key and value objects. In a HashSet the key is the value, so this avoids the duplication - not of objects, but of references. More importantly it also allows a HashEntry to extend a WeakReference Object, which cannot be done as the code presently stands. Here is the new interface: protected static interface HashEntry extends Map.Entry, KeyValue { public HashEntry getNext(); public void setNext(HashEntry next); public int getHashCode(); public void setHashCode(int hashCode); /** * @param key raw key (ie, no interpretation for special cases like NULL */ public void setRawKey(Object key); /** * * @return the raw key */ public Object getRawKey(); } This allows the implementation to decide how they can refer to the key and the values. Essentially we remove all reference in the code to the variables 'key' and 'value' and replace them with the (set/ get)rawkey (set/get)value methods. The raw key method is necessary as the setKey method is often overridden to do special null substition work. I have also created a more interesting NULL object, that can better describe itself. When debugging it is often helpful to know that one is looking at a NULL object. Finally I also - and debatably wrongly - changed the Iterator from static inner classes to real inner classes. This is how it is meant to work anyway. An inner class just has a reference to its enclosing class. But perhaps there is something here that I have not understood. My other contributions don't hang on this change. They just make the code a little simpler. If the intention is to extract these classes to an external package, then the current solution of having a static inner class makes sense. I will attach class diagrams and diffs to this request to clarify the changes. --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org