Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 88263 invoked from network); 6 Dec 2003 17:07:16 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 6 Dec 2003 17:07:16 -0000 Received: (qmail 54935 invoked by uid 500); 6 Dec 2003 17:07:06 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 54885 invoked by uid 500); 6 Dec 2003 17:07:06 -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 54872 invoked from network); 6 Dec 2003 17:07:06 -0000 Received: from unknown (HELO scaup.mail.pas.earthlink.net) (207.217.120.49) by daedalus.apache.org with SMTP; 6 Dec 2003 17:07:06 -0000 Received: from h-69-3-70-6.sttnwaho.dynamic.covad.net ([69.3.70.6] helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1ASftc-0005ck-00 for commons-dev@jakarta.apache.org; Sat, 06 Dec 2003 09:07:09 -0800 Message-ID: <3FD20CBA.1070904@earthlink.net> Date: Sat, 06 Dec 2003 09:07:06 -0800 From: Brian S O'Neill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [collections] HashedMap and subclasses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 The "IdentityMap" caught my attention. I wrote a map with the same name awhile back which had one extra feature. The keys were weakly referenced. I think the name "WeakIdentityMap" is more sensible. The implementation would clean out cleared entires as they were discovered and before expansions. If space is freed up, then the expansion in canceled. This map can be safely used in place of IdentityMap, but it may have extra performance and storage overhead. Anyhow, I'm wondering if you think that the extensible HashedMap contains enough "override" points to make this sort of map possible without having to implement from WeakIdentityMap from scratch. I think all the necessary override points are there, I'll just have to see if it works. http://teatrove.sourceforge.net/javadoc/com/go/trove/util/IdentityMap.html Stephen Colebourne wrote: >A number of new classes now form a hierarchy in the map subpackage: > >HashedMap (general hash map) > >IdentityMap extends HashedMap (uses ==) > >LinkedMap extends HashedMap (insertion order) > >LRUMap extends LinkedMap (access order, drops oldest) > > >Is everyone happy with this hierarchy? >Should LRUMap (access order) extend LinkedMap (insertion order) (lots of >code shared)? >Should there be an AbstractHashedMap class, rather than all extending >HashedMap? > >We're going to have to live with this so it needs to be right.....;-) > >Also, should caching and reusing of previous MapEntry objects be part of the >default implementations? > >Finally, I think that StaticBucketMap and ReferenceMap don't benefit from >extending HashedMap, but if someone wants to confirm or deny this they're >most welcome :-0 > >Stephen > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org >For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org