Java: strange order of queue made from priority queue

Question

I wrote a maze solving program which is supposed to support DFS, BFS, A*, Dijkstra's, and greedy algorithm. Anyway, I chose PriorityQueue for my frontier data structure since I thought a priority can behave like a queue, stack, or priority queue depends on the implementation of the comparator.

This is how I implemented my comparator to turn the priority queue into a queue:

/Since the "natural ordering" of a priority queue has the least element at the head and a conventional comparator returns -1 when the first is less than the second, the hacked comparator always return 1 so that the current (last) square will be placed at the tail (this should work recursively)/

public int compare(Square square1, Square square2)
{
    return 1;
}

However, my solution for the maze was not optimal after I did a BFS.

The maze starts at top right corner with coordinate (35,1) and my program checks the left, then up, then down, then right neighbour. Here are the println I did:

polled out (35,1)

added (34,1)

added (35,2)

polled out (34,1)

added (33,1)

added (34,2)

polled out (35,2)

added (35,3)

polled out (33,1)

added (32,1)

added (33,2)

polled out (34,2)

add (34,3)

poll out (32,1)

......

Notice in a BFS (35,3) should be polled out before (32,1) since the former is added into the queue before the latter. What really confused me is that the data structure behaved like a queue--all new members were added from the back--until I added (32,1), which was placed at the head of the queue.

I thought my comparator should force the priority queue to put new comers in the back. What is even stranger to me is that the data structure changed its nature from a queue to a stack in the middle.

Many thanks to you guys ahead and sorry about my poor English, Sincerely, Sean

Answer 1

The way you've implemented compare is wrong, and would only work if it's called only in a very specific way that you're assuming. However, you have no idea in what context the PriorityQueue actually calls compare. The compare function might well be called on an existing element inside the data structure, instead of the new one, or vice versa.

(Even if you did read the source code and traced it and found that this particular implementation works in a certain way, you shouldn't depend on that if you want your code to be maintainable. At the least, you'd be making yourself more work by having to explain why it works.)

You could just use some sort of counter and assign it as the value for each added item, then implement compare correctly based on the value.

A correct implementation of compare might look like this:

int compare(Object x, Object y){
    return x.getSomeProperty() - y.getSomeProperty();
}

Note that if you switch the order of the parameters, the answer will change as well. No, the int returned does not necessarily have to come from {-1, 0, 1}. The spec calls for 0, or a negative or positive integer. You can use any one you wish, so long as it's the correct sign.