Re: NPE in PriorityQueue.poll()
Twisted wrote:
Mark Jeffcoat wrote:
I've hypothesized that compareTo() is throwing an uncaught
exception; you don't need an argument to prove me wrong, just
wrap the entire method in a block that catches everything,
and show that the behavior doesn't change.
It doesn't do anything except test booleans and compare (with < and ==)
ints. I don't see it throwing any exception, except NPE if it gets a
null argument.
Other posters have hypothesized that you have threading
problems. What happens when you wrap your PriorityQueue
with Collections.synchronizedCollection()? Any change?
It's already synchronized.
You've hypothesized that nulls are being added to the
queue. What happens when you call PriorityQueue.add(null)?
I don't. There's only two places that add anything to the queue. One
adds the outcome of a new, and the other adds something back after it
had been removed and stored for a while, so if that one is adding a
null it's only because the queue already contained at least one null.
I have a more indirect hypothesis to throw in the mix. JDK 1.6
PriorityQueue has a heap implementation. Is there any possibility of it
getting confused, and going off the end or creating gaps, if compareTo
is inconsistent?
I'm a bit more willing than Mark to consider library issues with a
non-final version such as 1.6.
However, I would work in any case on trying to strip down the minimal
case that reproduces the problem. You will need a minimal test case if
it is a library issue, and if it isn't trying to prepare one may bring
out the actual bug.
Patricia