c.toArray might (incorrectly) not return Object[] (see 6260652)

Doug Lea dl at cs.oswego.edu
Fri May 22 11:56:08 UTC 2009

David Holmes - Sun Microsystems wrote:
> Doug Lea said the following on 05/22/09 21:31:
>> David Holmes - Sun Microsystems wrote:
>>> Thanks for the info, one query though ...
>>> Ummm why didn't it just use:
>>>     elementData = c.toArray(new Object[c.size()]);
>> Because "c" might be a concurrent collection, so you
>> don't want to independently call c.size(). Notice
>> that AbstractCollection correctly implements
>> toArray() even for such collections but cannot do so
>> for toArray(T[] a) because it must interpret
>> a.length as the required size.
> Has that code been updated recently because it sure looks like it tries 
> to acommodate this and always return an array of exactly size() length 
> (at the time toArray is called). ??

Sorry; I should have been clearer about why
   c.toArray(new Object[c.size()])
is subtly wrong here. ArrayList.size must equal
the number of elements, which might be different
than the array size. If c's size shrinks at an
inconvenient moment during the call, then we might
think that the trailing null, that toArray(T[] a)
is required to append if a is too big, is actually a
(null) element of the collection.


More information about the core-libs-dev mailing list