commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian S O'Neill <>
Subject Re: [collections] HashedMap and subclasses
Date Sat, 06 Dec 2003 17:07:06 GMT
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 

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
>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
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message