commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [Commons-Avalon:collections] code integration
Date Thu, 20 Jun 2002 16:03:56 GMT
> yup, I understand that...  My point is that the rest of the 
> map contract 
> should be addressed as well.  :)

Agreed.  I'll fix the collection views if you'd like.

Also, BucketMap does not support null keys or values but 
returns null when such values are supplied to put().  
Map contract specifies NullPointerException in that case.

The tests won't pick that up, so we should add a test case.

Also, there's no no-argument and Map-argument constructors;
not required, but recommended.


> btw, one thing that java.util.HashMap and java.util.Hashtable 
> provide is the ability to have the underlying hashtable grow 
> when the contents of the hashtable grow to a certain load 
> factor of the size of the underlying table.  I didn't see the 
> same feature in BucketMap.  Wouldn't that mean that BucketMap 
> would degrade in performance significantly (compared with 
> java.util's hash based maps) as the size of the map 
> increases well beyond its number of buckets?  

I don't think auto-resizing could be implemented in BucketMap
without affecting the optimizations in the get and put 
methods.  Basically, what monitor do you enter when you're
resizing the array of monitors?  Any clever workaround would
incur double-checked-locking-esque problems.

I think BucketMap is optimal for the case when you know upfront
that you have a maximum number of possible mappings at any
time.

-Paul


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message