Re: [really patch] Re: HashMap putAll/putAllInternal bug

[Bryce McKinlay]

On Oct 11, 2003, at 4:00 AM, Stuart Ballard wrote:

> Bryce McKinlay wrote:
> > The collections classes, on the other hand, are actually quite well 
> > specified in my opinion (having architected many of the current 
> > collections implementations used in classpath). I don't believe that 
> > anyone should need to write collections code that relies on 
> > unspecified details.  Besides, matching every single one of those 
> > details would be close to impossible without copying Sun's source 
> > code virtually line for line. I think its better to stop now, while 
> > we have a very stable and bug-free set of collections classes, or we 
> > will forever be chasing silly, unspecified details like this, and 
> > potentially introducing real regressions and reducing performance in 
> > the process.
>
> I'm curious as to whether you can come up with an architecture for the 
> type of Map I need that includes an efficient and correct 
> implementation of size() - that is, an architecture such that the 
> prior implementation of putAll() would both work correctly and be not 
> significantly less efficient than calling hasNext().
>
> My requirement is for a map which holds references to two other maps, 
> "front" and "back". The keySet() of my map is the union of 
> front.keySet() and back.keySet(). The value corresponding to a given 
> key is 'front.containsKey(key) ? front.get(key) : back.get(key)'. Both 
> front and back can be accessed directly through other code and may 
> change in any way without my map being notified. How can I implement 
> size() without a full iteration?

If you need this to be fast, perhaps the best way (to guarantee good 
performance on any implementation) would be to define your own method:

HashMap asHashMap()
{
  HashMap hash = new HashMap(estimatedSize);
  hash.putAll(front);
  hash.putAll(back);
  return hash;
}

Bryce.