ing
this PR, my motivation was also (1.) that I was curious about the reasons
why they are missing and (2.) about the JDK PR process in general. And this
curiosity has been satisfied.
1.
I was not really aware about the requirements of the API user to
maintain the "invariants of the
oger. 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 comp
r 4, 2022 at 1:37 PM Stuart Marks 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 tha
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
has
mailto:david.hol...@oracle.com>
> <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>>> wrote:
>
> Hi Julian,
>
> On 3/03/2022 10:33 pm, Jules W. wrote:
> > Hi all,
> >
>
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
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 creat
n Thu, Mar 3, 2022 at 8:45 PM David Holmes > <mailto:david.hol...@oracle.com>> wrote:
> >
> > Hi Julian,
> >
> > On 3/03/2022 10:33 pm, Jules W. wrote:
> > > Hi all,
> > >
> > > A new PR that adds methods to
/2022 10:33 pm, 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
<https://github.com/openjdk/jdk/pull/6938> but has no corresponding
issue. As
> I&#
/03/2022 10:33 pm, 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
> On 3/03/2022 10:33 pm, 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 to
Sorry Julian, I see now you were the person aiding the person who
created the PR.
David
On 3/03/2022 10:45 pm, David Holmes wrote:
Hi Julian,
On 3/03/2022 10:33 pm, Jules W. wrote:
Hi all,
A new PR that adds methods to PriorityQueue was created some time ago at
https://github.com/openjdk
Hi Julian,
On 3/03/2022 10:33 pm, 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 mailin
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 creat
I believe the linked sequence of messages refer to the addition of a
PriorityQueue constructor only taking a Comparator which was does appear in
Java 1.8. Did you have a link to something regarding the a constructor
taking a Collection and a Comparator (2 arguments)?
On Thu, May 14, 2015 at 2
On May 15, 2015, at 4:04 PM, Chris Hegarty wrote:
> And/Or should PriorityQueue override addAll and provide a more performant
> implementation for common Collection types ( just like the constructor )?
>
It should be possible to improve this case too: create a new array,
appropriat
>
> I was initially confused by this because it seems to attribute the
> algorithmic difference to Comparable vs Comparator, which doesn't make any
> sense
That's exactly what threw me off as well, but I didn't bother checking
(doh!). Anyway, I think the upside is we're all in agreement now that
Yes, this is very subtle, and Brett mentioned it (albeit somewhat obliquely) in
an email on jdk9-dev: [1]
If someone needs to make a
heap and their data is Comparable, the corresponding constructor gives a
O(n) runtime. If their data uses a Comparator, the corresponding runtime
(using addAll)
Whoops, I believe you're right -- I completely overlooked that as well :(
On Fri, May 15, 2015 at 12:40 PM, Paul Sandoz
wrote:
>
> On May 15, 2015, at 6:15 PM, Louis Wasserman wrote:
>
> > http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for
> > heapifying an unsorted array i
On May 15, 2015, at 6:15 PM, Louis Wasserman wrote:
> http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for
> heapifying an unsorted array in O(n), corroborated elsewhere at
> http://courses.csail.mit.edu/6.006/fall10/handouts/recitation10-8.pdf .
> Any particular reason we can
xt to
potentially optimize.
sent from my phone
On May 15, 2015 10:04 AM, "Chris Hegarty" wrote:
> And/Or should PriorityQueue override addAll and provide a more performant
> implementation for common Collection types ( just like the constructor )?
>
> -Chris.
>
> On 15/05/
And/Or should PriorityQueue override addAll and provide a more
performant implementation for common Collection types ( just like the
constructor )?
-Chris.
On 15/05/15 14:20, Vitaly Davidovich wrote:
Paul,
I don't think you're missing anything obvious (unless I am as well :))
On May 15, 2015, at 3:20 PM, Vitaly Davidovich wrote:
> Paul,
>
> I don't think you're missing anything obvious (unless I am as well :)). What
> you wrote is basically what I meant by creating static helper method in
> Brett's own code that does exactly what you wrote. The asymptotic comple
e class already supports that internally,
seems like a harmless change.
sent from my phone
On May 15, 2015 8:45 AM, "Paul Sandoz" wrote:
>
> On May 14, 2015, at 8:17 AM, Brett Bernstein
> wrote:
>
> > I believe the linked sequence of messages refer to the addition of a
On May 14, 2015, at 8:17 AM, Brett Bernstein wrote:
> I believe the linked sequence of messages refer to the addition of a
> PriorityQueue constructor only taking a Comparator which was does appear in
> Java 1.8. Did you have a link to something regarding the a constructor
&
75-L79
On Thu, May 14, 2015 at 8:21 AM, Martin Buchholz wrote:
> On Wed, May 13, 2015 at 11:17 PM, Brett Bernstein > wrote:
>
>> I believe the linked sequence of messages refer to the addition of a
>> PriorityQueue constructor only taking a Comparator which was does appear in
&
On Wed, May 13, 2015 at 11:17 PM, Brett Bernstein wrote:
> I believe the linked sequence of messages refer to the addition of a
> PriorityQueue constructor only taking a Comparator which was does appear in
> Java 1.8. Did you have a link to something regarding the a constructor
&
Software is hard.
We tried and got stuck, although the former effort can be revived.
RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019124.html
On Wed, May 13, 2015 at 10:17 PM, Brett Bernstein wrote:
> To w
On 07/25/13 10:15, Doug Lea wrote:
On 07/24/13 19:30, Martin Buchholz wrote:
PriorityQueue is unusual in that Doug maintains a copy in jsr166 CVS even though
it is a non-thread-safe collection. I think it makes sense,
because PriorityQueue and PriorityBlockingQueue have parallel APIs and
Changeset: f056728871f8
Author:mduigou
Date: 2013-07-26 17:23 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f056728871f8
8021601: Add unit test for PriorityQueue(Comparator) constructor
Reviewed-by: darcy, alanb
! src/share/classes/java/util/PriorityQueue.java
! test/java
On 26/07/2013 17:06, Mike Duigou wrote:
Hello all;
JDK-6799426 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b) was
pushed without a unit test. (Always recheck for unit tests when breathing life
back into a stale old patch). A unit test is needed. This change adds an
additional case
Looks good Mike; cheers,
-Joe
On 7/26/2013 5:06 PM, Mike Duigou wrote:
Hello all;
JDK-6799426 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b) was
pushed without a unit test. (Always recheck for unit tests when breathing life
back into a stale old patch). A unit test is needed. This
Hello all;
JDK-6799426 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b) was
pushed without a unit test. (Always recheck for unit tests when breathing life
back into a stale old patch). A unit test is needed. This change adds an
additional case to an existing test to exercise the new co
On 07/24/13 19:30, Martin Buchholz wrote:
PriorityQueue is unusual in that Doug maintains a copy in jsr166 CVS even though
it is a non-thread-safe collection. I think it makes sense,
because PriorityQueue and PriorityBlockingQueue have parallel APIs and parallel
implementations. Many changes
Yes, and there should be. I will open an issue.
Mike
On Jul 23 2013, at 17:26 , Alan Bateman wrote:
> On 22/07/2013 12:24, Mike Duigou wrote:
>> Hello all;
>>
>> A simple rewiew for the addition of another constructor to PriorityQueue.
>> Currently if you wish to sp
On 22/07/2013 12:24, Mike Duigou wrote:
Hello all;
A simple rewiew for the addition of another constructor to PriorityQueue.
Currently if you wish to specify a Comparator you must also supply a size. This
addition allows use of the default size which is good for two reason; you don't
ha
m the previous constructor, but both
> sound a bit awkward. Both can probably benefit from an improvement.
>
> Currently:
> "Creates a {@code PriorityQueue} with the default initial capacity that
> orders its elements according to the specified comparator."
>
> Depending on
Changeset: a6cbb9808e4b
Author:mduigou
Date: 2013-07-22 12:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6cbb9808e4b
6799426: Adds constructor PriorityQueue(Comparator)
Reviewed-by: lancea
! src/share/classes/java/util/PriorityQueue.java
Mike,
I know the description is pulled from the previous constructor, but both
sound a bit awkward. Both can probably benefit from an improvement.
Currently:
"Creates a {@code PriorityQueue} with the default initial capacity that
orders its elements according to the specified compa
On 22/07/2013 20:24, Mike Duigou wrote:
Hello all;
A simple rewiew for the addition of another constructor to PriorityQueue.
Currently if you wish to specify a Comparator you must also supply a size. This
addition allows use of the default size which is good for two reason; you don't
ha
On 07/22/2013 09:42 PM, Lance Andersen - Oracle wrote:
looks fine Mike
Best
Lance
Yes, fine for me too.
Rémi
On Jul 22, 2013, at 3:24 PM, Mike Duigou wrote:
Hello all;
A simple rewiew for the addition of another constructor to PriorityQueue.
Currently if you wish to specify a Comparator
looks fine Mike
Best
Lance
On Jul 22, 2013, at 3:24 PM, Mike Duigou wrote:
> Hello all;
>
> A simple rewiew for the addition of another constructor to PriorityQueue.
> Currently if you wish to specify a Comparator you must also supply a size.
> This addition allows use of t
Hello all;
A simple rewiew for the addition of another constructor to PriorityQueue.
Currently if you wish to specify a Comparator you must also supply a size. This
addition allows use of the default size which is good for two reason; you don't
have to specify a fixed value an
r reference.
>
> Thanks.
>
>> Just one minor observation while reviewing the changes. Is it necessary
>> for initFromPriorityQueue to call initFromCollection ( in the case where
>> you're given a PriorityQueue subclass), or can it simply call
>> initElementsFromCollect
anges. Is it
necessary for initFromPriorityQueue to call initFromCollection ( in
the case where you're given a PriorityQueue subclass), or can it
simply call initElementsFromCollection?
It's possible that the subclass overrides toArray to return an array
that doesn't preserve the inte
Queue to call initFromCollection ( in the case where
you're given a PriorityQueue subclass), or can it simply call
initElementsFromCollection?
It's possible that the subclass overrides toArray to return an array
that doesn't preserve the internal order. Hence we nee
re given a PriorityQueue subclass), or can it simply call
initElementsFromCollection?
-Chris.
On 07/05/2010 03:37, David Holmes wrote:
Hi Martin,
CR 6950540 filed. (Chris might want to tidy it up :) )
Changes look okay to me.
Thanks,
David
Martin Buchholz said the following on 05/07/10 12:19:
arator might accept nulls.
True but a Comparator is only used if the Collection is a SortedSet or a
PriorityQueue. For any other Collection the elements must implement
Comparable and the code in:
private void siftDownComparable(int k, E x) {
Comparable key = (Comparable)x;
int half = s
/webrevs/openjdk7/PriorityQueueConstructor/
>>>
>>> I'm not sure this is necessarily the right fix. It seems to me that
>>> incidental nulls will be caught in many/most cases by the sorting code
>>> for
>>> collections assumed to contain Comparable
ll be caught in many/most cases by the sorting code for
collections assumed to contain Comparable's.
The comparator might accept nulls.
True but a Comparator is only used if the Collection is a SortedSet or a
PriorityQueue. For any other Collection the elements must implement
Comparable an
> And we don't need to check when
> filling from an existing PriorityQueue.
Strictly speaking, the source PriorityQueue might be a subclass that
has been modified to accept nulls.
But yes, we could have a version of the fix that only checks for nulls
if the source is not a PQ.
> So is it
Martin,
Martin Buchholz said the following on 05/07/10 08:24:
This is a bug report with fix.
(Chris, please file a bug)
Summary: PriorityQueue(collection) should throw NPE if collection
contains a null
Description:
PriorityQueue spec says:
"A priority queue does not permit {...@code
This is a bug report with fix.
(Chris, please file a bug)
Summary: PriorityQueue(collection) should throw NPE if collection
contains a null
Description:
PriorityQueue spec says:
"A priority queue does not permit {...@code null} elements."
but the constructor taking a collectio
53 matches
Mail list logo
