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

[Eric Blake]

I just thought of another argument for changing the Map.putAll implementations 
to use hasNext(), rather than size().  Sun's proposal for JDK 1.5 includes 
adding a foreach construct, documented in JSR 201.  According to their 
proposal, the syntax:

for (Object o : mymap.keys()) { /* use o */ }

will be short for

for (Iterator i = mymap.keys().iterator(); i.hasNext();)
{
  Object o = i.next();
  /* use o */
}

Sun seems to be blessing the use of hasNext() here, by not documenting that 
this should optimize to calling size().

I also agree that correctly calculating size() for a list composed of two 
other lists is easy, but for a set composed of two other sets is difficult, 
because of the set property that duplicate elements be counted only once.

David Holmes wrote:
> Stuart Ballard wrote:
>
> > because the code that's causing a problem is in HashMap,
> > not AbstractMap, and it applies
> > when a Map of my type is passed to putAll() on a HashMap.
>
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Stuart I apologize. I had misunderstood the exact nature and source of
> the problem. I agree that both Abstractmap and HashMap putAll methods
> should use hasNext() of the target collections iterator, not it's
> size() method. In fact those methods should use nothing other than the
> target collection's iterator as specified in AbstractMap.
>
> David Holmes
>
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath

--
Someday, I might put a cute statement here.

Eric Blake             address@hidden