Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10

2021-01-14 Thread Leo Jiang
On Thu, 14 Jan 2021 14:00:00 GMT, Leo Jiang wrote: > This is the changes for JDK 16 msg drop 10. [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) Since they're Unicode escape sequences in the l10n resource files, so I attached a human readable webrev, created by

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

2021-01-14 Thread Peter Levart
On Fri, 8 Jan 2021 11:39:17 GMT, Peter Levart wrote: >> Hi @stsypanov, >> >>> The **behavior** of this convenience method is **identical** to that of >>> c.addAll(Arrays.asList(elements)) >> >> What about: >> >>> The **behaviour** of this convenience method is **similar** to that of >>>

Re: [jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException

2021-01-14 Thread Kezhu Wang
On Sun, 13 Dec 2020 03:31:44 GMT, Martin Buchholz wrote: > 8254350: CompletableFuture.get may swallow InterruptedException @Martin-Buchholz @DougLea @AlanBateman Sorry for rough in. After change `future.get()` to `future.get(1, TimeUnit.DAYS)`, `SwallowedInterruptedException` failed.

[jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10

2021-01-14 Thread Leo Jiang
This is the changes for JDK 16 msg drop 10. - Commit messages: - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 Changes: https://git.openjdk.java.net/jdk16/pull/123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=123=00 Issue:

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

2021-01-14 Thread Leo Jiang
> This is the changes for JDK 16 msg drop 10. Leo Jiang 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 the merge/rebase. The pull request contains two additional commits since the last

Re: RFR: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Erik Joelsson
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort 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

Re: RFR: 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result

2021-01-14 Thread Alan Bateman
On Wed, 13 Jan 2021 18:41:05 GMT, Naoto Sato wrote: > Please review the fix to this issue. Unused thread local StringCoding.Result > is now wrapped with SoftReference, which can be GC'ed as needed. I confirmed > it worked as expected with a test case >

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v6]

2021-01-14 Thread Сергей Цыпанов
> Hello, I feel like this was previously discussed in > https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot > find original mail I post this here. > > Currently `Collections.addAll()` is implemented and documented as: > /** > * ... > * The behavior of this

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

2021-01-14 Thread Сергей Цыпанов
On Fri, 8 Jan 2021 11:39:17 GMT, Peter Levart wrote: >> Hi @stsypanov, >> >>> The **behavior** of this convenience method is **identical** to that of >>> c.addAll(Arrays.asList(elements)) >> >> What about: >> >>> The **behaviour** of this convenience method is **similar** to that of >>>

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

2021-01-14 Thread Сергей Цыпанов
On Thu, 14 Jan 2021 10:18:23 GMT, Peter Levart wrote: >> ...but we could employ this method to guarantee more than >> `c.addAll(Arrays.asList(elements))` does. So what about: >> >>> The behaviour of this convenience method is similar to that of >>>

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10

2021-01-14 Thread Leo Jiang
On Thu, 14 Jan 2021 14:10:12 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > [webrev.tar.gz](https://github.com/openjdk/jdk16/files/5814846/webrev.tar.gz) > > Since they're Unicode escape sequences in the l10n resource files, so I > attached a human readable webrev,

Integrated: 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result

2021-01-14 Thread Naoto Sato
On Wed, 13 Jan 2021 18:41:05 GMT, Naoto Sato wrote: > Please review the fix to this issue. Unused thread local StringCoding.Result > is now wrapped with SoftReference, which can be GC'ed as needed. I confirmed > it worked as expected with a test case >

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

2021-01-14 Thread Naoto Sato
On Thu, 14 Jan 2021 14:27:25 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > Leo Jiang 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 the merge/rebase. The pull

Re: RFR: 8253866: Security Libs Terminology Refresh [v2]

2021-01-14 Thread Jamil Nimeh
> This is the security libs portion of the effort 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 follows: > > - blacklisted.certs -> blocked.certs (along

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v7]

2021-01-14 Thread Сергей Цыпанов
> Hello, I feel like this was previously discussed in > https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot > find original mail I post this here. > > Currently `Collections.addAll()` is implemented and documented as: > /** > * ... > * The behavior of this

Re: RFR: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Sean Mullan
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort 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

Re: RFR: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Weijun Wang
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort 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

Integrated: 8253866: Security Libs Terminology Refresh

2021-01-14 Thread Jamil Nimeh
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote: > This is the security libs portion of the effort 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

Re: RFR: 8253866: Security Libs Terminology Refresh [v2]

2021-01-14 Thread Jamil Nimeh
On Thu, 14 Jan 2021 15:45:43 GMT, Sean Mullan wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Minor grammatical fixes > > src/java.base/share/conf/security/java.security line 455: > >> 453: #max_retries and

Re: [jdk16] RFR: 8254350: CompletableFuture.get may swallow InterruptedException

2021-01-14 Thread Martin Buchholz
On Thu, 14 Jan 2021 13:59:50 GMT, Kezhu Wang wrote: >> 8254350: CompletableFuture.get may swallow InterruptedException > > @Martin-Buchholz @DougLea @AlanBateman Sorry for rough in. After change > `future.get()` to `future.get(1, TimeUnit.DAYS)`, > `SwallowedInterruptedException` failed.

Re: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec

2021-01-14 Thread Stuart Marks
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:

Re: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec

2021-01-14 Thread Stuart Marks
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. Changes look good.

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll [v7]

2021-01-14 Thread Peter Levart
On Thu, 14 Jan 2021 15:25:25 GMT, Сергей Цыпанов wrote: >> Hello, I feel like this was previously discussed in >> https://mail.openjdk.java.net/pipermail/core-libs-dev/ but since I cannot >> find original mail I post this here. >> >> Currently `Collections.addAll()` is implemented and

Re: Difference in encoding semantics of URI returned by File.toURI and Path.toUri representing the same file

2021-01-14 Thread Sebastian Stenzel
> On 13. Jan 2021, at 17:50, Daniel Fuchs wrote: > > [...] > It's not clear to me whether NFC should be applied - or what would be > the consequences of applying NFC there (or not). While I can't answer this question, it may be worth mentioning RFC 3987 which might not be directly

RFR: 8259707: LDAP channel binding does not work with StartTLS extension

2021-01-14 Thread Alexey Bakhtin
Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension. Test from the bug report and jtreg javax/naming tests are passed. - Commit messages: - 8259707: LDAP channel binding does not work with StartTLS extension Changes:

RE: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently

2021-01-14 Thread yano-masan...@fujitsu.com
Hello, Please reply if anyone can be a sponsor. Regards, Masanori Yano > -Original Message- > From: Yano, Masanori > Sent: Wednesday, December 23, 2020 5:01 PM > To: 'core-libs-dev@openjdk.java.net' > Subject: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty >

RFR: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues

2021-01-14 Thread Athijegannathan Sundararajan
Fixed compilation issues with the test. Test compiles and runs fine locally. - Commit messages: - 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues Changes: https://git.openjdk.java.net/jdk/pull/2091/files Webrev:

Re: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec [v2]

2021-01-14 Thread Tagir F . Valeev
> Handle TreeMap::computeIfAbsent when previous mapping with null value existed > (in this case spec requires to overwrite the existing mapping) Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Copyright year updated

Integrated: 8259622: TreeMap.computeIfAbsent deviates from spec

2021-01-14 Thread Tagir F . Valeev
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) This pull request has now been integrated. Changeset: 2c8e337d Author:Tagir F. Valeev

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

2021-01-14 Thread Leo Jiang
On Thu, 14 Jan 2021 17:19:11 GMT, Naoto Sato wrote: >> Leo Jiang 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 the merge/rebase. The pull request contains two additional commits >>

Re: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant

2021-01-14 Thread Richard Fussenegger
On Thu, 17 Dec 2020 22:16:12 GMT, Roger Riggs wrote: >> I cannot create CSRs, only members can. Deprecating and switching to another >> function results in much more work for users overall because it affects all >> those who use it correctly as well. In other words: 100% >> >> I'm in favor of

Re: RFR: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues

2021-01-14 Thread Alan Bateman
On Fri, 15 Jan 2021 05:19:44 GMT, Athijegannathan Sundararajan wrote: > Fixed compilation issues with the test. Test compiles and runs fine locally. Are you going to remove it from the exclude list (test/jdk/ProblemList.txt)? I skimmed through the changes and it looks fine but would like