[Commons-Avalon:collections] code integration

["Michael A. Smith" <ma...@apache.org>]

On Thu, 20 Jun 2002, Nicola Ken Barozzi wrote:
> The Avalon project has decided that it's time to move some packages of 
> the jakarta-avalon-excalibur module to Commons.
> 
> Some of the packages there eligible for the move are:
[snip]
> collections

It looks like most of collections was already copied over some time ago
(just over a year ago).  The only things missing are the Buffer classes
and the BucketMap.

>         how can we integrate?

The code that had already been moved over differs a bit, but i have a
feeling it's mostly just by "style" since the avalon versions went
through a reformatting of the code 3 months ago.  I'd be more than happy
to assist in looking for actual code differences and integrating them.  
I won't have a chance for at least a week though.

I do have a couple of concerns with the BucketMap.  In a quick glance,
it looks like it doesn't follow the Map contract -- the colletion views
are not backed by the map.  The new commons collections test suite for
Map implementations should check for that, along with potentially other 
differences from the Map contract.  Any differences in contract would 
have to be resolved. 

regards,
michael



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Commons-Avalon:collections] code integration

["Michael A. Smith" <ma...@apache.org>]

On Thu, 20 Jun 2002, Berin Loritsch wrote:
> > From: Michael A. Smith [mailto:mas@apache.org] 
> 
> > I do have a couple of concerns with the BucketMap.  In a 
> > quick glance, it looks like it doesn't follow the Map 
> > contract -- the colletion views are not backed by the map.  
> > The new commons collections test suite for Map 
> > implementations should check for that, along with potentially other 
> > differences from the Map contract.  Any differences in contract would 
> > have to be resolved. 
> 
> BTW, I wrote the BucketMap.  My primary concern while
> writing it was fine-grained locking.  At that it excells.  The
> process of adding, removing, and looking up information far
> exceeds a Synchronized Map or Hashtable when multiple threads
> are trying to do the same thing.
> 
> The main focus was an add/remove/lookup--not the rest of the
> Map contracts.  That is because of the focus of what it is
> used for.

yup, I understand that...  My point is that the rest of the map contract 
should be addressed as well.  :)

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?  

btw, I'd be happy to fix that issue in BucketMap once it's moved over.  
It's really not that difficult to do and wouldn't have an impact on 
thread contention, although it probably would increase the memory 
footprint a bit and add a couple of operations for each lookup (a 
bitwise &, an array dereference, a comparison to see if the 
expansion threshold had been reached, and the amortized cost of table 
expansion).  

regards
michael



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Commons-Avalon:collections] code integration

[Berin Loritsch <bl...@apache.org>]

> From: Michael A. Smith [mailto:mas@apache.org] 

> I do have a couple of concerns with the BucketMap.  In a 
> quick glance, it looks like it doesn't follow the Map 
> contract -- the colletion views are not backed by the map.  
> The new commons collections test suite for Map 
> implementations should check for that, along with potentially other 
> differences from the Map contract.  Any differences in contract would 
> have to be resolved. 

BTW, I wrote the BucketMap.  My primary concern while
writing it was fine-grained locking.  At that it excells.  The
process of adding, removing, and looking up information far
exceeds a Synchronized Map or Hashtable when multiple threads
are trying to do the same thing.

The main focus was an add/remove/lookup--not the rest of the
Map contracts.  That is because of the focus of what it is
used for.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>