PriorityQueue(collection) should throw NPE

Martin Buchholz martinrb at
Fri May 7 17:07:10 UTC 2010

On Fri, May 7, 2010 at 03:47, David Holmes <David.Holmes at> wrote:
> Hi Chris,
> Chris Hegarty said the following on 05/07/10 19:55:
>> Hi David, Martin,
>> Thanks for filing the bug David, I'll just add a link to the email thread
>> in the archive for reference.
> Thanks.
>> Just one minor observation while reviewing the changes. Is it necessary
>> for initFromPriorityQueue to call initFromCollection ( in the case where
>> you're given a PriorityQueue subclass), or can it simply call
>> initElementsFromCollection?
> It's possible that the subclass overrides toArray to return an array that
> doesn't preserve the internal order. Hence we need to re-sort, hence
> initFromCollection.


As a thought experiment, suppose you're writing a spiffy new
priority queue implementation that is supposed to be a drop-in
replacement for PriorityQueue.  You might choose to
subclass PriorityQueue even if you're not reusing any
of the implementation (because we made the
mistake of not making PriorityQueue an interface).
PriorityQueue's iterator and toArray methods make
no promises about element order.

On the bright side, heapify() will be O(N), not O(N log N)
if the input array is already heapified.


More information about the core-libs-dev mailing list