New methods in PriorityQueue

[Roger Riggs]

Hi Julian,

Thanks for facilitating the communication, I probably should have 
dropped you
from the reply as it was intended for the list in general as well as the 
PR submitter.

Thanks, Roger

On 3/4/22 2:08 AM, Julian Waters wrote:
> Hi all,
>
> I apologize for the confusion, it seems like something went awry on my end
> with the mailing lists, since there are apparently now 2 copies of the same
> thread with different names. I guess I'll just go with this one, since the
> technical discussion is going on here.
>
> To clarify, I wasn't the one who created the PR, I'll relay the feedback to
> the author since I'm not really in the position to give any feedback
> myself, given my inexperience with this area of the JDK.
>
> Thank you Stuart and Roger for the replies, have a great day! :)
>
> best regards,
> Julian
>
>
>
> On Fri, Mar 4, 2022 at 1:37 PM Stuart Marks <stuart.marks at oracle.com> wrote:
>
>> 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