NPE in PriorityQueue.poll()

[Patricia Shanahan]

Since the queue isn't being rendered unusable and the console isn't
being spammed with dozens in a row, it seems that some object is
actually removed -- the null. If the null remained in the queue for any
length of time, then yes there's be more than a minor nuisance.
Fortunately that does not seem to be happening.

Did I mention that I never saw NPEs here before updating to 1.6.0?

That is consistent with either of two theories:

1. A bug in the 1.6 implementation of PriorityQueue that does not exist
in the 1.5 version.

2. A bug in your code that does not produce any obvious errors in the
pre-1.6 version of the code.

For example, a compareTo change while an object is on the queue would be
much more likely to produce an NPE with the 1.6 implementation of
PriorityQueue than the 1.5 implementation.

Patricia

 

[Daniel Pitts]

No, it's "setup" by the constructor and unchanged afterwards.


I have code elsewhere that does mutate objects in queues. Anytime the
change would affect compareTo() or equals() the object is removed,
modified, and added back. (All while synchronizing on the queue.) In no
case is the object concurrently modified somewhere else.

Give us an sscce (http://physci.org/codes/sscce/) and we'll give you
the solution you ask for.

 

[Twisted]

Give us an sscce

I don't have one -- whatever it is.

And what is that link you keep spamming in this newsgroup?

 

[Twisted]

For example, a compareTo change while an object is on the queue would be
much more likely to produce an NPE with the 1.6 implementation of
PriorityQueue than the 1.5 implementation.

Highly unlikely to be the cause, since all of the fields in the object
in question are final.

 

[Daniel Pitts]

I don't have one -- whatever it is.

And what is that link you keep spamming in this newsgroup?

Try reading the link, as it tells you what an sscce is, and advice to
creating one - Short, Self Contained, Correct (Compilable), Example.

 

[Twisted]

Try reading the link, as it tells you what an sscce is, and advice to
creating one - Short, Self Contained, Correct (Compilable), Example.

Ah. Well, let that be a lesson to you then. When you write, try to
avoid clever acronyms as a substitute for clarity of expression -- and
don't rely on people following a link to get your message across,
because people are way too leery of spam, spyware, and so forth to do
anything but ignore links in Usenet posts except in a reply to a post
where they specifically asked for a link, or links to well-known safe
resources like Google and Wikipedia.

 

[Daniel Pitts]

Ah. Well, let that be a lesson to you then. When you write, try to
avoid clever acronyms as a substitute for clarity of expression -- and
don't rely on people following a link to get your message across,
because people are way too leery of spam, spyware, and so forth to do
anything but ignore links in Usenet posts except in a reply to a post
where they specifically asked for a link, or links to well-known safe
resources like Google and Wikipedia.

Sure can do, and let it be a lesson to you that when several people
answer your questions the same way, perhaps you should investigate in
understanding why. The link I provided is safe, and in any case,
providing an example that allows us to reproduce your problem is the
best route for help anyway.

 

[Twisted]

Sure can do, and let it be a lesson to you that when several people
answer your questions the same way, perhaps you should investigate in
understanding why.

If the answer is not actually an answer but another question, Web
links, or whatever, then it is liable to get ignored. In any event, you
posting the same thing to two or three different threads does not
constitute "several people" doing *anything*.

The link I provided is safe

And I'm supposed to just take your word for it? You may know it's safe,
but all I know is it's an unsolicited(x) link to an unfamiliar(xx) site
that somebody posted on usenet inside a post that is, at best,
tangential to the topic(xxx) under discussion. That's three strikes,
you're out, meaning I don't follow the link without a compelling reason
of some kind. Certainly not just out of curiosity.

and in any case,
providing an example that allows us to reproduce your problem is the
best route for help anyway.

Too bad it isn't always possible. The things I'm reporting are complex
bugs that reproduce sporadically rather than systematically and
basically to make them show up you just have to engage in extensive,
normal use until it pops up. The simple, predictable bugs were easy to
either fix (in my code) or work around as the case may be; for the most
part, they never make it to being the subject of a Usenet posting. That
leaves the complex ones.

 

[Andreas Leitgeb]

Highly unlikely to be the cause, since all of the fields in the object
in question are final.

Unless these fields (those relevant to compareTo) are exclusively
primitive types or immutable Objects (Integer, String, ...),
the "final" doesn't help anything.

So, perhaps not the enqueued items are changed, but any (even final)
referenced Objects can change, and are relevant to sorting ?

 

[Twisted]

Unless these fields (those relevant to compareTo) are exclusively
primitive types or immutable Objects (Integer, String, ...),
the "final" doesn't help anything.

They are. Didn't I mention that the only things being used in
compareTo() are booleans and integers?

 

[Andreas Leitgeb]

They are. Didn't I mention that the only things being used in
compareTo() are booleans and integers?

Probably you did. But you can't expect anyone to remember all
bits and bytes of all previous postings

Anyway, I think I'm through with my bag of tricks, so unless
you take the effort to write some small app to reproduce the
error, I'll end my participation in this thread. :-(

Perhaps, posting just that one class (that gets enqueued) might
help for further diagnosis without giving away too much "IP".