New methods in PriorityQueue

[Stuart Marks]

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
>