Hi Martin,
Thanks for the review! However, the corner case you mentioned seems to
be related to the design choice of Map::compute(), and it's out of the
scope of this change. What do you think?
Best,
John Lin
Martin Buchholz 於 2020年6月12日 週五 上午11:42寫道：
>
> 林自均, pleased to meet you!
>
> This
林自均, pleased to meet you!
This rewrite seems clear and clean.
Would it be even clearer if we did
if (newValue != null) {
map.put(key, newValue);
} else {
map.remove(key);
}
Hmmm, what about the corner case where the map permits null values and
the old value is null?
On Thu, Jun 11, 2020
Hi all,
This is my first time contribution. Please let me know if I did
something wrong. Thanks. Regards
I'm working on this bug: https://bugs.openjdk.java.net/browse/JDK-8247402
The original problem is that the implementation requirements for
Map::compute() lacks of return statements for some
Hi,
found it: https://bugs.openjdk.java.net/browse/JDK-8237876
Thanks,
Tigran.
- Original Message -
> From: "Daniel Fuchs"
> To: "Sean Mullan" , "Tigran Mkrtchyan"
> , "security-dev"
>
> Cc: "core-libs-dev"
> Sent: Wednesday, June 10, 2020 4:29:36 PM
> Subject: Re: Thread leak by
Hi Andy,
Looks good.
Thanks,
Alexander
On 6/11/20 1:22 PM, Andy Herrick wrote:
Please review the small jpackage test fix at [1] to issue [2].
[1] http://cr.openjdk.java.net/~herrick/8247418/webrev.01/
[2] https://bugs.openjdk.java.net/browse/JDK-8247418
/Andy
Looks good.
Thanks,
Alexander
On 6/11/20 1:19 PM, Andy Herrick wrote:
looks good.
/Andy
On 6/11/2020 1:23 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Restore handling not only Java runtime home but also Java runtime
root directory in `--runtime-image` option on
looks good.
/Andy
On 6/11/2020 1:23 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Restore handling not only Java runtime home but also Java runtime root
directory in `--runtime-image` option on Mac.
The patch also fixes [3] issue as a side effect of moving
Looks good.
- Alexey
On 6/11/2020 4:22 PM, Andy Herrick wrote:
Please review the small jpackage test fix at [1] to issue [2].
[1] http://cr.openjdk.java.net/~herrick/8247418/webrev.01/
[2] https://bugs.openjdk.java.net/browse/JDK-8247418
/Andy
Please review the small jpackage test fix at [1] to issue [2].
[1] http://cr.openjdk.java.net/~herrick/8247418/webrev.01/
[2] https://bugs.openjdk.java.net/browse/JDK-8247418
/Andy
Hi Peter,
I am surprised by the java/net/httpclient failures: these tests
have been quite stable for me. Is your repository up to date?
Or are these maybe failing in timeout, in which case you might
need to increase the timeout factor (-timeout) or lower the
concurrency (-conc). Or maybe you
Hi Roger,
Thanks for your comments.
I am not knowingly changing the required behavior. All I am proposing is
guarding the thread stack walk if it will be a waste of effort. If an
application or framework has its own ClassLoaders, then the guard will fail
and the thread stack will be walked.
The
Daniel,
Thanks for the suggestion to run more tests.
I'm not sure what the criteria for "success" is here.
I have run
$ jtreg-5.0-b01/bin/jtreg \
-verbose:summary -a -ea -esa -agentvm -conc:8 -ignore:quiet -timeout:2 \
-exclude:./test/jdk/ProblemList.txt \
-jdk:${jdk} \
Looks good.
> On 11 Jun 2020, at 18:11, Joe Darcy wrote:
>
> Hi Pavel,
>
> On 6/11/2020 2:54 AM, Pavel Rappo wrote:
>> Joe,
>>
>> There is a typo:
>>
>> *appropriate overloading of {@link java.util.Arrays#equals
>> Arrays.hashCode}.
>>
Please review fix [2] for jpackage bug [1].
Restore handling not only Java runtime home but also Java runtime root
directory in `--runtime-image` option on Mac.
The patch also fixes [3] issue as a side effect of moving functionality
of BasicTest.testJLinkRuntime() function into the new
Hi Pavel,
On 6/11/2020 2:54 AM, Pavel Rappo wrote:
Joe,
There is a typo:
*appropriate overloading of {@link java.util.Arrays#equals Arrays.hashCode}.
^ ~~~^
Since we are in this area, is it possible to rephrase (or at least
thanks for the review,
Vicente
On 6/11/20 4:47 AM, Chris Hegarty wrote:
On 10 Jun 2020, at 23:23, Vicente Romero wrote:
Please review this small change to the API for
java.lang.Class::permittedSubclasses which clarifies that no particular order
of the returned elements should be assumed
Joe,
There is a typo:
*appropriate overloading of {@link java.util.Arrays#equals Arrays.hashCode}.
^ ~~~^
Since we are in this area, is it possible to rephrase (or at least
re-punctuate) the doc comment for
> On 10 Jun 2020, at 23:23, Vicente Romero wrote:
>
> Please review this small change to the API for
> java.lang.Class::permittedSubclasses which clarifies that no particular order
> of the returned elements should be assumed by clients. The related bug is at
> [1], the webrev at [2] and
On 11/06/2020 06:26, Joe Darcy wrote:
Hello,
Please review a number of small updates to the javadoc of
java.lang.annotation.Annotation to address
JDK-8245620: Improve Annotation.annotationType() documentation
The use of Annotation.annotationType() vs calling getClass on an
annotation
19 matches
Mail list logo
