of itself, in the
same sense that unmodifiable collections are views of an underlying collection?
Alan
On Apr 30, 2021, at 3:42 PM, Stuart Marks wrote:
Consider the case of a large application or other system, one that's large
enough to have lots of internal APIs, but that is built as a singl
On Sat, 24 Apr 2021 01:32:45 GMT, Tagir F. Valeev wrote:
>> I decided to show a complete static method in the example, so it could be
>> copied to user utility class as is. Not sure if it's reasonable to add
>> `assert cls.isRecord();` there. Also I don't know whether there's a
>> limitation
You did not really answer to the real question, why should i use
ReversibleCollection instead of a Collection as parameter.
You said that it's a better type because you can not send a HashSet, but as i
said, sending a HashSet of 0 or 1 element is perfectly valid.
For me, we are not far
the offerX methods -- but I'll leave the proposal as it
stands regarding add{First,Last} methods.
s'marks
On 4/28/21 6:54 AM, Peter Levart wrote:
On 4/28/21 7:19 AM, Stuart Marks wrote:
On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
On Tuesday, April 27, 2021 11:25 CEST, Peter Levart
Hi Henri,
I've changed the subject of this thread because I think it's out of scope of the
ReversibleCollection proposal. I don't mean to say that we can't talk about it, but
I would like it to be decoupled from ReversibleCollection. I'm somewhat arbitrarily
calling it "Collection::getAny"
(Catching up on old email threads.)
I don't have much to add to the technical discussion here. Yes, caching the Integer
instances seems obsolescent, and it seems unlikely that caching String conversions
will be helpful. I've gone ahead and closed out the bug. [1]
On triaging bugs... we do
On 4/27/21 9:17 AM, Anthony Vanelverdinghe wrote:
On Tuesday, April 27, 2021 11:25 CEST, Peter Levart
wrote:
Now just some of my thoughts about the proposal:
- SortedSet.addFirst/.addLast - I think an operation that would be used
in situations like: "I know this element should always be
On 4/27/21 2:25 AM, Peter Levart wrote:
Right, I'm persuaded. Now if only the problems of transition to the usage of new
type that Remi is worried about were mild enough. Source (in)compatibility is not
that important if workarounds exist that are also backwards source compatible so
that
On 4/25/21 11:09 AM, Peter Levart wrote:
When making this proposition, I was only thinking of how to enable new
yet-nonexistent operations on collections that have order / are reversible and that
the code calling these methods would already knows that it is dealing with ordered /
reversible
An API can not use ReversibleCollection as parameter before all the
implementations of Collection that have an ordering are updated to implement
ReversibleCollection instead of Collection.
By example, if I add a method
public void foo(ReversibleCollection c)
in my library, people that want
On 4/22/21 8:36 AM, Stephen Colebourne wrote:
On Thu, 22 Apr 2021 at 13:58, Remi Forax wrote:
I would like to preserve the invariant that, when calling a method on a
Collection/iterator, an UnsupportedOperationException only occurs when trying
to mutate that collection.
If we are ok with
On Wed, 21 Apr 2021 13:13:16 GMT, Jim Laskey wrote:
>> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
>
> Jim Laskey has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by
On 4/19/21 2:01 PM, Remi Forax wrote:
- Mail original -
Thinking a little bit about your proposal,
introducing an interface right in the middle of a hierarchy is not a backward
compatible change
(you have an issue when the compiler has to use the lowest upper bound).
By example
On 4/19/21 4:05 PM, fo...@univ-mlv.fr wrote:
* There's a useful clump of semantics here, combined with sensible operations
that
rely on those semantics. There are a lot of places in the spec where there is
hedging of the form "if the collection has an ordering, then... otherwise the
On Mon, 19 Apr 2021 22:12:30 GMT, Ian Graves wrote:
>> Clarifying note on comments mode to explicitly note that whitespace within
>> character classes is ignored.
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Adding
On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves wrote:
>> This fixes a bug where the formatting code for `%g` flags incorrectly tries
>> to round `BigDecimal` after determining whether it should be a decimal
>> numeric format or a scientific numeric format. The solution rounds before
>>
On Sat, 17 Apr 2021 08:55:59 GMT, Tagir F. Valeev wrote:
> I decided to show a complete static method in the example, so it could be
> copied to user utility class as is. Not sure if it's reasonable to add
> `assert cls.isRecord();` there. Also I don't know whether there's a
> limitation on
On 4/17/21 9:49 AM, Remi Forax wrote:
I think the analysis is spot on but I don't think the proposed solution is the
right one.
Introducing a new interface (two in this case) has a really huge cost and in
this case, i've trouble to see why i will want to write a method that takes a
On 4/17/21 4:49 AM, Tagir Valeev wrote:
Great proposal, thanks!
It has most functionality from my previous proposal, except the
ability to iterate LinkedHashSet starting from a specific element.
Well, probably we can skip this for now.
Thanks! And thanks for making that proposal a year
On 4/17/21 2:48 AM, Stephen Colebourne wrote:
On Fri, 16 Apr 2021 at 18:41, Stuart Marks wrote:
This is a proposal to add a ReversibleCollection interface to the Collections
Framework. I'm looking for comments on overall design before I work on detailed
specifications and tests. Please send
On 4/16/21 3:06 PM, Donald Raab wrote:
We should be cautious when adding new APIs to existing interfaces. There may be
libraries which extend JDK types and already have reversed(), toReversed() or
asReversed() APIs and corresponding interfaces.
There are OrderedIterable and
This is a proposal to add a ReversibleCollection interface to the Collections
Framework. I'm looking for comments on overall design before I work on detailed
specifications and tests. Please send such comments as replies on this email thread.
Here's a link to a draft PR that contains the code
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
Marked as reviewed by smarks (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3182
On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy wrote:
> 8264148: Update spec for exceptions retrofitted for exception chaining
The removal of the obsolescent "As of release 1.4, this exception has been
retrofitted..." is good. Changing the calls from the other exception-getting
methods to
On Tue, 9 Mar 2021 23:38:26 GMT, Joe Darcy wrote:
>> The existing documentation of Method.isBridge isn't terribly helpful to the
>> reader. This RFE proposes to given a common example of how bridge methods
>> are used. The JLS does *not* have a section discussing bridge methods in
>> detail;
On Tue, 9 Mar 2021 19:51:42 GMT, Stuart Marks wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to review feedback.
>
> src/java.base/share/classes/java/lang/reflect/M
On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy wrote:
>> The existing documentation of Method.isBridge isn't terribly helpful to the
>> reader. This RFE proposes to given a common example of how bridge methods
>> are used. The JLS does *not* have a section discussing bridge methods in
>> detail;
On Tue, 9 Mar 2021 19:13:24 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/reflect/Method.java line 589:
>>
>>> 587: * different return type, the virtual machine does not.
>>> 588: * A
>>> 589: * common case where covariant overrides are used is for a {@link
>>
On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy wrote:
>> The existing documentation of Method.isBridge isn't terribly helpful to the
>> reader. This RFE proposes to given a common example of how bridge methods
>> are used. The JLS does *not* have a section discussing bridge methods in
>> detail;
On Sat, 6 Mar 2021 17:44:18 GMT, Joe Darcy wrote:
>> The existing documentation of Method.isBridge isn't terribly helpful to the
>> reader. This RFE proposes to given a common example of how bridge methods
>> are used. The JLS does *not* have a section discussing bridge methods in
>> detail;
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.io`,
> `java.math`, and `java.text` packages to make use of the `instanceof` pattern
> variable?
>
> Kind regards,
> Patrick
Marked as reviewed by
On Thu, 4 Mar 2021 04:13:12 GMT, Ian Graves wrote:
>> Modify the `unmodifiable*` methods in `java.util.Collections` to be
>> idempotent. That is, when given an immutable collection from
>> `java.util.ImmutableCollections` or `java.util.Collections`, these methods
>> will return the reference
On Fri, 26 Feb 2021 21:37:14 GMT, Stuart Marks wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test refactoring. Adding implNote to modified methods
>
> The `@implNote` additions are go
On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy wrote:
> I considered @stuart-marks previous suggestion during the code review of
> JDK-8261123 to include a more explicit discussion of why, say, different
> representations of 2 should not be regarded as equivalent. After
> contempla
On Fri, 4 Dec 2020 06:50:14 GMT, Stuart Marks wrote:
> This rewrites the doc of ArraysSupport.newLength, adds detail to the
> exception message, and adds a test. In addition to some renaming and a bit of
> refactoring of the actual code, I also made two changes of substance to th
On Tue, 2 Mar 2021 15:05:51 GMT, Pavel Rappo wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year.
>
> src/java.base/share/classes/jdk/internal/util/ArraysSu
mit was exceeded. Instead, if the
> required length is in this range, this method returns that required length.
>
> Separately, I'll work on retrofitting various call sites around the JDK to
> use this method.
Stuart Marks has updated the pull request incrementally with one additional
c
mit was exceeded. Instead, if the
> required length is in this range, this method returns that required length.
>
> Separately, I'll work on retrofitting various call sites around the JDK to
> use this method.
Stuart Marks has updated the pull request incrementally with one additional
mit was exceeded. Instead, if the
> required length is in this range, this method returns that required length.
>
> Separately, I'll work on retrofitting various call sites around the JDK to
> use this method.
Stuart Marks has updated the pull request incrementally with one addition
mit was exceeded. Instead, if the
> required length is in this range, this method returns that required length.
>
> Separately, I'll work on retrofitting various call sites around the JDK to
> use this method.
Stuart Marks has updated the pull request incrementally with
On Fri, 26 Feb 2021 20:15:19 GMT, Ian Graves wrote:
>> Modify the `unmodifiable*` methods in `java.util.Collections` to be
>> idempotent. That is, when given an immutable collection from
>> `java.util.ImmutableCollections` or `java.util.Collections`, these methods
>> will return the reference
On Fri, 12 Feb 2021 20:27:00 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my changeset for JDK-8252399: 'Update mapMulti
>> documentation to use type test pattern instead of instanceof once JEP 375
>> exits preview' ?
>>
>> This change updates the example code
On Tue, 23 Feb 2021 23:32:01 GMT, Stuart Marks wrote:
>>> > Is there any behavior change here that merits a CSR review?
>>>
>>> Maybe. The one observable change is that calling `Collections.bar(foo)`
>>> with a `foo` that is already a `ba
On Tue, 23 Feb 2021 16:27:06 GMT, Ian Graves wrote:
> Is there any behavior change here that merits a CSR review?
Yes. See my comments in the bug report:
On Fri, 19 Feb 2021 01:52:51 GMT, liach
wrote:
>> Maybe it is not correct for UnmodifiableEntrySet::contains to short circuit?
>> What if the implementation was changed to:
>>
>> `public boolean contains(Object o) {
>> if (!(o instanceof Map.Entry))
>> return
On Fri, 12 Feb 2021 22:52:06 GMT, Joe Darcy wrote:
>> A follow-up of sorts to JDK-8257086, this change aims to improve the
>> discussion of the relationship between Object.equals and compareTo and
>> compare methods. The not-consistent-with-equals natural ordering of
>> BigDecimal get more
On Fri, 12 Feb 2021 22:12:30 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/Comparable.java line 90:
>>
>>> 88: * of the {@code equals} method and the equivalence classes defined by
>>> 89: * the quotient of the {@code compareTo} method are the same.
>>> 90: *
>>
>> I think
On Wed, 3 Feb 2021 22:42:00 GMT, Ian Graves wrote:
> Updating the specification to reflect well-established behavior in Formatter
> when incorrect flags used for `%`.
Marked as reviewed by smarks (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2389
On Thu, 11 Feb 2021 04:24:40 GMT, Stuart Marks wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix typos in javadoc tags found during review.
>
> src/java.base/share/classes/jav
On Wed, 10 Feb 2021 01:49:55 GMT, Joe Darcy wrote:
>> A follow-up of sorts to JDK-8257086, this change aims to improve the
>> discussion of the relationship between Object.equals and compareTo and
>> compare methods. The not-consistent-with-equals natural ordering of
>> BigDecimal get more
On Wed, 10 Feb 2021 02:55:14 GMT, Brian Burkhalter wrote:
>> This is the exact text recommended in java.lang.Comparable when a type's
>> natural ordering is inconsistent with equals. The statement to that effect
>> at the top of BigDecimal didn't use that exact wording
>
> Okay, I see.
The
On Thu, 4 Feb 2021 22:45:10 GMT, Ian Graves wrote:
> A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).
> This is an enhancement to update jlink's usage of `Collections.toList()` to
> `Stream.toList()`.
Aside from the simplification issues, the Collectors.toList() =>
On Sat, 30 Jan 2021 01:58:02 GMT, Joe Darcy wrote:
>> Updates to the specifications of Double.{equals, compareTo} to explain more
>> explicitly why the obvious wrappers around "==" and "<"/"==" are not
>> sufficient for floating-point values.
>>
>> Once the wording is worked out, I'll
Indeed it's the case that a varargs method can't determine whether it was called
with several explicit arguments or whether it was called with an array. However,
that doesn't have any bearing on whether or not Set.of rejects duplicates.
The model for Set.of is to support a
On Fri, 29 Jan 2021 17:31:09 GMT, Joe Darcy wrote:
>> Updates to the specifications of Double.{equals, compareTo} to explain more
>> explicitly why the obvious wrappers around "==" and "<"/"==" are not
>> sufficient for floating-point values.
>>
>> Once the wording is worked out, I'll
On Thu, 28 Jan 2021 07:15:05 GMT, Joe Darcy wrote:
>> Great, let me know if you'd like me to provide some text for any particular
>> topics in this area.
>
>>
>>
>> Great, let me know if you'd like me to provide some text for any particular
>> topics in this area.
>
> Before sending out
On Wed, 27 Jan 2021 03:18:09 GMT, Stuart Marks wrote:
> Fix a typo, and change an example to use Stream.toList().
This pull request has now been integrated.
Changeset: eb923685
Author: Stuart Marks
URL: https://git.openjdk.java.net/jdk/commit/eb923685
Stats: 3 lines in 1 f
Fix a typo, and change an example to use Stream.toList().
-
Commit messages:
- 8259816: Typo in java.util.stream package description
Changes: https://git.openjdk.java.net/jdk/pull/2249/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2249=00
Issue:
On Fri, 22 Jan 2021 05:39:55 GMT, Stuart Marks wrote:
> Tighten up argument checking in constructor.
This pull request has now been integrated.
Changeset: a8871776
Author: Stuart Marks
URL: https://git.openjdk.java.net/jdk/commit/a8871776
Stats: 90 lines in 2 files changed:
On Fri, 22 Jan 2021 17:12:34 GMT, Daniel Fuchs wrote:
>> Or even maybe `rulesArray =
>> lastRules.toArray(ZoneOffsetTransitionRule[]::new);`?
>
> Good point - but that would be:
>
> ZoneOffsetTransitionRule[] rulesArray =
> lastRules.toArray(ZoneOffsetTransitionRule[]::new).clone();
Tighten up argument checking in constructor.
-
Commit messages:
- 8246788: ZoneRules invariants can be broken
Changes: https://git.openjdk.java.net/jdk/pull/2191/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2191=00
Issue:
On Wed, 13 Jan 2021 09:51:01 GMT, Tagir F. Valeev wrote:
> Handle TreeMap::computeIfAbsent when previous mapping with null value existed
> (in this case spec requires to overwrite the existing mapping)
Marked as reviewed by smarks (Reviewer).
-
PR:
On Thu, 14 Jan 2021 23:25:22 GMT, Stuart Marks wrote:
>> Handle TreeMap::computeIfAbsent when previous mapping with null value
>> existed (in this case spec requires to overwrite the existing mapping)
>
> Marked as reviewed by smarks (Reviewer).
Thanks for picking this up.
Thanks for filing this!
Tagir Valeev picked this up and has filed a PR:
https://git.openjdk.java.net/jdk/pull/2058
s'marks
On 1/11/21 10:05 AM, Phil Smith wrote:
Hello, I submitted bug report 9068554 recently, but I consider this a
pretty big issue and I'd like for this not to get lost in
On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks wrote:
> Just fixing a broken link.
This pull request has now been integrated.
Changeset: 8a81cf15
Author: Stuart Marks
URL: https://git.openjdk.java.net/jdk16/commit/8a81cf15
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2
Just fixing a broken link.
-
Commit messages:
- 8259298: broken link in Stream::toList spec
Changes: https://git.openjdk.java.net/jdk16/pull/106/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=106=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8259298
Stats: 2
On Fri, 18 Dec 2020 19:04:36 GMT, Sean Mullan wrote:
>>> MD5 and DES were removed as SE requirements in JDK 14. See
>>> https://bugs.openjdk.java.net/browse/JDK-8214483 for more information.
>>> However, there are no plans to remove the implementations from the JDK at
>>> this time.
>>
>> In
On 12/8/20 5:30 AM, Remi Forax wrote:
De: "Dave Franken"
Adding methods like notContains or notFilter have been considered several times
in the past and rejected because it's too many methods with no real gain. I'm
sure you can dig some old emails on lambda-dev and see the first iteration
On Thu, 17 Dec 2020 01:01:38 GMT, Stuart Marks wrote:
> Back out code changes from JDK-8235812 to restore correct matching behavior.
> Adjust test to comment out cases that tested for incorrect behavior.
This pull request has now been integrated.
Changeset: cbc3feeb
Author:Stuart
On Wed, 16 Dec 2020 17:16:14 GMT, Brian Burkhalter wrote:
>> Please review this small verbiage change to specify clearly the behavior of
>> `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of
>> `Reader::read(char[] cbuf, int off, int len)` when `len` is zero.
>
> Brian
Back out code changes from JDK-8235812 to restore correct matching behavior.
Adjust test to comment out cases that tested for incorrect behavior.
-
Commit messages:
- 8258259: Unicode linebreak matching behavior is incorrect; backout
JDK-8235812
Changes:
On Wed, 9 Dec 2020 00:32:44 GMT, Paul Sandoz wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix typo, clarify asserts disabled, test prefGrowth==0
>
> Marked as reviewed by psandoz
On Wed, 16 Dec 2020 20:08:11 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as
On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as
On Thu, 10 Dec 2020 23:36:13 GMT, Brian Burkhalter wrote:
>> Please review this small verbiage change to specify clearly the behavior of
>> `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of
>> `Reader::read(char[] cbuf, int off, int len)` when `len` is zero.
>
> Brian
On Tue, 15 Dec 2020 09:17:03 GMT, Magnus Ihse Bursie wrote:
>> Your call, I'm not a native English speaker :-) It felt to me it's
>> 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a
>> restrictive allow-list.
>
> It's an adverb, since it's the act of 'defining' that is
On Sun, 4 Oct 2020 11:55:50 GMT, Andrey Turbanov
wrote:
>> 8258422: Cleanup unnecessary null comparison before instanceof check in
>> java.base
>
> I believe this changes is useful and still actual:
> 1. improve code to make it easier to read.
> 2. performance should be improved a bit too
On Tue, 8 Dec 2020 22:12:29 GMT, Joe Darcy wrote:
>> I'll note initially that the original bug is about `equals` and `==` whereas
>> this change also covers `compareTo` and additional comparison operators `<`
>> and `>`. I believe covering this additional material **IS** important, as
>>
On Tue, 8 Dec 2020 16:29:49 GMT, Joe Darcy wrote:
> Updates to the specifications of Double.{equals, compareTo} to explain more
> explicitly why the obvious wrappers around "==" and "<"/"==" are not
> sufficient for floating-point values.
>
> Once the wording is worked out, I'll replicate it
mit was exceeded. Instead, if the
> required length is in this range, this method returns that required length.
>
> Separately, I'll work on retrofitting various call sites around the JDK to
> use this method.
Stuart Marks has updated the pull request incrementally with one additional
com
!I3YBH6KonWfqm4zW7pQRatPsLcj4rRjGOveB6NWQedZVU8BeJ3hknZcPy7rC1G2fug$
).
Cheers,
Cay
Il 04/12/2020 19:53, Stuart Marks ha scritto:
Hi Cay,
Thanks for mentioning this. It's good to know that adding this provides value to
people who are actually trying to use this stuff (as opposed to adding
On Mon, 7 Dec 2020 16:05:11 GMT, Roger Riggs wrote:
>> The origin of this code is in collections like ArrayList that have an
>> existing array (hence oldLength >= 0) and that need it to grow (hence
>> minGrowth > 0). Those were the prevailing assumptions in the code from which
>> this was
On Fri, 4 Dec 2020 16:02:33 GMT, Roger Riggs wrote:
>> This rewrites the doc of ArraysSupport.newLength, adds detail to the
>> exception message, and adds a test. In addition to some renaming and a bit
>> of refactoring of the actual code, I also made two changes of substance to
>> the code:
On Fri, 4 Dec 2020 19:13:45 GMT, Roger Riggs wrote:
>> The preconditions aren't checked, because this is an internal method, and
>> the code size is minimized in order to help inlining. That's also why
>> `hugeLength` is a separate method. (I guess I could add comments to this
>> effect.)
Hi Cay,
Thanks for mentioning this. It's good to know that adding this provides value to
people who are actually trying to use this stuff (as opposed to adding stuff merely
for the sake of completeness, as often seems to arise).
I've added some notes to JDK-8065554.
Looking at this more
On Fri, 4 Dec 2020 15:53:01 GMT, Roger Riggs wrote:
>> This rewrites the doc of ArraysSupport.newLength, adds detail to the
>> exception message, and adds a test. In addition to some renaming and a bit
>> of refactoring of the actual code, I also made two changes of substance to
>> the code:
On Fri, 4 Dec 2020 15:47:51 GMT, Roger Riggs wrote:
>> This rewrites the doc of ArraysSupport.newLength, adds detail to the
>> exception message, and adds a test. In addition to some renaming and a bit
>> of refactoring of the actual code, I also made two changes of substance to
>> the code:
Hi Martin,
I'd appreciate it if you could take a look at this.
Thanks,
s'marks
On 12/3/20 10:57 PM, Stuart Marks wrote:
This rewrites the doc of ArraysSupport.newLength, adds detail to the exception
message, and adds a test. In addition to some renaming and a bit of refactoring
This rewrites the doc of ArraysSupport.newLength, adds detail to the exception
message, and adds a test. In addition to some renaming and a bit of refactoring
of the actual code, I also made two changes of substance to the code:
1. I fixed a problem with overflow checking. In the original code,
On Sat, 28 Nov 2020 08:42:52 GMT, John Lin
wrote:
>> @johnlinp In any case, you'd also need to update the surrounding prose; we
>> need to remove this:
>> returning the current value or {@code null} if absent:```
>
> @pavelrappo Please see my updated CSR below. Thanks.
>
> # Map::compute
On Mon, 30 Nov 2020 15:08:51 GMT, Pavel Rappo wrote:
>> @johnlinp, thanks for updating the CSR draft; it is much better now.
>>
>> @stuart-marks, I think we could further improve this snippet. This `if`
>> statement seems to use an optimization:
>>
>> if
On Thu, 3 Dec 2020 01:08:18 GMT, Stuart Marks wrote:
> Some small doc changes. The changes are to `@apiNote` text, which is
> non-normative, so no CSR is required.
This pull request has now been integrated.
Changeset: 2b73f992
Author:Stuart Marks
URL: https://git.openjdk.ja
Some small doc changes. The changes are to `@apiNote` text, which is
non-normative, so no CSR is required.
-
Commit messages:
- 8228615: Optional.empty() doc should suggest isEmpty() instead of isPresent()
Changes: https://git.openjdk.java.net/jdk/pull/1585/files
Webrev:
On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks wrote:
> This change introduces a new terminal operation on Stream. This looks like a
> convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> met
On Wed, 25 Nov 2020 17:14:43 GMT, Peter Levart wrote:
>> An alternative with similar performance would be to do a Stream.toArray()
>> and then copy that array into new Object[] and then wrap that copy with
>> listFromTrustedArrayNullsAllowed(). The difference would be in the
>> serialization
On Wed, 25 Nov 2020 16:39:20 GMT, Pavel Rappo wrote:
>> @pavelrappo Please see my proposed CSR below. Thank you.
>>
>> # Map::compute should have a clearer implementation requirement.
>>
>> ## Summary
>>
>> java.util.Map::compute should have a clearer implementation requirement in
>> its
On 11/18/20 3:55 AM, Florian Weimer wrote:
I think it's also needed for an efficient null element check in
List::copyOf. I have a hunch that with the posted implementation, it
would incorrectly produce an immutable list that contains null
elements.
(Sorry for the delay; oddly, this comment
On Tue, 24 Nov 2020 02:19:34 GMT, Pavel Rappo wrote:
> 2. Both the proposed pseudo-code and the existing pseudo-code deviate from
> the documented behaviour (written in prose) and the actual implementation.
Let me clarify something. The "documented behavior" is actually the API
specification,
On Sun, 22 Nov 2020 16:00:45 GMT, Alan Bateman wrote:
>> This change terminally deprecates the following methods defined by
>> java.lang.ThreadGroup
>>
>> - stop
>> - destroy
>> - isDestroyed
>> - setDaemon
>> - isDaemon
>>
>> The stop method has been deprecated since=1.2 because it is
onvenient (if the caller can deal with
> what this operation returns), as collecting into a List is the most common
> stream terminal operation.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Add comment and assert regarding
201 - 300 of 1347 matches
Mail list logo
