I agree with Roger. Let me amplify this.
The general rule for collections that use hashes and comparison methods (such as
HashMap and TreeMap, as well as PriorityQueue) is that one mustn't mutate any
element that resides in such a collection in any way that changes the results of
hashCode, equals, or the comparison method. It's a bad precedent to add APIs that
seem to support such mutation. As Roger said, the supported way of doing this is to
remove, mutate, and then reinsert.
It seems like it might be safe to mutate an element, only temporarily violating the
PQ's invariants until the mutated element is sifted into the correct position.
However, even a "temporary" violation is exceedingly dangerous. If some other
modification is made to the PQ while it's in this state, it could end up permanently
corrupting the PQ.
Managing such a situation would need to be handled exceedingly carefully. As such,
this seems like a highly specialized use case, thus the proposal isn't suitable as a
general-purpose API.
s'marks
On 3/3/22 10:18 AM, Roger Riggs wrote:
Hi Julian,
Modifying the priorities of elements in the PriorityQueue violates the
invariants of the PriorityQueue established at insertion and maintained
at removal by the Comparator.
To maintain the invariant the element should be removed, its priority modified,
and re-inserted.
An API to manually manipulate the order is inconsistent with the design of
PriorityQueue.
Regards, Roger
On 3/3/22 6:59 AM, Jules W. wrote:
Hi all,
A new PR that adds methods to PriorityQueue was created some time ago at
https://github.com/openjdk/jdk/pull/6938 but has no corresponding issue. As
I'm not too familiar with this part of the JDK I'm querying this mailing
list for anyone to properly review the PR before I create an issue for it
in the JBS
best regards,
Julian Waters
