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 PriorityQueue" while usin
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
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 that resides in such a
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
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,
> >
> > A new PR that adds m
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
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
t 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 PriorityQueue was
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'm n
022 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
> 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 fam
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 mailing
list
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
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 chris.hega...@oracle.com 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
On May 15, 2015, at 3:20 PM, Vitaly Davidovich vita...@gmail.com 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
On May 14, 2015, at 8:17 AM, Brett Bernstein brett.bernst...@gmail.com 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
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 paul.san...@oracle.com
wrote:
On May 15, 2015, at 6:15 PM, Louis Wasserman lowas...@google.com wrote:
http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm
On May 15, 2015, at 6:15 PM, Louis Wasserman lowas...@google.com 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
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
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 brett.bernst
On Wed, May 13, 2015 at 11:17 PM, Brett Bernstein brett.bernst...@gmail.com
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
On Thu, May 14, 2015 at 8:21 AM, Martin Buchholz marti...@google.com wrote:
On Wed, May 13, 2015 at 11:17 PM, Brett Bernstein brett.bernst...@gmail.com
wrote:
I believe the linked sequence of messages refer to the addition of a
PriorityQueue constructor only taking a Comparator which was does
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
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
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.
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
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 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 specify a Comparator you must also
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
have
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
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 the default size which
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
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
have
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 comparator
, 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 one's spoken emphasis, it can sound as if the capacity
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:
David
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 need to re-sort,
hence
. 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 internal order. Hence we
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
initElementsFromCollection?
It's possible that the subclass overrides toArray to return an array
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 collection does not enforce
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 null
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 only the case for filling
from a SortedSet that needs the explicit
that
incidental nulls will 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
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'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
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 and the code in:
private void siftDownComparable(int k, E x) {
Comparable? super E key
49 matches
Mail list logo
