[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [really patch] Re: HashMap putAll/putAllInternal bug
Date: Thu, 16 Oct 2003 06:33:22 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

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 =;
  /* 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

Someday, I might put a cute statement here.

Eric Blake             address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]