From prappo at openjdk.java.net  Mon Nov  1 15:11:22 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 1 Nov 2021 15:11:22 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
Message-ID: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>

Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.

-------------

Commit messages:
 - Fix *code* typo
 - Be more immutable
 - Fix typos

Changes: https://git.openjdk.java.net/jdk/pull/6191/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6191&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276234
  Stats: 10 lines in 3 files changed: 0 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6191.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6191/head:pull/6191

PR: https://git.openjdk.java.net/jdk/pull/6191

From redestad at openjdk.java.net  Mon Nov  1 15:27:14 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Nov 2021 15:27:14 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
In-Reply-To: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
Message-ID: <HV_zBZI1B0qhntmmeP-gFVYDTl-g6Ar_f3BO3PrZpBY=.c5ccc76b-dddb-41b6-8066-3a1a6e3dd433@github.com>

On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.

LGTM, but please use `static final`

src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:

> 246:         private static final LocaleDataStrategy INSTANCE = new LocaleDataStrategy();
> 247:         // TODO: avoid hard-coded Locales
> 248:         private final static Set<Locale> JAVA_BASE_LOCALES

Canonical modifier order is `static final`

src/java.base/share/classes/sun/util/resources/LocaleData.java line 327:

> 325:                 = new SupplementaryStrategy();
> 326:         // TODO: avoid hard-coded Locales
> 327:         private final static Set<Locale> JAVA_BASE_LOCALES

Canonical modifier order is `static final`

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6191

From redestad at openjdk.java.net  Mon Nov  1 15:27:36 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Nov 2021 15:27:36 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter
Message-ID: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>

Prompted by a request from Volkan Yaz?c? I took a look at why DataTimeFormatters are much less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch address some of that gap, without having looked at the third party implementations. 

When printing times:
- Avoid turning integral values into `String`s before appending them to the buffer 
- Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`

This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).

Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.

Testing: tier1-3

-------------

Commit messages:
 - 8276220: Reduce excessive allocations in DateTimeFormatter

Changes: https://git.openjdk.java.net/jdk/pull/6188/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276220
  Stats: 429 lines in 4 files changed: 407 ins; 10 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Mon Nov  1 15:27:37 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Nov 2021 15:27:37 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <r-YCBQZCNMw69EFoFY8LOEthCRKeWNRAn9i7tR0qLco=.20be0514-249e-40a9-a290-eb4b06b8254f@github.com>

On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Prompted by a request from Volkan Yaz?c? I took a look at why DataTimeFormatters are much less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch address some of that gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Microbenchmark numbers for the supplied `DateTimeFormatterBench`. 

Baseline:

Benchmark                               (pattern)   Mode  Cnt       Score       Error   Units
formatInstants                           HH:mm:ss  thrpt   15       6.558 ?     0.125  ops/ms
  ?gc.alloc.rate.norm                    HH:mm:ss  thrpt   15  192015.139 ?     0.352    B/op
formatInstants                       HH:mm:ss.SSS  thrpt   15       2.772 ?     0.036  ops/ms
  ?gc.alloc.rate.norm                HH:mm:ss.SSS  thrpt   15  696805.289 ? 11280.987    B/op
formatInstants              yyyy-MM-dd'T'HH:mm:ss  thrpt   15       4.025 ?     0.056  ops/ms
  ?gc.alloc.rate.norm       yyyy-MM-dd'T'HH:mm:ss  thrpt   15  264020.926 ?     0.555    B/op
formatInstants          yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15       2.121 ?     0.026  ops/ms
  ?gc.alloc.rate.norm   yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  768811.221 ? 11281.118    B/op
formatZonedDateTime                      HH:mm:ss  thrpt   15       8.797 ?     0.254  ops/ms
  ?gc.alloc.rate.norm                    HH:mm:ss  thrpt   15   96007.787 ?     0.331    B/op
formatZonedDateTime                  HH:mm:ss.SSS  thrpt   15       3.109 ?     0.024  ops/ms
  ?gc.alloc.rate.norm                HH:mm:ss.SSS  thrpt   15  600798.055 ? 11280.992    B/op
formatZonedDateTime         yyyy-MM-dd'T'HH:mm:ss  thrpt   15       4.814 ?     0.037  ops/ms
  ?gc.alloc.rate.norm       yyyy-MM-dd'T'HH:mm:ss  thrpt   15  168013.636 ?     0.389    B/op
formatZonedDateTime     yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15       2.299 ?     0.059  ops/ms
  ?gc.alloc.rate.norm   yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  680012.566 ? 11281.140    B/op


Patched:

Benchmark                               (pattern)   Mode  Cnt       Score      Error   Units
formatInstants                           HH:mm:ss  thrpt   15       7.721 ?    0.114  ops/ms
  ?gc.alloc.rate.norm                    HH:mm:ss  thrpt   15  120010.043 ?    0.934    B/op
formatInstants                       HH:mm:ss.SSS  thrpt   15       5.684 ?    0.083  ops/ms
  ?gc.alloc.rate.norm                HH:mm:ss.SSS  thrpt   15  120009.973 ?    0.608    B/op
formatInstants              yyyy-MM-dd'T'HH:mm:ss  thrpt   15       4.962 ?    0.058  ops/ms
  ?gc.alloc.rate.norm       yyyy-MM-dd'T'HH:mm:ss  thrpt   15  120010.027 ?    0.703    B/op
formatInstants          yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15       3.889 ?    0.068  ops/ms
  ?gc.alloc.rate.norm   yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  120010.284 ?    1.003    B/op
formatZonedDateTime                      HH:mm:ss  thrpt   15      11.087 ?    0.404  ops/ms
  ?gc.alloc.rate.norm                    HH:mm:ss  thrpt   15   24002.072 ?    0.219    B/op
formatZonedDateTime                  HH:mm:ss.SSS  thrpt   15       7.325 ?    0.139  ops/ms
  ?gc.alloc.rate.norm                HH:mm:ss.SSS  thrpt   15   24002.080 ?    0.267    B/op
formatZonedDateTime         yyyy-MM-dd'T'HH:mm:ss  thrpt   15       6.127 ?    0.040  ops/ms
  ?gc.alloc.rate.norm       yyyy-MM-dd'T'HH:mm:ss  thrpt   15   24002.084 ?    0.459    B/op
formatZonedDateTime     yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15       4.576 ?    0.049  ops/ms
  ?gc.alloc.rate.norm   yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   24002.102 ?    0.511    B/op


The most dramatic improvement is seen for `formatZonedDateTime` using the format `yyyy-MM-dd'T'HH:mm:ss.SSS`, which sees a 2x speed-up and almost 97% reduction in allocations. The same variant using `Instant`s see a 1.8x speed-up and almost 85% reduction in allocations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From dfuchs at openjdk.java.net  Mon Nov  1 15:56:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 1 Nov 2021 15:56:16 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
In-Reply-To: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
Message-ID: <dG7Nvslh4kZG_6G5s6E_hayt4qlz7TiLlvzAR1ucwD4=.25a37d12-2029-4b9f-89bd-c141deaaade7@github.com>

On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.

src/java.base/share/classes/sun/util/resources/LocaleData.java line 336:

> 334:         public List<Locale> getCandidateLocales(String baseName, Locale locale) {
> 335:             // Specify only the given locale
> 336:             return List.of(locale);

Is it guaranteed that `locale` is not `null` here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From duke at openjdk.java.net  Mon Nov  1 16:09:21 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Mon, 1 Nov 2021 16:09:21 GMT
Subject: <i18n dev> RFR: JDK-8276236: Table headers missing in Formatter api
 docs
Message-ID: <_iqMdYEvrAlYs7m5YbpGP0r-AeEFKnwTAy-raqhR-pc=.02705bdb-4115-4875-8c5b-1ecef9bbc5f9@github.com>

Adds table headers to all tables in Formatter api docs. I inferred the header "Unicode" for the columns that contained unicode
codepoints.

Formatter api docs: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html

-------------

Commit messages:
 - Fixes JDK-8276236

Changes: https://git.openjdk.java.net/jdk/pull/6195/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6195&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276236
  Stats: 80 lines in 1 file changed: 80 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6195.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6195/head:pull/6195

PR: https://git.openjdk.java.net/jdk/pull/6195

From itakiguchi at openjdk.java.net  Mon Nov  1 16:10:26 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 1 Nov 2021 16:10:26 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - Langtools command's usage were grabled on Japanese Windows

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=04
  Stats: 104 lines in 17 files changed: 74 ins; 0 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771

PR: https://git.openjdk.java.net/jdk/pull/5771

From naoto at openjdk.java.net  Mon Nov  1 16:12:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 1 Nov 2021 16:12:08 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
In-Reply-To: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
Message-ID: <tZNkTk0lWatN7YrRlEdFe0pbNZBOJYKtfpKoiZyQ9uo=.7acca940-8be9-45a8-b449-9219828d27c5@github.com>

On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From prappo at openjdk.java.net  Mon Nov  1 16:20:10 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 1 Nov 2021 16:20:10 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
In-Reply-To: <dG7Nvslh4kZG_6G5s6E_hayt4qlz7TiLlvzAR1ucwD4=.25a37d12-2029-4b9f-89bd-c141deaaade7@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
 <dG7Nvslh4kZG_6G5s6E_hayt4qlz7TiLlvzAR1ucwD4=.25a37d12-2029-4b9f-89bd-c141deaaade7@github.com>
Message-ID: <YE0iFm7D6v0b-TwAuxJjHusPD2Ddo1JAplqJ53e7chw=.7e67f7f1-7705-49ce-bb39-f57a8435ab03@github.com>

On Mon, 1 Nov 2021 15:52:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 336:
> 
>> 334:         public List<Locale> getCandidateLocales(String baseName, Locale locale) {
>> 335:             // Specify only the given locale
>> 336:             return List.of(locale);
> 
> Is it guaranteed that `locale` is not `null` here?

This is a good question. As far I can see, the only call site checks for null explicitly: https://github.com/openjdk/jdk/blob/a4c46e1e4f4f2f05c8002b2af683a390fc46b424/src/java.base/share/classes/sun/util/resources/Bundles.java#L113

So the answer is yes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From prappo at openjdk.java.net  Mon Nov  1 16:28:09 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 1 Nov 2021 16:28:09 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
In-Reply-To: <HV_zBZI1B0qhntmmeP-gFVYDTl-g6Ar_f3BO3PrZpBY=.c5ccc76b-dddb-41b6-8066-3a1a6e3dd433@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
 <HV_zBZI1B0qhntmmeP-gFVYDTl-g6Ar_f3BO3PrZpBY=.c5ccc76b-dddb-41b6-8066-3a1a6e3dd433@github.com>
Message-ID: <XMrlxnPX1hib0WcJzfdHSfxupzcSElbQT_1dshO4ybk=.8df5e33b-1d5e-4a68-8811-2673db242b8f@github.com>

On Mon, 1 Nov 2021 15:23:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
> 
>> 246:         private static final LocaleDataStrategy INSTANCE = new LocaleDataStrategy();
>> 247:         // TODO: avoid hard-coded Locales
>> 248:         private final static Set<Locale> JAVA_BASE_LOCALES
> 
> Canonical modifier order is `static final`

It turns out that my IDE was configured NOT to highlight missorted modifiers. Once I reconfigured it, I saw these cases and some other in that same file. I'll fix them all if that's okay.

My recollection is that there have been campaigns on using "the blessed modifiers order". It might be that since the last such crusade the modifiers have gone out of hand, and we might need to re-bless them :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From prappo at openjdk.java.net  Mon Nov  1 16:51:37 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 1 Nov 2021 16:51:37 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
 [v2]
In-Reply-To: <XMrlxnPX1hib0WcJzfdHSfxupzcSElbQT_1dshO4ybk=.8df5e33b-1d5e-4a68-8811-2673db242b8f@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
 <HV_zBZI1B0qhntmmeP-gFVYDTl-g6Ar_f3BO3PrZpBY=.c5ccc76b-dddb-41b6-8066-3a1a6e3dd433@github.com>
 <XMrlxnPX1hib0WcJzfdHSfxupzcSElbQT_1dshO4ybk=.8df5e33b-1d5e-4a68-8811-2673db242b8f@github.com>
Message-ID: <0LHhxDGarZgvvUQ9c8MJfsxagnMW5YRRhcQvx1Qu1Mo=.d0e937e7-03b2-4ce7-ac4b-9254d05ce3fb@github.com>

On Mon, 1 Nov 2021 16:25:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
>> 
>>> 246:         private static final LocaleDataStrategy INSTANCE = new LocaleDataStrategy();
>>> 247:         // TODO: avoid hard-coded Locales
>>> 248:         private final static Set<Locale> JAVA_BASE_LOCALES
>> 
>> Canonical modifier order is `static final`
>
> It turns out that my IDE was configured NOT to highlight missorted modifiers. Once I reconfigured it, I saw these cases and some other in that same file. I'll fix them all if that's okay.
> 
> My recollection is that there have been campaigns on using "the blessed modifiers order". It might be that since the last such crusade the modifiers have gone out of hand, and we might need to re-bless them :-)

Fixed in 2b7e0c6.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From prappo at openjdk.java.net  Mon Nov  1 16:51:36 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 1 Nov 2021 16:51:36 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
 [v2]
In-Reply-To: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
Message-ID: <arP4T4CBjpWKM-xMh4w9c55tz5agAPxbOQMegnm-CU8=.246bfb89-820d-4d27-b4a1-cf029eb9fbf1@github.com>

> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Use the blessed modifiers order

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6191/files
  - new: https://git.openjdk.java.net/jdk/pull/6191/files/8e2815b8..2b7e0c68

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6191&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6191&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6191.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6191/head:pull/6191

PR: https://git.openjdk.java.net/jdk/pull/6191

From coffeys at openjdk.java.net  Mon Nov  1 17:19:07 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Mon, 1 Nov 2021 17:19:07 GMT
Subject: <i18n dev> RFR: JDK-8276236: Table headers missing in Formatter
 api docs
In-Reply-To: <_iqMdYEvrAlYs7m5YbpGP0r-AeEFKnwTAy-raqhR-pc=.02705bdb-4115-4875-8c5b-1ecef9bbc5f9@github.com>
References: <_iqMdYEvrAlYs7m5YbpGP0r-AeEFKnwTAy-raqhR-pc=.02705bdb-4115-4875-8c5b-1ecef9bbc5f9@github.com>
Message-ID: <aZ9JLFvStH4LMThzIrQ0Hocu4Mwj_u2fVvM7YbnOkFs=.75f6bd49-d737-4c64-b677-2d88ce182530@github.com>

On Mon, 1 Nov 2021 15:59:22 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Adds table headers to all tables in Formatter api docs. I inferred the header "Unicode" for the columns that contained unicode
> codepoints.
> 
> Formatter api docs: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html

LGTM

-------------

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6195

From iris at openjdk.java.net  Mon Nov  1 17:22:14 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 1 Nov 2021 17:22:14 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
 [v2]
In-Reply-To: <arP4T4CBjpWKM-xMh4w9c55tz5agAPxbOQMegnm-CU8=.246bfb89-820d-4d27-b4a1-cf029eb9fbf1@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
 <arP4T4CBjpWKM-xMh4w9c55tz5agAPxbOQMegnm-CU8=.246bfb89-820d-4d27-b4a1-cf029eb9fbf1@github.com>
Message-ID: <DcTJ43iZtkDMf2lguRPXmD7aAL-MjokGaL7mfT3YKWk=.ab5c3c26-7527-4cc7-af2a-49156b2d9fa5@github.com>

On Mon, 1 Nov 2021 16:51:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the blessed modifiers order

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From iris at openjdk.java.net  Mon Nov  1 17:24:13 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 1 Nov 2021 17:24:13 GMT
Subject: <i18n dev> RFR: JDK-8276236: Table headers missing in Formatter
 api docs
In-Reply-To: <_iqMdYEvrAlYs7m5YbpGP0r-AeEFKnwTAy-raqhR-pc=.02705bdb-4115-4875-8c5b-1ecef9bbc5f9@github.com>
References: <_iqMdYEvrAlYs7m5YbpGP0r-AeEFKnwTAy-raqhR-pc=.02705bdb-4115-4875-8c5b-1ecef9bbc5f9@github.com>
Message-ID: <oNPfUeHLgPtDY_5YTnKzepjv6kTcqAzalqGyMa41Jvs=.a2f90db7-0241-4de3-9b0b-50a0d3c41096@github.com>

On Mon, 1 Nov 2021 15:59:22 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Adds table headers to all tables in Formatter api docs. I inferred the header "Unicode" for the columns that contained unicode
> codepoints.
> 
> Formatter api docs: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6195

From scolebourne at openjdk.java.net  Mon Nov  1 22:22:10 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 1 Nov 2021 22:22:10 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <KOSGZH5OXVPRhsRJTD3uSBzNvRwZ2qYwQh0hAqgGwws=.6856126e-21bd-4de3-827a-8e92f15378b3@github.com>

On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Changes requested by scolebourne (Author).

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3269:

> 3267:                 return false;
> 3268:             }
> 3269:             int val = value.intValue(); // NANO_OF_SECOND must fit in an int and can't be negative

Unfortunately, this is not a valid assumption, and it affects the logic of the optimization more generally (methods where non-negative is assumed).

Basically, NANO_OF_SECOND (and all other fields in the formatter) can have any `long` value. Despite immediate appearances, the value is not limited to 0 to 999,999,999. This is because you are allowed to create an implementation of `Temporal` that returns values outside that range. No such class exists in the JDK, but such a class would be perfectly legal. As a related example, it would be perfectly value to write a time class that ran from 03:00 to 26:59 each day, thus HOUROF_DAY cannot be assumed by the formatter to be between 0 and 23.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Mon Nov  1 22:30:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Nov 2021 22:30:08 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter
In-Reply-To: <KOSGZH5OXVPRhsRJTD3uSBzNvRwZ2qYwQh0hAqgGwws=.6856126e-21bd-4de3-827a-8e92f15378b3@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <KOSGZH5OXVPRhsRJTD3uSBzNvRwZ2qYwQh0hAqgGwws=.6856126e-21bd-4de3-827a-8e92f15378b3@github.com>
Message-ID: <Ic4mxiGZHS2EOcegmgHwhGKkvFbG9i-ZqrJZVbpx7nI=.d960e525-10df-45dd-bd58-db2053436d0a@github.com>

On Mon, 1 Nov 2021 22:18:52 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3269:
> 
>> 3267:                 return false;
>> 3268:             }
>> 3269:             int val = value.intValue(); // NANO_OF_SECOND must fit in an int and can't be negative
> 
> Unfortunately, this is not a valid assumption, and it affects the logic of the optimization more generally (methods where non-negative is assumed).
> 
> Basically, NANO_OF_SECOND (and all other fields in the formatter) can have any `long` value. Despite immediate appearances, the value is not limited to 0 to 999,999,999. This is because you are allowed to create an implementation of `Temporal` that returns values outside that range. No such class exists in the JDK, but such a class would be perfectly legal. As a related example, it would be perfectly value to write a time class that ran from 03:00 to 26:59 each day, thus HOUROF_DAY cannot be assumed by the formatter to be between 0 and 23.

The commentary on this line could probably be improved, but this is in a private printer-parser that will only be used for NANO_OF_SECOND and not any arbitrary `Temporal` (see line 704), thus I fail to see how this assumption can fail (since NANO_OF_SECOND specifies a value range from 0 to 999,999,999).

I considered writing a more generic integral-fraction printer parser that would optimize for any value-range that fits in an int, but seeing how NANO_OF_SECOND is likely the only one used in practice and with a high demand for better efficiency I opted to specialize for it more directly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Mon Nov  1 22:42:50 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Nov 2021 22:42:50 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v2]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <z62SzxA9YHes5N81KjcWqIBJ5c9k1mClvWcVywcJoLw=.7e46b2ac-6724-41f4-8d21-6f3ddfe6b343@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove stray method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/9e97b4dc..ee13139a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Mon Nov  1 22:42:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 1 Nov 2021 22:42:52 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v2]
In-Reply-To: <Ic4mxiGZHS2EOcegmgHwhGKkvFbG9i-ZqrJZVbpx7nI=.d960e525-10df-45dd-bd58-db2053436d0a@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <KOSGZH5OXVPRhsRJTD3uSBzNvRwZ2qYwQh0hAqgGwws=.6856126e-21bd-4de3-827a-8e92f15378b3@github.com>
 <Ic4mxiGZHS2EOcegmgHwhGKkvFbG9i-ZqrJZVbpx7nI=.d960e525-10df-45dd-bd58-db2053436d0a@github.com>
Message-ID: <M7A5HoBD3AVl9F_gF9Q3xELlgx4eqq5-uo1ZSGzz09c=.4e86db29-3e5a-42d3-a08d-2320224d5ed0@github.com>

On Mon, 1 Nov 2021 22:27:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3269:
>> 
>>> 3267:                 return false;
>>> 3268:             }
>>> 3269:             int val = value.intValue(); // NANO_OF_SECOND must fit in an int and can't be negative
>> 
>> Unfortunately, this is not a valid assumption, and it affects the logic of the optimization more generally (methods where non-negative is assumed).
>> 
>> Basically, NANO_OF_SECOND (and all other fields in the formatter) can have any `long` value. Despite immediate appearances, the value is not limited to 0 to 999,999,999. This is because you are allowed to create an implementation of `Temporal` that returns values outside that range. No such class exists in the JDK, but such a class would be perfectly legal. As a related example, it would be perfectly value to write a time class that ran from 03:00 to 26:59 each day, thus HOUROF_DAY cannot be assumed by the formatter to be between 0 and 23.
>
> The commentary on this line could probably be improved, but this is in a private printer-parser that will only be used for NANO_OF_SECOND and not any arbitrary `TemporalField` (see line 704), thus I fail to see how this assumption can fail (since NANO_OF_SECOND specifies a value range from 0 to 999,999,999).
> 
> I considered writing a more generic integral-fraction printer parser that would optimize for any value-range that fits in an int, but seeing how NANO_OF_SECOND is likely the only one used in practice and with a high demand for better efficiency I opted to specialize for it more directly.

I see what you're saying that an arbitrary `Temporal` could define its own fields with its own ranges, but I would consider it a design bug if such an implementation at a whim redefines the value ranges of well-defined constants such as `ChronoField.NANO_OF_SECOND` or `HOUR_OF_DAY`. I'd expect such a `Temporal` would have to define its own enumeration of allowed `TemporalField`s.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From prappo at openjdk.java.net  Mon Nov  1 22:53:19 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 1 Nov 2021 22:53:19 GMT
Subject: <i18n dev> RFR: 8276234: Trivially clean up locale-related code
 [v2]
In-Reply-To: <arP4T4CBjpWKM-xMh4w9c55tz5agAPxbOQMegnm-CU8=.246bfb89-820d-4d27-b4a1-cf029eb9fbf1@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
 <arP4T4CBjpWKM-xMh4w9c55tz5agAPxbOQMegnm-CU8=.246bfb89-820d-4d27-b4a1-cf029eb9fbf1@github.com>
Message-ID: <pybWQZHM3mEzbEzB8X0anlKXCUa0FmWyo988UkCOuII=.2dc5ae7e-ed3d-4936-b2e7-a91cd29c7afb@github.com>

On Mon, 1 Nov 2021 16:51:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the blessed modifiers order

The test job that has been scheduled previously has completed successfully.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From prappo at openjdk.java.net  Mon Nov  1 22:53:20 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 1 Nov 2021 22:53:20 GMT
Subject: <i18n dev> Integrated: 8276234: Trivially clean up locale-related
 code
In-Reply-To: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
References: <05Aer6RdSPxZBki5ScMZ20xG3OEODScFADcYSHucQ2Y=.12009073-51ba-4f39-bb9c-22673b6998c6@github.com>
Message-ID: <obvj_z4Y6o4eISG-1kI8b8wMgksguLa9ByDwpDmoQVA=.69ceaa6d-619a-4deb-a277-f9ba79ae1c1c@github.com>

On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR. A comprehensive test job has been scheduled; I'll notify this thread once that job has completed.

This pull request has now been integrated.

Changeset: 2eafa036
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2eafa036c03d3e8f3dba8f67dd37b484874dc3d3
Stats:     13 lines in 3 files changed: 0 ins; 1 del; 12 mod

8276234: Trivially clean up locale-related code

Reviewed-by: redestad, naoto, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/6191

From itakiguchi at openjdk.java.net  Tue Nov  2 00:19:15 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 2 Nov 2021 00:19:15 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <LN2laH6f1Iev8itWARImc-iyulBKM3xgmWCFSRxTfi0=.b232f0c7-4955-40c8-8dca-e126fa3260c3@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

I needed to rebase my fixed code since JavapTask.java and JdepsTask.java were updated.

Hello @jonathan-gibbons .
Could you check new fixes ?
I changed following parts:
* Native charset is generated on com/sun/tools/javac/util/Log.java.
* module-info.java was updated

Hello @naotoj .
Could you check new fixes again ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From ysatowse at openjdk.java.net  Tue Nov  2 01:26:09 2021
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 2 Nov 2021 01:26:09 GMT
Subject: <i18n dev> RFR: 8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
References: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
Message-ID: <NgveACjidum-QevMm0JcMGhPfAZjMmsue0GdahQMaxo=.133eb74f-da15-48c1-b5ce-bf52bed28e72@github.com>

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests. 
> 
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fails with tzdata2021e

@coffeys please complete your review on this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6144

From scolebourne at openjdk.java.net  Tue Nov  2 07:34:07 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Tue, 2 Nov 2021 07:34:07 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v2]
In-Reply-To: <M7A5HoBD3AVl9F_gF9Q3xELlgx4eqq5-uo1ZSGzz09c=.4e86db29-3e5a-42d3-a08d-2320224d5ed0@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <KOSGZH5OXVPRhsRJTD3uSBzNvRwZ2qYwQh0hAqgGwws=.6856126e-21bd-4de3-827a-8e92f15378b3@github.com>
 <Ic4mxiGZHS2EOcegmgHwhGKkvFbG9i-ZqrJZVbpx7nI=.d960e525-10df-45dd-bd58-db2053436d0a@github.com>
 <M7A5HoBD3AVl9F_gF9Q3xELlgx4eqq5-uo1ZSGzz09c=.4e86db29-3e5a-42d3-a08d-2320224d5ed0@github.com>
Message-ID: <7qlXyuTr1puHgxPryb1CpsvEdPxsSnsE9TFG5xpA2m4=.ea431668-f69a-413d-9106-676640d86dc8@github.com>

On Mon, 1 Nov 2021 22:35:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The commentary on this line could probably be improved, but this is in a private printer-parser that will only be used for NANO_OF_SECOND and not any arbitrary `TemporalField` (see line 704), thus I fail to see how this assumption can fail (since NANO_OF_SECOND specifies a value range from 0 to 999,999,999).
>> 
>> I considered writing a more generic integral-fraction printer parser that would optimize for any value-range that fits in an int, but seeing how NANO_OF_SECOND is likely the only one used in practice and with a high demand for better efficiency I opted to specialize for it more directly.
>
> I see what you're saying that an arbitrary `Temporal` could define its own fields with its own ranges, but I would consider it a design bug if such an implementation at a whim redefines the value ranges of well-defined constants such as `ChronoField.NANO_OF_SECOND` or `HOUR_OF_DAY`. I'd expect such a `Temporal` would have to define its own enumeration of allowed `TemporalField`s.

That isn't the design model however. The design model for the formatter is a `Map` like view of field to value. Any value may be associated with any field - that is exactly what `Temporal` offers. [`TempralAccessor.getLong()`](https://download.java.net/java/early_access/loom/docs/api/java.base/java/time/temporal/TemporalAccessor.html#getLong(java.time.temporal.TemporalField)) is very explicit about this.

As indicated above, the positive part is that an hour-of-day of 26 can be printed by a user-written `WrappingLocalTime` class. The downside is the inability to make optimizing assumptions as per this code.

FWIW, I had originally intended to write dedicated private formatters where the pattern and type to be formatted are known, such as `LocalDate` and the ISO pattern.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From coffeys at openjdk.java.net  Tue Nov  2 09:26:09 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 2 Nov 2021 09:26:09 GMT
Subject: <i18n dev> RFR: 8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
References: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
Message-ID: <-bYG3g0xtNPZ3g5S_XUAjUwoui2kNWfOlGq4yLTMvMg=.90b063de-5c3b-41fd-b1c9-d1e10fb2a8bf@github.com>

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests. 
> 
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fails with tzdata2021e

Marked as reviewed by coffeys (Reviewer).

I think you've enough Reviewers already but yes, this looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6144

From duke at openjdk.java.net  Tue Nov  2 09:50:19 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Tue, 2 Nov 2021 09:50:19 GMT
Subject: <i18n dev> Integrated: JDK-8276236: Table headers missing in
 Formatter api docs
In-Reply-To: <_iqMdYEvrAlYs7m5YbpGP0r-AeEFKnwTAy-raqhR-pc=.02705bdb-4115-4875-8c5b-1ecef9bbc5f9@github.com>
References: <_iqMdYEvrAlYs7m5YbpGP0r-AeEFKnwTAy-raqhR-pc=.02705bdb-4115-4875-8c5b-1ecef9bbc5f9@github.com>
Message-ID: <Cd3LGk1W9YtJDjgNf630DsV0q-nlW8kgZco4vhhNxfU=.b4e14533-136c-436f-b2a1-ab4925762ede@github.com>

On Mon, 1 Nov 2021 15:59:22 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Adds table headers to all tables in Formatter api docs. I inferred the header "Unicode" for the columns that contained unicode
> codepoints.
> 
> Formatter api docs: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html

This pull request has now been integrated.

Changeset: 92be9d8c
Author:    Ludvig Janiuk <ludvig.j.janiuk at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92be9d8c535274eea4edd06273e6d7811f6bb113
Stats:     80 lines in 1 file changed: 80 ins; 0 del; 0 mod

8276236: Table headers missing in Formatter api docs

Reviewed-by: coffeys, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/6195

From redestad at openjdk.java.net  Tue Nov  2 11:03:02 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 2 Nov 2021 11:03:02 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add fallback for values outside the allowable range

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/ee13139a..21092323

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=01-02

  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Tue Nov  2 11:07:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 2 Nov 2021 11:07:09 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <7qlXyuTr1puHgxPryb1CpsvEdPxsSnsE9TFG5xpA2m4=.ea431668-f69a-413d-9106-676640d86dc8@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <KOSGZH5OXVPRhsRJTD3uSBzNvRwZ2qYwQh0hAqgGwws=.6856126e-21bd-4de3-827a-8e92f15378b3@github.com>
 <Ic4mxiGZHS2EOcegmgHwhGKkvFbG9i-ZqrJZVbpx7nI=.d960e525-10df-45dd-bd58-db2053436d0a@github.com>
 <M7A5HoBD3AVl9F_gF9Q3xELlgx4eqq5-uo1ZSGzz09c=.4e86db29-3e5a-42d3-a08d-2320224d5ed0@github.com>
 <7qlXyuTr1puHgxPryb1CpsvEdPxsSnsE9TFG5xpA2m4=.ea431668-f69a-413d-9106-676640d86dc8@github.com>
Message-ID: <cev4bLETonvenxrC5aOptn5dLfb6Kmi6APzm1mOj0vU=.65a175f5-a2d4-4a78-b996-35c575841079@github.com>

On Tue, 2 Nov 2021 07:31:09 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> I see what you're saying that an arbitrary `Temporal` could define its own fields with its own ranges, but I would consider it a design bug if such an implementation at a whim redefines the value ranges of well-defined constants such as `ChronoField.NANO_OF_SECOND` or `HOUR_OF_DAY`. I'd expect such a `Temporal` would have to define its own enumeration of allowed `TemporalField`s.
>
> That isn't the design model however. The design model for the formatter is a `Map` like view of field to value. Any value may be associated with any field - that is exactly what `Temporal` offers. [`TempralAccessor.getLong()`](https://download.java.net/java/early_access/loom/docs/api/java.base/java/time/temporal/TemporalAccessor.html#getLong(java.time.temporal.TemporalField)) is very explicit about this.
> 
> As indicated above, the positive part is that an hour-of-day of 26 can be printed by a user-written `WrappingLocalTime` class. The downside is the inability to make optimizing assumptions as per this code.
> 
> FWIW, I had originally intended to write dedicated private formatters where the pattern and type to be formatted are known, such as `LocalDate` and the ISO pattern.

Ok, I've added a fallback to instantiate and use an instance of `FractionPrinterParser` when the value is outside of the range. This has a negligible negative effect on performance in the provided micro-benchmarks. Does this resolve your concerns?

I think dedicated private formatters is still a good idea, but I wanted to take a stab (like this) at improving common patterns in the shared code first.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From ysatowse at openjdk.java.net  Tue Nov  2 13:06:20 2021
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 2 Nov 2021 13:06:20 GMT
Subject: <i18n dev> Integrated: 8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
References: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
Message-ID: <xBnWl6rU7IkD231OQ3nIf0WLiImkHIbdKi41PSKDoqI=.87e1e540-3788-48a6-9595-a52d6f5f0caa@github.com>

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests. 
> 
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fails with tzdata2021e

This pull request has now been integrated.

Changeset: 5b4e3986
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5b4e39863dbc0d61e91675261dd6887f704ab868
Stats:     52 lines in 6 files changed: 29 ins; 6 del; 17 mod

8275766: (tz) Update Timezone Data to 2021e
8275849: TestZoneInfo310.java fails with tzdata2021e

Reviewed-by: naoto, iris, erikj, coffeys

-------------

PR: https://git.openjdk.java.net/jdk/pull/6144

From prappo at openjdk.java.net  Tue Nov  2 16:54:28 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 16:54:28 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
Message-ID: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>

This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?

As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.

This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:

    $ sh ./bin/blessed-modifier-order.sh src/java.base

The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.

[^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
[^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6213/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6213&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276348
  Stats: 39 lines in 21 files changed: 0 ins; 0 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6213.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6213/head:pull/6213

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 16:58:11 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 16:58:11 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <zZMdJU4BXOR-4mcoyrKrmrTLXGiJi8hekZJ_KGvldrw=.362aaf50-0708-4016-8455-ffb817c5f12c@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

A colleague suggested that I should clarify that the `blessed-modifier-order.sh` script that I used is available in the JDK repo at https://github.com/openjdk/jdk/blob/01105d6985b39d4064b9066eab3612da5a401685/bin/blessed-modifier-order.sh. That script was contributed by Martin Buchholz in JDK-8136656 in 2015.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From dfuchs at openjdk.java.net  Tue Nov  2 17:13:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 2 Nov 2021 17:13:10 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <vAasuC86pLnqzqKTDT1xJlXxIDU57fCqyOJbKbpZgNQ=.22ec60dd-e1ee-44e5-ac4d-9d9e85e35839@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by dfuchs (Reviewer).

LGTM

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From rriggs at openjdk.java.net  Tue Nov  2 17:17:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 2 Nov 2021 17:17:18 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

src/java.base/share/classes/java/lang/Object.java line 282:

> 280:      * <li>For objects of type {@code Class,} by executing a
> 281:      *     static synchronized method of that class.
> 282:      * </ul>

In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From darcy at openjdk.java.net  Tue Nov  2 17:24:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 2 Nov 2021 17:24:14 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <jYgJWYaCicwG9drcOKmBwmNg622VJmuQOL1Eh-gVhY8=.17d6cecf-0b90-4592-82f6-7ece2c782b91@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From iris at openjdk.java.net  Tue Nov  2 17:24:14 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 2 Nov 2021 17:24:14 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <GJb7WJ0CqsRGsN-5zeOhiq82SGQMFT8N9AImRs_lzHU=.8f86ebc7-055a-4c69-b983-a2e7710f01df@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From alanb at openjdk.java.net  Tue Nov  2 17:42:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 2 Nov 2021 17:42:14 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
Message-ID: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>

On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.

I think Roger is right and maybe the change to the javadoc could be dropped from this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 17:49:19 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 17:49:19 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
Message-ID: <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>

On Tue, 2 Nov 2021 17:39:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Object.java line 282:
>> 
>>> 280:      * <li>For objects of type {@code Class,} by executing a
>>> 281:      *     static synchronized method of that class.
>>> 282:      * </ul>
>> 
>> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.
>
>> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.
> 
> I think Roger is right and maybe the change to the javadoc could be dropped from this patch.

It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 18:22:12 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 18:22:12 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
Message-ID: <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>

On Tue, 2 Nov 2021 17:45:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> In comments, I think the 'synchronized static 'reads better, the conventional order is for the code.
>> 
>> I think Roger is right and maybe the change to the javadoc could be dropped from this patch.
>
> It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded.

Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev.  

Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prr at openjdk.java.net  Tue Nov  2 18:30:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Nov 2021 18:30:16 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <YGH-CpRv1zM9qRSQzYtt_Gv5I0GOlg7eqx2NgoVAKuI=.e87785f1-d09e-49b1-964b-d283b5aa738b@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit lose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

JFYI a couple of times I've wondered if we regressed on this. I just ran the script on the desktop module and we havea  few instances there too, so I've filed a clean up bug on it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From msheppar at openjdk.java.net  Tue Nov  2 18:52:20 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Tue, 2 Nov 2021 18:52:20 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
Message-ID: <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>

On Tue, 2 Nov 2021 18:17:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> It's tough when a natural language clashes with a programming language. I appreciate that this particular clash might cause discomfort to native English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for adjective order.) That said, consider the following pragmatic aspect. Unless we change the script not to process prose in comments (btw, how would we do that?), every single time we run that script, that particular line in Object.java will need to be tracked and excluded.
>
> Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev.  
> 
> Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him.

"to each his own". I think static synchronized reads best and more natural  than synchronzied static. Also from a semantic point of view as it conveys class level characteristic thus lends static to having a prominence in specified order.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From rriggs at openjdk.java.net  Tue Nov  2 18:52:20 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 2 Nov 2021 18:52:20 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
Message-ID: <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>

On Tue, 2 Nov 2021 18:48:06 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Here's a bit of archaeology. I found the original JDK-8136583 patch, which has moved from where it was in the RFR to https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/. That patch doesn't change Object.java. The RFR thread mentions neither that javadoc change nor any javadoc change for that matter. So either the script was different, or Martin filtered that line (from Object.java) out before creating the webrev.  
>> 
>> Now, in his followup thread on core-libs-dev, http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035273.html, Martin specifically pointed out javadoc changes and said that they seem fine to him.
>
> "to each his own". I think static synchronized reads best and more natural  than synchronzied static. Also from a semantic point of view as it conveys class level characteristic thus lends static to having a prominence in specified order.

Pragmatically, fix the script to ignore those keywords on comment lines.  
Learn Perl, its just a regular expression pattern match and replace expression.

All of the changes have to be manually reviewed by the author and then the reviewers.
Checking unneeded changes is part of every mechanical change.

The text being changed in the javadoc is the *spec*; that deserves special attention in review.

But having seen several reviewers be unmoved by the difference, the real pragmatic view
is to ignore the English.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From duke at openjdk.java.net  Tue Nov  2 19:18:16 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 2 Nov 2021 19:18:16 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:

> 86:  */
> 87: public
> 88: abstract class CallSite {

I think it's better to move all modifiers to the single line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 19:18:15 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 19:18:15 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
 <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
Message-ID: <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>

On Tue, 2 Nov 2021 18:48:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.

I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
 
> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.

I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 19:25:14 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 19:25:14 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>
Message-ID: <vhdidv2oL8fQ22csqEcQeFWHFPdjcq__t1IUzD6X4-E=.99ff41dd-0131-43c5-a66d-ba15309b429a@github.com>

On Tue, 2 Nov 2021 19:15:26 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
>> 
>> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
>> 
>> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
>> 
>>     $ sh ./bin/blessed-modifier-order.sh src/java.base
>> 
>> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
>> 
>> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
>> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
>
> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:
> 
>> 86:  */
>> 87: public
>> 88: abstract class CallSite {
> 
> I think it's better to move all modifiers to the single line.

This is a survivorship bias. This example jumps out at you, because it happens to use missorted modifiers. I'm pretty sure this is not an aberration, but a style. If you want to change that style, you should create a respective JBS issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From rriggs at openjdk.java.net  Tue Nov  2 19:54:10 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 2 Nov 2021 19:54:10 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <yoYcZRSo53PJgOWRV4VK75VVmcr8Aav4wIzHbn-4-94=.79d6c5a1-a6a8-4d0d-af46-0df5ecf5101a@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Keep it as is with the modifiers in the recommended order.  I don't think adding extra typography is warranted.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Tue Nov  2 19:59:14 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Nov 2021 19:59:14 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <vhdidv2oL8fQ22csqEcQeFWHFPdjcq__t1IUzD6X4-E=.99ff41dd-0131-43c5-a66d-ba15309b429a@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <Hx4Imv8fgOgCcoUKs5PtvPAlncZOYusrM7vKU3elSt0=.669e2997-18be-420d-82b4-0c171a49dca7@github.com>
 <vhdidv2oL8fQ22csqEcQeFWHFPdjcq__t1IUzD6X4-E=.99ff41dd-0131-43c5-a66d-ba15309b429a@github.com>
Message-ID: <s2u76YJkLRi3hQZHdoGO52SPSRjCpUU9uiSQ-tTFVvk=.c35ba140-aaa2-408f-afb6-ee366f861cf7@github.com>

On Tue, 2 Nov 2021 19:22:15 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:
>> 
>>> 86:  */
>>> 87: public
>>> 88: abstract class CallSite {
>> 
>> I think it's better to move all modifiers to the single line.
>
> This is a survivorship bias. This example jumps out at you, because it happens to use missorted modifiers. I'm pretty sure this is not an aberration, but a style. If you want to change that style, you should create a respective JBS issue.

I've grepped the code and can now see that a list of modifiers broken by newlines which cannot be explained by line-width concerns is indeed an irregularity. Not only in java.base but also in other modules. Although there aren't many of such cases, I would prefer them to be addressed in a separate cleanup, which you are welcome to pursue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From martin at openjdk.java.net  Tue Nov  2 20:38:21 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 2 Nov 2021 20:38:21 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <CHZWzS1TClQhEeQBLovKK_BILKuVfkXQFXiJLnhyMAs=.e2c9e467-3670-42e3-9252-c78f02daace3@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

Marked as reviewed by martin (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From martin at openjdk.java.net  Tue Nov  2 20:38:21 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 2 Nov 2021 20:38:21 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
 <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
 <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>
Message-ID: <RI-elaMIMqBwnoN3g_iKS9cVHlzfuWndB2t_F03wuiE=.fd1d8ac0-6c26-43da-92bb-9f6d65636f4e@github.com>

On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Pragmatically, fix the script to ignore those keywords on comment lines.  
>> Learn Perl, its just a regular expression pattern match and replace expression.
>> 
>> All of the changes have to be manually reviewed by the author and then the reviewers.
>> Checking unneeded changes is part of every mechanical change.
>> 
>> The text being changed in the javadoc is the *spec*; that deserves special attention in review.
>> 
>> But having seen several reviewers be unmoved by the difference, the real pragmatic view
>> is to ignore the English.
>
>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
> 
> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
>  
>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
> 
> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.

The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)

Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
I don't have a strong feeling either way on changing that file.

I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
I would also not update copyright years for such changes.

It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Wed Nov  3 10:10:20 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Nov 2021 10:10:20 GMT
Subject: <i18n dev> Integrated: 8276348: Use blessed modifier order in
 java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <kYYsea9qLBMAcGUxzLj14jVEJHgc0PqjOSxnojS-YXQ=.1b075e29-e097-47fb-a3f6-e397e990ba53@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

This pull request has now been integrated.

Changeset: 61506336
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/615063364ab6bdd3fa83401745e05b45e13eacdb
Stats:     39 lines in 21 files changed: 0 ins; 0 del; 39 mod

8276348: Use blessed modifier order in java.base

Reviewed-by: dfuchs, darcy, iris, rriggs, martin

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From prappo at openjdk.java.net  Wed Nov  3 11:26:15 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Nov 2021 11:26:15 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <RI-elaMIMqBwnoN3g_iKS9cVHlzfuWndB2t_F03wuiE=.fd1d8ac0-6c26-43da-92bb-9f6d65636f4e@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <C_RH0XOJP4sJikQDtJE6dhbyMr-P-5FfPL6fXyyEkHA=.121ae11c-ed2f-4045-9f1b-b0156adad190@github.com>
 <6Pxo2SojgFwcTVvc4ziRXzJ6B96eq7itxpx8Lf8siYY=.4359b5a4-7596-46bb-92fa-a3d5de8939cc@github.com>
 <PJVIYcE5QnWvPCs_IfETmgzK9WQsjEbxhvOScKITqb4=.6d36b37b-a998-41b3-ab08-bd68d18f7aa2@github.com>
 <nULKrpH6vkOFEDalsd2SYevGhofp4mdKdnXLdB7z_v4=.5ce195c2-1df4-486a-bcd9-cb9326d701f8@github.com>
 <uRHQ57RpAvXKhvHi6WmrxcURnOycF0mm6lYd1j4q4H0=.f5acb908-20ca-410f-8d10-af058ffb8742@github.com>
 <IvtIY6sUGo0ulBN5tOjK_27ibmoqpcsSS_8oUHFq5KQ=.ecb24e2d-ed9d-4b36-8ec1-a32605e4be67@github.com>
 <eXdlDhq0oeTg0j_DSjUF85lVxQRKfl3HarGioOkDzJk=.3f534355-7f83-4323-b3ad-4a491fe5d7b0@github.com>
 <RI-elaMIMqBwnoN3g_iKS9cVHlzfuWndB2t_F03wuiE=.fd1d8ac0-6c26-43da-92bb-9f6d65636f4e@github.com>
Message-ID: <Fz41LrTr1xQWBzD_pay82SIc9MxdY4O5Rl7tOnV1eSw=.1717ed8f-3288-4355-ad02-9133dfdfa8cf@github.com>

On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
>> 
>> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
>>  
>>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
>> 
>> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.
>
> The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)
> 
> Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
> I don't have a strong feeling either way on changing that file.
> 
> I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
> I would also not update copyright years for such changes.
> 
> It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.

One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49

So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.**

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From scolebourne at openjdk.java.net  Wed Nov  3 12:12:22 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 3 Nov 2021 12:12:22 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>
Message-ID: <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>

On Tue, 2 Nov 2021 11:03:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add fallback for values outside the allowable range

Changes requested by scolebourne (Author).

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3158:

> 3156: 
> 3157:         // only instantiated and used if there's ever a value outside the allowed range
> 3158:         private FractionPrinterParser fallback;

This class has to be safe in a multi-threaded environment. I'm not convinced it is safe right now, as the usage doesn't follow the standard racy single check idiom. At a minimum, there needs to be a comment explaining the thread-safety issues.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3266:

> 3264:             if (!field.range().isValidIntValue(value)) {
> 3265:                 if (fallback == null) {
> 3266:                     fallback = new FractionPrinterParser(field, minWidth, maxWidth, decimalPoint, subsequentWidth);

It would be nice to see a test case cover this.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3290:

> 3288:             range.checkValidValue(value, field);
> 3289:             BigDecimal minBD = BigDecimal.valueOf(range.getMinimum());
> 3290:             BigDecimal rangeBD = BigDecimal.valueOf(range.getMaximum()).subtract(minBD).add(BigDecimal.ONE);

I wouldn't be surprised if there is a way to replace the use of `BigDecimal` with calculations using `long`.  Fundamentally, calculations like 15/60 -> 0.25 are not hard, but it depends on whether the exact results can be matched across a wide range of possible inputs.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3544:

> 3542:             BigDecimal valueBD = BigDecimal.valueOf(value).subtract(minBD);
> 3543:             BigDecimal fraction = valueBD.divide(rangeBD, 9, RoundingMode.FLOOR);
> 3544:             // stripTrailingZeros bug

I believe this bug was fixed a while back, so this code could be simplified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 12:20:11 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 12:20:11 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>
 <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>
Message-ID: <nrlMqP28KkxE2sk0TQOKF-IdPJ6B3RrcsfTAyOoNm4M=.4d48a922-4070-4b0d-87ac-c4cd8b45352e@github.com>

On Wed, 3 Nov 2021 12:04:10 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add fallback for values outside the allowable range
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3544:
> 
>> 3542:             BigDecimal valueBD = BigDecimal.valueOf(value).subtract(minBD);
>> 3543:             BigDecimal fraction = valueBD.divide(rangeBD, 9, RoundingMode.FLOOR);
>> 3544:             // stripTrailingZeros bug
> 
> I believe this bug was fixed a while back, so this code could be simplified.

Got a reference to which bug this was and how it manifests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 12:25:15 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 12:25:15 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>
 <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>
Message-ID: <gnGH1IvmzuUXgOmzD-d5fUyWHlZ9UjnjEPIRwIQW_VU=.dd8b34f2-e87a-4b35-ba4a-27d20398b327@github.com>

On Wed, 3 Nov 2021 11:53:52 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add fallback for values outside the allowable range
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3158:
> 
>> 3156: 
>> 3157:         // only instantiated and used if there's ever a value outside the allowed range
>> 3158:         private FractionPrinterParser fallback;
> 
> This class has to be safe in a multi-threaded environment. I'm not convinced it is safe right now, as the usage doesn't follow the standard racy single check idiom. At a minimum, there needs to be a comment explaining the thread-safety issues.

Yes, I'll make sure to read into a local variable.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3266:
> 
>> 3264:             if (!field.range().isValidIntValue(value)) {
>> 3265:                 if (fallback == null) {
>> 3266:                     fallback = new FractionPrinterParser(field, minWidth, maxWidth, decimalPoint, subsequentWidth);
> 
> It would be nice to see a test case cover this.

I'll see to it.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3290:
> 
>> 3288:             range.checkValidValue(value, field);
>> 3289:             BigDecimal minBD = BigDecimal.valueOf(range.getMinimum());
>> 3290:             BigDecimal rangeBD = BigDecimal.valueOf(range.getMaximum()).subtract(minBD).add(BigDecimal.ONE);
> 
> I wouldn't be surprised if there is a way to replace the use of `BigDecimal` with calculations using `long`.  Fundamentally, calculations like 15/60 -> 0.25 are not hard, but it depends on whether the exact results can be matched across a wide range of possible inputs.

I think the main engineering challenge is writing tests that ensure that we don't lose precision on an arbitrary fractional field.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 12:30:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 12:30:49 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v4]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <Pg20R8Z8B05U8D8mQDW7bQS8Vv8bI06uLcImhxeOf40=.ab763046-d397-481a-81c2-928079c75ea7@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Single-check idiom

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/21092323..579b2c01

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=02-03

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 12:47:22 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 12:47:22 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <gnGH1IvmzuUXgOmzD-d5fUyWHlZ9UjnjEPIRwIQW_VU=.dd8b34f2-e87a-4b35-ba4a-27d20398b327@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>
 <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>
 <gnGH1IvmzuUXgOmzD-d5fUyWHlZ9UjnjEPIRwIQW_VU=.dd8b34f2-e87a-4b35-ba4a-27d20398b327@github.com>
Message-ID: <dNc2CBM8vuYO0lBLTxvG-oZKbiJKpPterKgKYQB4Pa8=.3573edba-9722-488e-94e7-7e4e7c6c2253@github.com>

On Wed, 3 Nov 2021 12:21:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3266:
>> 
>>> 3264:             if (!field.range().isValidIntValue(value)) {
>>> 3265:                 if (fallback == null) {
>>> 3266:                     fallback = new FractionPrinterParser(field, minWidth, maxWidth, decimalPoint, subsequentWidth);
>> 
>> It would be nice to see a test case cover this.
>
> I'll see to it.

When adding a test for this I discovered that  `FractionPrinterParser::format` will end up calling `field.range().checkValidValue(value, field)` [here](https://github.com/openjdk/jdk/blob/579b2c017f24f2266abefd35c2b8f28fa7268d93/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java#L3543). This means that the pre-existing implementation does check the value range and throws exceptions when trying to print a `value` outside of the `field` range. 

To mimic the existing behavior we have to do the same check in `NanosPrinterParser::format` and drop the fallback (which would have somewhat nonsensical output for values outside the range, anyhow).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 12:54:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 12:54:49 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v5]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <DkRvsE517du7zh2qTOlvTTp47IM1OSkY9EBlCmmL5uM=.790a83e2-2849-41a8-bf22-7cae073e1f8f@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  FractionPrinterParser checks values to be in range; NanosPrinterParser should do the same. Simplify accordingly.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/579b2c01..f887c0d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=03-04

  Stats: 15 lines in 2 files changed: 0 ins; 14 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 13:14:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 13:14:42 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v6]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <-D-kt2Jcmf0u-szFNE4jrsC6J0XbTgfROTgmQcuiR-4=.ae4ea7e6-5d73-4d57-ab85-1ce137e43645@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add test verifying OOB values throw exception

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/f887c0d7..1d21a1a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=04-05

  Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 13:14:43 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 13:14:43 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <dNc2CBM8vuYO0lBLTxvG-oZKbiJKpPterKgKYQB4Pa8=.3573edba-9722-488e-94e7-7e4e7c6c2253@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>
 <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>
 <gnGH1IvmzuUXgOmzD-d5fUyWHlZ9UjnjEPIRwIQW_VU=.dd8b34f2-e87a-4b35-ba4a-27d20398b327@github.com>
 <dNc2CBM8vuYO0lBLTxvG-oZKbiJKpPterKgKYQB4Pa8=.3573edba-9722-488e-94e7-7e4e7c6c2253@github.com>
Message-ID: <WPthwHpCpQ8FE2Xv8RZ-cX-TK8tiBQe8rDLTkaq-Lwk=.c80b2a7b-3a3f-4ccf-bab5-0d6e9493f3e8@github.com>

On Wed, 3 Nov 2021 12:44:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'll see to it.
>
> When adding a test for this I discovered that  `FractionPrinterParser::format` will end up calling `field.range().checkValidValue(value, field)` [here](https://github.com/openjdk/jdk/blob/579b2c017f24f2266abefd35c2b8f28fa7268d93/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java#L3543). This means that the pre-existing implementation does check the value range and throws exceptions when trying to print a `value` outside of the `field` range. 
> 
> To mimic the existing behavior we have to do the same check in `NanosPrinterParser::format` and drop the fallback (which would have somewhat nonsensical output for values outside the range, anyhow).

Added a test case showing that values that are outside the range throw `DateTimeException`. This passes with and without the patch and mainly documents the pre-existing behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From darcy at openjdk.java.net  Wed Nov  3 13:26:16 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Nov 2021 13:26:16 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v3]
In-Reply-To: <nrlMqP28KkxE2sk0TQOKF-IdPJ6B3RrcsfTAyOoNm4M=.4d48a922-4070-4b0d-87ac-c4cd8b45352e@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <a4fRmQ6TpdRm71ilP64M0YLjIGcKF2oTn3hnQ7x_NnE=.c150fba6-0917-43aa-95f7-56f1126ed844@github.com>
 <ABZmJOY_wSvMgyKm62UyWxf7o3yL9oBKuSnf1deiI1c=.1aa779ef-06db-4253-bad9-b356ff43deb3@github.com>
 <nrlMqP28KkxE2sk0TQOKF-IdPJ6B3RrcsfTAyOoNm4M=.4d48a922-4070-4b0d-87ac-c4cd8b45352e@github.com>
Message-ID: <1vlcv74N50Pr_GJmpf4v7YGXNcXQ1cgIsm3ly5eR2Nk=.51f2155d-87f6-4a59-bb4b-198247409493@github.com>

On Wed, 3 Nov 2021 12:17:09 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3544:
>> 
>>> 3542:             BigDecimal valueBD = BigDecimal.valueOf(value).subtract(minBD);
>>> 3543:             BigDecimal fraction = valueBD.divide(rangeBD, 9, RoundingMode.FLOOR);
>>> 3544:             // stripTrailingZeros bug
>> 
>> I believe this bug was fixed a while back, so this code could be simplified.
>
> Got a reference to which bug this was and how it manifests?

If you're referring to JDK-6480539: "BigDecimal.stripTrailingZeros() has no effect on zero itself ("0.0")", it was fixed in JDK 8.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From prappo at openjdk.java.net  Wed Nov  3 14:14:22 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Nov 2021 14:14:22 GMT
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
Message-ID: <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com>

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse?
> 
> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
> 
> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
> 
>     $ sh ./bin/blessed-modifier-order.sh src/java.base
> 
> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
> 
> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_
> 
> On 3/11/2021 9:26 pm, Pavel Rappo wrote:
> 
> > On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:
> > > > > Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
> > > > 
> > > > 
> > > > I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
> > > > > But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
> > > > 
> > > > 
> > > > I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.
> > > 
> > > 
> > > The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)
> > > Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
> > > I don't have a strong feeling either way on changing that file.
> > > I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
> > > I would also not update copyright years for such changes.
> > > It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.
> > 
> > 
> > One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49
> > So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.**
> 
> Line 281 is (was!) consistent with line 277 because it is distinguishing a synchronized "static method" from a synchronized "instance method". There was no need to make any change to line 281 because of the blessed-order of modifiers as defined for method declarations! This text is just prose. Now for consistency you should change line 277 to refer to a "non-static synchronized method" (as "instance synchronized method" would be truly awful).

Thanks, David. You've provided a clear and convincing argument, and I can see the inconsistency I introduced. I can revert that particular piece back if you think that it would be appropriate. 

That said, this line will have to be filtered out every time the script is run. I could probably provide a more involved script that harnesses the power of AST (com.sun.source.doctree) to try to filter out prose, but it would be impossible to beat the simplicity of the current script; and simplicity is also important.
 
> Line 49 places "static synchronized" in code font, implying that it is referring to the actual method modifiers and as such using the blessed order is appropriate. Line 49 does not need to be "consistent" with line 281. If line 49 used a normal font so the words "static" and "synchronized" were just prose then either order would be perfectly fine in terms of English language, but then you could make a case for having it be consistent with line 281.

I've been always having hard time with modifiers being not enclosed in `@code` in the first place; they are barely English words. Is there really a semantic difference between L49 and L281 such that it warrants the use of `@code` in the former but not in the latter case? Does `synchornized` or `static` in L281 refer to anything other than the like-named Java modifiers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6213

From scolebourne at openjdk.java.net  Wed Nov  3 14:27:14 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 3 Nov 2021 14:27:14 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v6]
In-Reply-To: <-D-kt2Jcmf0u-szFNE4jrsC6J0XbTgfROTgmQcuiR-4=.ae4ea7e6-5d73-4d57-ab85-1ce137e43645@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <-D-kt2Jcmf0u-szFNE4jrsC6J0XbTgfROTgmQcuiR-4=.ae4ea7e6-5d73-4d57-ab85-1ce137e43645@github.com>
Message-ID: <egSc7n_mUAuqmHfwmBKhT-CGDeTufNg8zG2XrdeDwZQ=.0afdad49-c7b7-4124-b013-509d569a7ab5@github.com>

On Wed, 3 Nov 2021 13:14:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test verifying OOB values throw exception

Thanks for adding the new tests, and finding that fraction formatting is more constrained than I thought it was.

I think there is a case for a spec update in `DateTimeFormatterBuilder` to clarify the constraint on the input value (at this point, that seems better than changing the behaviour of fraction formatting). As things stand, the exception that is thrown is not described by the spec. (The spec change could be part of this PR or a separate one).

-------------

Marked as reviewed by scolebourne (Author).

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 15:00:17 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 15:00:17 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v6]
In-Reply-To: <egSc7n_mUAuqmHfwmBKhT-CGDeTufNg8zG2XrdeDwZQ=.0afdad49-c7b7-4124-b013-509d569a7ab5@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <-D-kt2Jcmf0u-szFNE4jrsC6J0XbTgfROTgmQcuiR-4=.ae4ea7e6-5d73-4d57-ab85-1ce137e43645@github.com>
 <egSc7n_mUAuqmHfwmBKhT-CGDeTufNg8zG2XrdeDwZQ=.0afdad49-c7b7-4124-b013-509d569a7ab5@github.com>
Message-ID: <foWdSR8kOVa5fcWx28RbNdxXMkFlox_b7dbEGeuqPEg=.d713c34d-278f-4571-bbcc-d09bd7b3ef30@github.com>

On Wed, 3 Nov 2021 14:24:28 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test verifying OOB values throw exception
>
> Thanks for adding the new tests, and finding that fraction formatting is more constrained than I thought it was.
> 
> I think there is a case for a spec update in `DateTimeFormatterBuilder` to clarify the constraint on the input value (at this point, that seems better than changing the behaviour of fraction formatting). As things stand, the exception that is thrown is not described by the spec. (The spec change could be part of this PR or a separate one).

Thanks for reviewing, @jodastephen! 

I think a spec update sounds good, but I think that should be done in as a follow-up. If you would be willing to provide the wording for such a spec update I can take care of creating a CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 17:23:51 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 17:23:51 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v7]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <p551Qhit9S5SNlqJac4px8CaC_BYevMa1tyddtMB2pY=.091880f7-35d4-4bcd-8191-1c06342554cf@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/1d21a1a5..3ce6d977

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From naoto at openjdk.java.net  Wed Nov  3 17:36:32 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 3 Nov 2021 17:36:32 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v7]
In-Reply-To: <p551Qhit9S5SNlqJac4px8CaC_BYevMa1tyddtMB2pY=.091880f7-35d4-4bcd-8191-1c06342554cf@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <p551Qhit9S5SNlqJac4px8CaC_BYevMa1tyddtMB2pY=.091880f7-35d4-4bcd-8191-1c06342554cf@github.com>
Message-ID: <JN8kDxOKvErDLR_qP8RLaLa-lCGkAMKGAcnH01IY5qY=.bf7ffe1a-1216-4ca7-a88a-435db1adb1c3@github.com>

On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup

Looks good. I'd create a new test case class out of `TestFractionPrinterParser`, as you introduced the new `NanosPrinterParser`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 18:13:18 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 18:13:18 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v7]
In-Reply-To: <JN8kDxOKvErDLR_qP8RLaLa-lCGkAMKGAcnH01IY5qY=.bf7ffe1a-1216-4ca7-a88a-435db1adb1c3@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <p551Qhit9S5SNlqJac4px8CaC_BYevMa1tyddtMB2pY=.091880f7-35d4-4bcd-8191-1c06342554cf@github.com>
 <JN8kDxOKvErDLR_qP8RLaLa-lCGkAMKGAcnH01IY5qY=.bf7ffe1a-1216-4ca7-a88a-435db1adb1c3@github.com>
Message-ID: <v1NxTW8iOqDpfYLwZC0sB6TLmFjnKYpS95T0Cmql7VY=.29f162a5-dc6c-432a-8312-e665fee05395@github.com>

On Wed, 3 Nov 2021 17:33:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good. I'd create a new test case class out of `TestFractionPrinterParser`, as you introduced the new `NanosPrinterParser`.

It was only indirectly a test of `FractionPrinterParser`; it's really a test of `PrinterParsers` built using `appendFraction`, which can be either `FractionPrinterParser` or the new `NanosPrinterParser`. So the name is still somewhat appropriate. We could rename it, but splitting it apart seems excessive.

I realized though that with my changes the test coverage of `FractionPrinterParser` is substantially reduced, since most of the testing is done using `NANO_OF_SECOND`. I'm adding a set of tests using similar input for `MICRO_OF_SECOND` that will exercise `FractionPrinterParser`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From naoto at openjdk.java.net  Wed Nov  3 18:21:21 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 3 Nov 2021 18:21:21 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v7]
In-Reply-To: <p551Qhit9S5SNlqJac4px8CaC_BYevMa1tyddtMB2pY=.091880f7-35d4-4bcd-8191-1c06342554cf@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <p551Qhit9S5SNlqJac4px8CaC_BYevMa1tyddtMB2pY=.091880f7-35d4-4bcd-8191-1c06342554cf@github.com>
Message-ID: <iuXDkRTHagc8tm_q2OoSksSpRyAnHQ2-yhvSsx-V8Yw=.536c19c7-9b53-4245-8e72-38ece97048dc@github.com>

On Wed, 3 Nov 2021 17:23:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup

test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java line 80:

> 78: 
> 79: /**
> 80:  * Test FractionPrinterParser.

OK, then I'd add some comments that the test covers `NanoPrinterParser` as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From naoto at openjdk.java.net  Wed Nov  3 18:44:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 3 Nov 2021 18:44:17 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <P0AuXzsED_Qw17n6662lW0-pxK838w59qmuenfK24Qs=.af9e293a-1d22-4f35-bbc2-2d5254cdc41c@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Firstly, please do NOT rebase your fix, as it will clobber the review history. Use merge instead.
As to the fix, I am not sure consolidating the code into Log.java would be OK as it would introduce module dependency.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From redestad at openjdk.java.net  Wed Nov  3 19:44:35 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 19:44:35 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v8]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <O6mc8dUDo0Sx8dKBDTj0sJP_wQ-e_4wth3kPsqmLikM=.5566c3da-4067-4a2c-b2f7-4cdb01e1f4aa@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add MICRO_OF_SECOND tests to retain proper coverage of FractionPrinterParser

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/3ce6d977..01fce436

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=06-07

  Stats: 107 lines in 2 files changed: 103 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 19:44:36 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 19:44:36 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v7]
In-Reply-To: <iuXDkRTHagc8tm_q2OoSksSpRyAnHQ2-yhvSsx-V8Yw=.536c19c7-9b53-4245-8e72-38ece97048dc@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <p551Qhit9S5SNlqJac4px8CaC_BYevMa1tyddtMB2pY=.091880f7-35d4-4bcd-8191-1c06342554cf@github.com>
 <iuXDkRTHagc8tm_q2OoSksSpRyAnHQ2-yhvSsx-V8Yw=.536c19c7-9b53-4245-8e72-38ece97048dc@github.com>
Message-ID: <3Vwpxtk_gkeAzeOtUv9rjj3ES1LfmiDJGVeN6d5b4eQ=.2e19690d-0eab-4a32-aceb-9436e3aa94d6@github.com>

On Wed, 3 Nov 2021 18:17:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor cleanup
>
> test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java line 80:
> 
>> 78: 
>> 79: /**
>> 80:  * Test FractionPrinterParser.
> 
> OK, then I'd add some comments that the test covers `NanoPrinterParser` as well.

Ok, done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From naoto at openjdk.java.net  Wed Nov  3 19:51:20 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 3 Nov 2021 19:51:20 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v8]
In-Reply-To: <O6mc8dUDo0Sx8dKBDTj0sJP_wQ-e_4wth3kPsqmLikM=.5566c3da-4067-4a2c-b2f7-4cdb01e1f4aa@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <O6mc8dUDo0Sx8dKBDTj0sJP_wQ-e_4wth3kPsqmLikM=.5566c3da-4067-4a2c-b2f7-4cdb01e1f4aa@github.com>
Message-ID: <5FQmdhcJqKVmMZEE3UctduT84G5_FxI-8JKjafEH14k=.9e2e0e44-2760-4f5f-abdf-f72e1f1195e9@github.com>

On Wed, 3 Nov 2021 19:44:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add MICRO_OF_SECOND tests to retain proper coverage of FractionPrinterParser

Oh, just noticed the copyright year->2021 in modified files. Should have noticed before.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 21:48:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 21:48:39 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v9]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <XuMFyBI2VFN_id3gZ_BYC-6G29sdDeMu6Xlk01B_xzU=.fb39f566-3aa9-4dda-971a-1e5c687f0fd7@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyrights

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/01fce436..f6adb5b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=07-08

  Stats: 25 lines in 4 files changed: 22 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 21:57:44 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 21:57:44 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v10]
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <pxFhpROH4JfryZmGNeBpEfNrVSMoAQIBWuEG6nG9G7w=.69f42daa-b1db-472c-ad40-498e71603037@github.com>

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove accidentally committed experimental @Stable (no effect on micros)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6188/files
  - new: https://git.openjdk.java.net/jdk/pull/6188/files/f6adb5b5..b663fe63

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6188&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6188/head:pull/6188

PR: https://git.openjdk.java.net/jdk/pull/6188

From naoto at openjdk.java.net  Wed Nov  3 22:12:19 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 3 Nov 2021 22:12:19 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v10]
In-Reply-To: <pxFhpROH4JfryZmGNeBpEfNrVSMoAQIBWuEG6nG9G7w=.69f42daa-b1db-472c-ad40-498e71603037@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <pxFhpROH4JfryZmGNeBpEfNrVSMoAQIBWuEG6nG9G7w=.69f42daa-b1db-472c-ad40-498e71603037@github.com>
Message-ID: <bbn_mAoEMXu2cDkT5TUhzHJrnZbFjeUGMya3hq6tSgY=.b31286a1-c930-499b-973f-5a774120dca7@github.com>

On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidentally committed experimental @Stable (no effect on micros)

Looks good. Thank you for the fix!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 23:00:21 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 23:00:21 GMT
Subject: <i18n dev> Integrated: 8276220: Reduce excessive allocations in
 DateTimeFormatter
In-Reply-To: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
Message-ID: <Q5EszWV4Er6k2f5_VoVT-0LJtvKl4SmQ5lJHmdm5U0s=.4ca8bf35-3ab9-4868-afd2-9fd0e3563889@github.com>

On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
> 
> When printing times:
> - Avoid turning integral values into `String`s before appending them to the buffer 
> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
> 
> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
> 
> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: ce8c7670
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ce8c76700ba854f43c48d32b068b30e7d78d9d1e
Stats:     564 lines in 4 files changed: 533 ins; 12 del; 19 mod

8276220: Reduce excessive allocations in DateTimeFormatter

Reviewed-by: scolebourne, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From redestad at openjdk.java.net  Wed Nov  3 23:00:19 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Nov 2021 23:00:19 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v10]
In-Reply-To: <pxFhpROH4JfryZmGNeBpEfNrVSMoAQIBWuEG6nG9G7w=.69f42daa-b1db-472c-ad40-498e71603037@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <pxFhpROH4JfryZmGNeBpEfNrVSMoAQIBWuEG6nG9G7w=.69f42daa-b1db-472c-ad40-498e71603037@github.com>
Message-ID: <0EHmJS_GsZhSfN_U1aZVAuSjIfCDcj7EhASGE6tKDC0=.ca7a59d7-3a8f-498f-ada1-7db733cd2fcb@github.com>

On Wed, 3 Nov 2021 21:57:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Prompted by a request from Volkan Yaz?c? I took a look at why the java.time formatters are less efficient for some common patterns than custom formatters in apache-commons and log4j. This patch reduces the gap, without having looked at the third party implementations. 
>> 
>> When printing times:
>> - Avoid turning integral values into `String`s before appending them to the buffer 
>> - Specialize `appendFraction` for `NANO_OF_SECOND` to avoid use of `BigDecimal`
>> 
>> This means a speed-up and reduction in allocations when formatting almost any date or time pattern, and especially so when including sub-second parts (`S-SSSSSSSSS`).
>> 
>> Much of the remaining overhead can be traced to the need to create a `DateTimePrintContext` and adjusting `Instant`s into a `ZonedDateTime` internally. We could likely also win performance by specializing some common patterns.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidentally committed experimental @Stable (no effect on micros)

Thanks, Naoto!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From david.holmes at oracle.com  Thu Nov  4 03:09:34 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Nov 2021 13:09:34 +1000
Subject: <i18n dev> RFR: 8276348: Use blessed modifier order in java.base
In-Reply-To: <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com>
References: <f8FO8T3A6RtEV7vYSgqSNE36Lp-uL1GQbIHliqNBUDQ=.b9698f17-8b95-4190-adaa-dea6a461120b@github.com>
 <4kq1lfBwrSqekbOoZVlvgPROJLfb4SZKUHiySOBEwGs=.a4cb19d9-47da-49b8-8615-c34b3ae155b0@github.com>
Message-ID: <531451b4-b966-e2cb-91ca-52a825c84ad9@oracle.com>

On 4/11/2021 12:14 am, Pavel Rappo wrote:
> On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:
> 
>> This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it en masse?
>>
>> As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spanning 453 files. Since then modifiers have become a bit loose, and it makes sense to re-bless (using the JDK-8136583 terminology) them.
>>
>> This change was produced by running the below command followed by updating the copyright years on the affected files where necessary:
>>
>>      $ sh ./bin/blessed-modifier-order.sh src/java.base
>>
>> The resulting change is much smaller than that of 2015: 39 lines spanning 21 files.
>>
>> [^1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/082987.html (or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-794333365)
>> [^2]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
> 
>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_
>>
>> On 3/11/2021 9:26 pm, Pavel Rappo wrote:
>>
>>> On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz <martin at openjdk.org> wrote:
>>>>>> Pragmatically, fix the script to ignore those keywords on comment lines. Learn Perl, its just a regular expression pattern match and replace expression.
>>>>>
>>>>>
>>>>> I understand in principle how to modify that script to ignore doc comments. The thing I was referring to when said "btw, how would we do that?" was this: not all comment lines are prose. Some of those lines belong to snippets of code, which I guess you would also like to be properly formatted.
>>>>>> But having seen several reviewers be unmoved by the difference, the real pragmatic view is to ignore the English.
>>>>>
>>>>>
>>>>> I'm sorry you feel that way. Would it be okay if I made it clear that those two words are not English adjectives but are special symbols that happen to use Latin script and originate from the English words they resemble? If so, I could enclose each of them in `{@code ... }`. If not, I could drop that particular change from this PR.
>>>>
>>>>
>>>> The blessed-modifier-order.sh script intentionally modifies comments, with the hope of finding code snippets (it did!)
>>>> Probably I manually deleted the change to Object.java back in 2015, to avoid the sort of controversy we're seeing now.
>>>> I don't have a strong feeling either way on changing that file.
>>>> I agree with @pavelrappo  that script-generated changes should not be mixed with manual changes.
>>>> I would also not update copyright years for such changes.
>>>> It's a feature of blessed-modifier-order.sh that all existing formatting is perfectly preserved.
>>>
>>>
>>> One more thing. Please have a look at this other line in the same file; this line was there before the change https://github.com/openjdk/jdk/blob/465d350d0b3cac277a58b9f8ece196c1cde68e80/src/java.base/share/classes/java/lang/Object.java#L49
>>> So before the change, the file was somewhat inconsistent. The change made it consistent. **If one is going to ever revert that controversial part of the change, please update both lines so that the file remains consistent.**
>>
>> Line 281 is (was!) consistent with line 277 because it is distinguishing a synchronized "static method" from a synchronized "instance method". There was no need to make any change to line 281 because of the blessed-order of modifiers as defined for method declarations! This text is just prose. Now for consistency you should change line 277 to refer to a "non-static synchronized method" (as "instance synchronized method" would be truly awful).
> 
> Thanks, David. You've provided a clear and convincing argument, and I can see the inconsistency I introduced. I can revert that particular piece back if you think that it would be appropriate.
> 
> That said, this line will have to be filtered out every time the script is run. I could probably provide a more involved script that harnesses the power of AST (com.sun.source.doctree) to try to filter out prose, but it would be impossible to beat the simplicity of the current script; and simplicity is also important.

Given this is prose, the adjectives should be separated by commas: "a 
synchronized, static method", and "a synchronized, instance method". 
Does that avoid the problem with the script?

>> Line 49 places "static synchronized" in code font, implying that it is referring to the actual method modifiers and as such using the blessed order is appropriate. Line 49 does not need to be "consistent" with line 281. If line 49 used a normal font so the words "static" and "synchronized" were just prose then either order would be perfectly fine in terms of English language, but then you could make a case for having it be consistent with line 281.
> 
> I've been always having hard time with modifiers being not enclosed in `@code` in the first place; they are barely English words. Is there really a semantic difference between L49 and L281 such that it warrants the use of `@code` in the former but not in the latter case? Does `synchornized` or `static` in L281 refer to anything other than the like-named Java modifiers?

Consider this definition:

"A synchronized method is one which must acquire the monitor of the 
Object upon which the method is invoked, and is indicated by applying 
the {@code synchronized} modifier to the method declaration."

Here there is a distinction** between the general notion of a 
"synchronized method" and the "synchronized" modifier. Obviously they 
are strongly related, and often could be used interchangeably, but you 
can also find places where it is more appropriate to use one over the 
other. So yes it is hard, but context can influence the choice: is this 
text referring to the general concept of a synchronized/static method, 
or to the use of the modifier? Line 49 could have gone either way IMO.

** The distinction would be more obvious if Java had an implicit way to 
define synchronized methods. So think about the concept of "package 
private" access - there is no package-private modifier so you 
wouldn't/shouldn't ever write "package private" in code font.

Cheers,
David

P.S. For the book "The Java Programming Language" the authors made a 
very conscious decision to not put the word "synchronized" in code font 
every time it was used in the text, but reserved the code font for 
specific usages. The same applies to other modifiers: static, public, 
etc. Other authors have made similar decisions.

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6213
> 

From naoto at openjdk.java.net  Thu Nov  4 16:16:34 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 4 Nov 2021 16:16:34 GMT
Subject: <i18n dev> RFR: 8276186: Require getAvailableLocales() methods to
 include Locale.ROOT
Message-ID: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>

This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249

-------------

Commit messages:
 - Minor fixup
 - Reflected CSR modifications
 - Added a test case
 - 8276186: Include Locale.ROOT in getAvailableLocales() methods

Changes: https://git.openjdk.java.net/jdk/pull/6258/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6258&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276186
  Stats: 108 lines in 10 files changed: 86 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6258/head:pull/6258

PR: https://git.openjdk.java.net/jdk/pull/6258

From itakiguchi at openjdk.java.net  Thu Nov  4 16:58:14 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 4 Nov 2021 16:58:14 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <P0AuXzsED_Qw17n6662lW0-pxK838w59qmuenfK24Qs=.af9e293a-1d22-4f35-bbc2-2d5254cdc41c@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <P0AuXzsED_Qw17n6662lW0-pxK838w59qmuenfK24Qs=.af9e293a-1d22-4f35-bbc2-2d5254cdc41c@github.com>
Message-ID: <fjnb_N2nCTEUxdKa7zGhdRd6U3UVDDh87UKRquApv6k=.ffa3c221-2afb-4de5-ab8e-ab6b47744f4d@github.com>

On Wed, 3 Nov 2021 18:41:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - Langtools command's usage were grabled on Japanese Windows
>
> Firstly, please do NOT rebase your fix, as it will clobber the review history. Use merge instead.
> As to the fix, I am not sure consolidating the code into Log.java would be OK as it would introduce module dependency.

@naotoj 
I'm sorry about my bad operation.

@jonathan-gibbons 
I appreciate if you give me some suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From duke at openjdk.java.net  Thu Nov  4 17:01:32 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Thu, 4 Nov 2021 17:01:32 GMT
Subject: <i18n dev> RFR: JDK-8276653: Missing row headers in j.l.Character
 docs
Message-ID: <0ZMDH2GwULod8d9mvDRiaaUGoqBVSrcLQZsZF9Y40B0=.83228830-0d41-435a-9e80-a1c38e2a974a@github.com>

The first table is missing row headers, adding them to aid screen readers.

-------------

Commit messages:
 - Added row headers in Character docs

Changes: https://git.openjdk.java.net/jdk/pull/6262/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6262&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276653
  Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6262.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6262/head:pull/6262

PR: https://git.openjdk.java.net/jdk/pull/6262

From naoto at openjdk.java.net  Thu Nov  4 20:03:12 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 4 Nov 2021 20:03:12 GMT
Subject: <i18n dev> RFR: JDK-8276653: Missing row headers in
 j.l.Character docs
In-Reply-To: <0ZMDH2GwULod8d9mvDRiaaUGoqBVSrcLQZsZF9Y40B0=.83228830-0d41-435a-9e80-a1c38e2a974a@github.com>
References: <0ZMDH2GwULod8d9mvDRiaaUGoqBVSrcLQZsZF9Y40B0=.83228830-0d41-435a-9e80-a1c38e2a974a@github.com>
Message-ID: <vrhhnsPelou7vlGF1S3JOCEpTITHtYKbbaFwThIe0S0=.5b666bf9-3c3d-4a10-8218-3edb82e5d96b@github.com>

On Thu, 4 Nov 2021 16:52:48 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> The first table is missing row headers, adding them to aid screen readers.

LGTM.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6262

From duke at openjdk.java.net  Thu Nov  4 21:09:20 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Thu, 4 Nov 2021 21:09:20 GMT
Subject: <i18n dev> Integrated: JDK-8276653: Missing row headers in
 j.l.Character docs
In-Reply-To: <0ZMDH2GwULod8d9mvDRiaaUGoqBVSrcLQZsZF9Y40B0=.83228830-0d41-435a-9e80-a1c38e2a974a@github.com>
References: <0ZMDH2GwULod8d9mvDRiaaUGoqBVSrcLQZsZF9Y40B0=.83228830-0d41-435a-9e80-a1c38e2a974a@github.com>
Message-ID: <EzggifoYGGGw2K9EZgs_Y3JUQzQVg35OIYw9lgX9jro=.33cd18db-2956-4e66-ae45-08b4c5ffba9d@github.com>

On Thu, 4 Nov 2021 16:52:48 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> The first table is missing row headers, adding them to aid screen readers.

This pull request has now been integrated.

Changeset: 8ec80c4b
Author:    Ludvig Janiuk <ludvig.j.janiuk at oracle.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8ec80c4bc1c3169963137b5a16a1b787540a3589
Stats:     11 lines in 1 file changed: 0 ins; 0 del; 11 mod

8276653: Missing row headers in j.l.Character docs

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/6262

From duke at openjdk.java.net  Mon Nov  8 06:08:06 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Nov 2021 06:08:06 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop to
 static nested classes
Message-ID: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>

Non-static classes hold a link to their parent classes, which in many cases can be avoided.
I updated only private and package-private classes. Didn't touch public/protected to not break external code.
Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

-------------

Commit messages:
 - [PATCH] Change nested classes in java.desktop to static nested classes

Changes: https://git.openjdk.java.net/jdk/pull/5943/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5943&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276794
  Stats: 219 lines in 79 files changed: 3 ins; 47 del; 169 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5943.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5943/head:pull/5943

PR: https://git.openjdk.java.net/jdk/pull/5943

From serb at openjdk.java.net  Mon Nov  8 06:08:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Nov 2021 06:08:07 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <xvbPBOA3Ki-QU1wXE8zPURCluZXWpiOQNhRtFlbIwq4=.5e622a74-60f8-46f2-b0db-c0e01ab79350@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

Changes looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5943

From itakiguchi at openjdk.java.net  Mon Nov  8 17:12:34 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 8 Nov 2021 17:12:34 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
 <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com>
Message-ID: <H9on_jHnBVjvsd8i_x8HmH0y9jtMv3vX5aVxWkSll84=.5710f743-2dc2-4ea5-bc53-9b877fbe1b86@github.com>

On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Ichiroh Takiguchi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> This is pretty ugly code to be replicating so many times.
> 
> What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`?  You should not assume that `System.out` and `System.err` will always refer to the console.

Hello @jonathan-gibbons .
I tested -Xstdout option for javac command on Linux and Windows platform.
Output file encoding was UTF-8.
I assume it's expected result.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From scolebourne at openjdk.java.net  Tue Nov  9 11:56:46 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Tue, 9 Nov 2021 11:56:46 GMT
Subject: <i18n dev> RFR: 8276220: Reduce excessive allocations in
 DateTimeFormatter [v10]
In-Reply-To: <0EHmJS_GsZhSfN_U1aZVAuSjIfCDcj7EhASGE6tKDC0=.ca7a59d7-3a8f-498f-ada1-7db733cd2fcb@github.com>
References: <2tv-cQlRiL5Ie5oTe05LcH6kKmXAuQbDRlnOCNqao2k=.3d601ea2-3c1b-4952-a912-67b390cf4424@github.com>
 <pxFhpROH4JfryZmGNeBpEfNrVSMoAQIBWuEG6nG9G7w=.69f42daa-b1db-472c-ad40-498e71603037@github.com>
 <0EHmJS_GsZhSfN_U1aZVAuSjIfCDcj7EhASGE6tKDC0=.ca7a59d7-3a8f-498f-ada1-7db733cd2fcb@github.com>
Message-ID: <H9jmUUsJB2qVMMOlLc4HLMGzJqRtOZZKN07LtURCcH0=.85d2c7dd-04e9-4d39-89d6-55e6957d746b@github.com>

On Wed, 3 Nov 2021 22:55:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove accidentally committed experimental @Stable (no effect on micros)
>
> Thanks, Naoto!

@cl4es For `DateTimeFormatterBuilder ` spec, I propose changing the existing wording slightly

    If the field value in the date-time to be printed is invalid it
    cannot be printed and an exception will be thrown.

to 

    If the field value in the date-time to be printed is outside the
    range of valid values then an exception will be thrown.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6188

From ysatowse at openjdk.java.net  Wed Nov 10 01:13:01 2021
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 10 Nov 2021 01:13:01 GMT
Subject: <i18n dev> RFR: 8276536: Update TimeZoneNames files to follow the
 changes made by JDK-8275766
Message-ID: <0_0aa15Rp4YJqIOAMXP3p0jKSVorLFiYqIMMTpW2Us8=.69beb7fb-a7b1-4aa7-85e2-f115f41909ef@github.com>

Please review this PR to update the TimeZoneNames files.  @naotoj @coffeys 

Some short name changes are not integrated to the JDK. It was detected by the change made in JDK-8275766. 
- Africa/Juba change was done by 2017c 
- Africa/Windhoek changes were done by 2018e 
- Antarctica/Macquarie change was done by 2017a

-------------

Commit messages:
 - Update affected long timezone names with its English name
 - Fix full timezone names of Antarctica/Macquarie
 - 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766

Changes: https://git.openjdk.java.net/jdk/pull/6226/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6226&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276536
  Stats: 88 lines in 11 files changed: 22 ins; 0 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6226.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6226/head:pull/6226

PR: https://git.openjdk.java.net/jdk/pull/6226

From redestad at openjdk.java.net  Wed Nov 10 14:05:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 10 Nov 2021 14:05:52 GMT
Subject: <i18n dev> RFR: 8276947: Clarify how
 DateTimeFormatterBuilder.appendFraction handles value ranges
Message-ID: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>

This changes the specification of `DateTimeFormatterBuilder.appendFraction` to more clearly specify that the formatter will throw an exception if you attempt to print a value outside of the value range of the given field. Changes suggested by @jodastephen in #6188.

-------------

Commit messages:
 - Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges

Changes: https://git.openjdk.java.net/jdk/pull/6335/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6335&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276947
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6335.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6335/head:pull/6335

PR: https://git.openjdk.java.net/jdk/pull/6335

From rriggs at openjdk.java.net  Wed Nov 10 14:49:34 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 10 Nov 2021 14:49:34 GMT
Subject: <i18n dev> RFR: 8276947: Clarify how
 DateTimeFormatterBuilder.appendFraction handles value ranges
In-Reply-To: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
References: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
Message-ID: <LJ_pJ-yNTVWQafQltiYcfBcpsmnORn1_q_20HQcYEtA=.24b0a2cf-025b-4005-b225-01d9ccc1e6f7@github.com>

On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This changes the specification of `DateTimeFormatterBuilder.appendFraction` to more clearly specify that the formatter will throw an exception if you attempt to print a value outside of the value range of the given field. Changes suggested by @jodastephen in #6188.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6335

From naoto at openjdk.java.net  Wed Nov 10 17:42:34 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Nov 2021 17:42:34 GMT
Subject: <i18n dev> RFR: 8276947: Clarify how
 DateTimeFormatterBuilder.appendFraction handles value ranges
In-Reply-To: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
References: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
Message-ID: <qgnRbIEkFQs6oYnmfV9UJTkGVHLXooeavKGJoKfq-KU=.47aa771b-7b58-424e-bd08-34dce756c335@github.com>

On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This changes the specification of `DateTimeFormatterBuilder.appendFraction` to more clearly specify that the formatter will throw an exception if you attempt to print a value outside of the value range of the given field. Changes suggested by @jodastephen in #6188.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6335

From naoto at openjdk.java.net  Wed Nov 10 18:33:33 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Nov 2021 18:33:33 GMT
Subject: <i18n dev> RFR: 8276536: Update TimeZoneNames files to follow
 the changes made by JDK-8275766
In-Reply-To: <0_0aa15Rp4YJqIOAMXP3p0jKSVorLFiYqIMMTpW2Us8=.69beb7fb-a7b1-4aa7-85e2-f115f41909ef@github.com>
References: <0_0aa15Rp4YJqIOAMXP3p0jKSVorLFiYqIMMTpW2Us8=.69beb7fb-a7b1-4aa7-85e2-f115f41909ef@github.com>
Message-ID: <hY54CxZzgW2ZSCno6RNoFePu65nPO5E9r2gb21wQl18=.e554150a-64b1-4cd2-8b4d-6adf4db18667@github.com>

On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR to update the TimeZoneNames files.  @naotoj @coffeys 
> 
> Some short name changes are not integrated to the JDK. It was detected by the change made in JDK-8275766. 
> - Africa/Juba change was done by 2017c 
> - Africa/Windhoek changes were done by 2018e 
> - Antarctica/Macquarie change was done by 2017a

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6226

From prappo at openjdk.java.net  Wed Nov 10 18:37:34 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 10 Nov 2021 18:37:34 GMT
Subject: <i18n dev> RFR: 8276186: Require getAvailableLocales() methods
 to include Locale.ROOT
In-Reply-To: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
References: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
Message-ID: <roXD1c431n2CJ8uDTwh4Ypp93d0J7VPSyhI4eLG1NIg=.c32c9732-37f9-4c4b-a581-1719ece5da96@github.com>

On Thu, 4 Nov 2021 16:07:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249

The change to the existing source looks good, and the new test looks beautiful. Thanks for doing this.

src/java.base/share/classes/java/time/format/DecimalStyle.java line 118:

> 116:      * Lists all the locales that are supported.
> 117:      * <p>
> 118:      * At a minimum, the returned Set must contain a {@code Locale} instance equal to

A nit, really. Consider applying either of these suggestions:
Suggestion:

     * At a minimum, the returned {@code Set} must contain a {@code Locale} instance equal to

Suggestion:

     * At a minimum, the returned set must contain a {@code Locale} instance equal to

-------------

Marked as reviewed by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6258

From naoto at openjdk.java.net  Wed Nov 10 19:05:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Nov 2021 19:05:17 GMT
Subject: <i18n dev> RFR: 8276186: Require getAvailableLocales() methods
 to include Locale.ROOT [v2]
In-Reply-To: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
References: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
Message-ID: <6CtmD4QtdSiBqHFYoNzl_wBAmsZarHuZMPd16MJWE2U=.eff3ac2f-1ced-41b2-81e5-f811b94a94bf@github.com>

> This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Using @code tag for `Set`.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6258/files
  - new: https://git.openjdk.java.net/jdk/pull/6258/files/1a611bd5..5bdd4917

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6258&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6258&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6258.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6258/head:pull/6258

PR: https://git.openjdk.java.net/jdk/pull/6258

From naoto at openjdk.java.net  Wed Nov 10 19:05:21 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Nov 2021 19:05:21 GMT
Subject: <i18n dev> RFR: 8276186: Require getAvailableLocales() methods
 to include Locale.ROOT [v2]
In-Reply-To: <roXD1c431n2CJ8uDTwh4Ypp93d0J7VPSyhI4eLG1NIg=.c32c9732-37f9-4c4b-a581-1719ece5da96@github.com>
References: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
 <roXD1c431n2CJ8uDTwh4Ypp93d0J7VPSyhI4eLG1NIg=.c32c9732-37f9-4c4b-a581-1719ece5da96@github.com>
Message-ID: <tHxBEqWDHLP2mLpmn2DW0Oo7-rdB3DLKDf3Sm5qnNf0=.dbe62e0d-625f-4e37-a0dd-f66674a9d540@github.com>

On Wed, 10 Nov 2021 18:29:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using @code tag for `Set`.
>
> src/java.base/share/classes/java/time/format/DecimalStyle.java line 118:
> 
>> 116:      * Lists all the locales that are supported.
>> 117:      * <p>
>> 118:      * At a minimum, the returned Set must contain a {@code Locale} instance equal to
> 
> A nit, really. Consider applying either of these suggestions:
> Suggestion:
> 
>      * At a minimum, the returned {@code Set} must contain a {@code Locale} instance equal to
> 
> Suggestion:
> 
>      * At a minimum, the returned set must contain a {@code Locale} instance equal to

Thanks. Adopted the former suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6258

From smarks at openjdk.java.net  Wed Nov 10 19:07:47 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 10 Nov 2021 19:07:47 GMT
Subject: <i18n dev> RFR: 8276186: Require getAvailableLocales() methods
 to include Locale.ROOT [v2]
In-Reply-To: <6CtmD4QtdSiBqHFYoNzl_wBAmsZarHuZMPd16MJWE2U=.eff3ac2f-1ced-41b2-81e5-f811b94a94bf@github.com>
References: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
 <6CtmD4QtdSiBqHFYoNzl_wBAmsZarHuZMPd16MJWE2U=.eff3ac2f-1ced-41b2-81e5-f811b94a94bf@github.com>
Message-ID: <h1jXzuUF07HP8TV_gsiY2sD5iopVi3ROlq1mU9ap9lc=.cda98dee-bfc3-4e6b-8123-3a2cf6fe6808@github.com>

On Wed, 10 Nov 2021 19:05:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using @code tag for `Set`.

Nice use of MethodHandles.lookup() in the test.

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6258

From jjg at openjdk.java.net  Wed Nov 10 19:19:36 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 19:19:36 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

I strongly dislike this proposed changeset. In my opinion, the original change that has provoked the changes here is a bad/incompatible change, and should maybe be reconsidered. The fact that a change in the Java runtime has triggered the need for so many changes in application-style code is some sort of "canary in the coalmine".

Generally, the issue is related to the fact that we wrap a PrintStream in a PrintWriter ... and, if I understand correctly, the writer ends up with the wrong character encoding. Is it possible to change PrintWriter and/or PrintStream so that the correct underlying encoding used by the PrintStream is also used by the PrintWriter. That way, all existing uses where a PrintWriter wraps a PrintStream would continue to work without any modification.

cc: @jddarcy with his CSR hat on, for the compatibility issues relating to the issue that caused the problems being addressed here.

-------------

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5771

From jjg at openjdk.java.net  Wed Nov 10 19:44:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 19:44:42 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi 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 five additional commits since the last revision:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Informally, I suggest one of the following:

1.  `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`  should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default.

2. or, add new overloads for  `PrintStream(PrintStream)` and `PrintStream(PrintStream, boolean)`  that are defined to use the character encoding from the `PrintStream` arg.


I note that `PrintStream` does not expose a "getter" for the encoding. That seems like a bug in itself, but even without fixing that, `PrintWriter` ought to be able to access the encoding "behind the scenes".

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From alanb at openjdk.java.net  Wed Nov 10 19:49:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 10 Nov 2021 19:49:45 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>
Message-ID: <P0j7oEBawdHQfuKSBVkH_RDBz63_7KuVrKSEd0nqloY=.a674c502-2cbb-4287-9b15-60aae71e8bb6@github.com>

On Wed, 10 Nov 2021 19:16:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Generally, the issue is related to the fact that we wrap a PrintStream in a PrintWriter ... and, if I understand correctly, the writer ends up with the wrong character encoding. Is it possible to change PrintWriter and/or PrintStream so that the correct underlying encoding used by the PrintStream is also used by the PrintWriter. That way, all existing uses where a PrintWriter wraps a PrintStream would continue to work without any modification.

JEP 400 has moved the JDK to using UTF-8 as the default charset, a long overdue change. So if you create a PrintStream or a PrintWriter without specifying the charset then it will default to UTF-8. The issue that I think we have with javac and a few other tools is that they are creating PrintWriters on PrintStreams where the underlying streams are stdout/stderr and so using the native encoding.  There was exploration into special casing this scenario during JEP 400 that was rejected because it complicates the spec and may not be feasible in cases where there are many layers in the onion. If there is resistance to fixing the tools then we might have to re-visit this. Naoto may have more to say on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From iris at openjdk.java.net  Wed Nov 10 19:50:36 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 10 Nov 2021 19:50:36 GMT
Subject: <i18n dev> RFR: 8276186: Require getAvailableLocales() methods
 to include Locale.ROOT [v2]
In-Reply-To: <6CtmD4QtdSiBqHFYoNzl_wBAmsZarHuZMPd16MJWE2U=.eff3ac2f-1ced-41b2-81e5-f811b94a94bf@github.com>
References: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
 <6CtmD4QtdSiBqHFYoNzl_wBAmsZarHuZMPd16MJWE2U=.eff3ac2f-1ced-41b2-81e5-f811b94a94bf@github.com>
Message-ID: <MihEZvsmKCB39vOtC0qHM5rp-awJl4_z1I3pIPnxDr4=.b908b855-e222-454f-ad09-e67ac8c19e40@github.com>

On Wed, 10 Nov 2021 19:05:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using @code tag for `Set`.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6258

From alanb at openjdk.java.net  Wed Nov 10 20:03:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 10 Nov 2021 20:03:38 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>
Message-ID: <yj5tQPFV9FTLJ1Muetf7awjcvN1Pey9UTFUsuwIPRl8=.35081123-9cf7-4290-9919-b8dc84725410@github.com>

On Wed, 10 Nov 2021 19:41:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`  should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default.

I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From naoto at openjdk.java.net  Wed Nov 10 20:55:43 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Nov 2021 20:55:43 GMT
Subject: <i18n dev> Integrated: 8276186: Require getAvailableLocales()
 methods to include Locale.ROOT
In-Reply-To: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
References: <tjug6LACJFuO4h1OigKG5CQpQ0eYRE4bUzt1WKiuSls=.39c7d161-1a54-41f9-bd73-67b8cc241aed@github.com>
Message-ID: <IWIMD8wsu3WaRquxzb99nDravOyOI9vN7i1bj5IFN44=.637491f5-7d61-43b0-b52c-ded749120c79@github.com>

On Thu, 4 Nov 2021 16:07:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This fix is to require to include `Locale.ROOT` in the returned arrays/set from `getAvailableLocales()` methods in various locale-sensitive classes. The implementation has been including `Locale.ROOT` since its inception, it is simply a doc clarification (+ a test case verifying it). Corresponding CSR has also been drafted: https://bugs.openjdk.java.net/browse/JDK-8276249

This pull request has now been integrated.

Changeset: 0c409cac
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c409cac789f1b1d21e09a65db36bb6c72c569db
Stats:     108 lines in 10 files changed: 86 ins; 0 del; 22 mod

8276186: Require getAvailableLocales() methods to include Locale.ROOT

Reviewed-by: prappo, smarks, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/6258

From coffeys at openjdk.java.net  Wed Nov 10 21:05:34 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 10 Nov 2021 21:05:34 GMT
Subject: <i18n dev> RFR: 8276536: Update TimeZoneNames files to follow
 the changes made by JDK-8275766
In-Reply-To: <0_0aa15Rp4YJqIOAMXP3p0jKSVorLFiYqIMMTpW2Us8=.69beb7fb-a7b1-4aa7-85e2-f115f41909ef@github.com>
References: <0_0aa15Rp4YJqIOAMXP3p0jKSVorLFiYqIMMTpW2Us8=.69beb7fb-a7b1-4aa7-85e2-f115f41909ef@github.com>
Message-ID: <S_bvAseKGzJzH20h8i-ad0LCCC4nxedq4002_5UQPec=.b9e91619-2bfe-4b17-947a-5a847dba230f@github.com>

On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR to update the TimeZoneNames files.  @naotoj @coffeys 
> 
> Some short name changes are not integrated to the JDK. It was detected by the change made in JDK-8275766. 
> - Africa/Juba change was done by 2017c 
> - Africa/Windhoek changes were done by 2018e 
> - Antarctica/Macquarie change was done by 2017a

Marked as reviewed by coffeys (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6226

From naoto at openjdk.java.net  Wed Nov 10 21:22:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Nov 2021 21:22:35 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From jjg at openjdk.java.net  Wed Nov 10 21:47:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 21:47:34 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <yj5tQPFV9FTLJ1Muetf7awjcvN1Pey9UTFUsuwIPRl8=.35081123-9cf7-4290-9919-b8dc84725410@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>
 <yj5tQPFV9FTLJ1Muetf7awjcvN1Pey9UTFUsuwIPRl8=.35081123-9cf7-4290-9919-b8dc84725410@github.com>
Message-ID: <ElJGwUEHP-L5sxPuUE7GP89NICEi0cOQBtOMUO1V-Aw=.def3aad5-bedd-43de-b01b-6629e139946a@github.com>

On Wed, 10 Nov 2021 20:00:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`  should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default.
> 
> I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output.

Yes, sorry for the confusion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From jjg at openjdk.java.net  Wed Nov 10 21:55:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 21:55:42 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <P0j7oEBawdHQfuKSBVkH_RDBz63_7KuVrKSEd0nqloY=.a674c502-2cbb-4287-9b15-60aae71e8bb6@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>
 <P0j7oEBawdHQfuKSBVkH_RDBz63_7KuVrKSEd0nqloY=.a674c502-2cbb-4287-9b15-60aae71e8bb6@github.com>
Message-ID: <8ugE0AF10_pPZDg1PoaezIIz1m-VG12m24NqmPcQHOA=.a437b180-fa0b-43f3-9c32-84179893a4dd@github.com>

On Wed, 10 Nov 2021 19:46:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  If there is resistance to fixing the tools then we might have to re-visit this.

It's not just the JDK tools that are an issue. I think that wrapping some PrintStream into a PrintWriter is a common enough idiom that it is not reasonable to fix all occurrences -- i.e. including those outside of JDK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From ysatowse at openjdk.java.net  Thu Nov 11 01:42:37 2021
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 11 Nov 2021 01:42:37 GMT
Subject: <i18n dev> Integrated: 8276536: Update TimeZoneNames files to
 follow the changes made by JDK-8275766
In-Reply-To: <0_0aa15Rp4YJqIOAMXP3p0jKSVorLFiYqIMMTpW2Us8=.69beb7fb-a7b1-4aa7-85e2-f115f41909ef@github.com>
References: <0_0aa15Rp4YJqIOAMXP3p0jKSVorLFiYqIMMTpW2Us8=.69beb7fb-a7b1-4aa7-85e2-f115f41909ef@github.com>
Message-ID: <q8-F8WWPat6wLpwf16zHFQ963BpqRyhNBNzUEiHf-WY=.b9275ad1-d0ec-4a4e-9e2f-c6df4353a3d3@github.com>

On Wed, 3 Nov 2021 07:05:08 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR to update the TimeZoneNames files.  @naotoj @coffeys 
> 
> Some short name changes are not integrated to the JDK. It was detected by the change made in JDK-8275766. 
> - Africa/Juba change was done by 2017c 
> - Africa/Windhoek changes were done by 2018e 
> - Antarctica/Macquarie change was done by 2017a

This pull request has now been integrated.

Changeset: ad3be04d
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ad3be04d2ac84836e393d696ff03ddfe72779094
Stats:     88 lines in 11 files changed: 22 ins; 0 del; 66 mod

8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766

Reviewed-by: naoto, coffeys

-------------

PR: https://git.openjdk.java.net/jdk/pull/6226

From redestad at openjdk.java.net  Thu Nov 11 20:37:44 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Nov 2021 20:37:44 GMT
Subject: <i18n dev> RFR: 8276947: Clarify how
 DateTimeFormatterBuilder.appendFraction handles value ranges
In-Reply-To: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
References: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
Message-ID: <IVUQ8MlG27GZqhzkKAUOxxQC7sIN5afRFnzW_lzK-mI=.41b83bc6-0573-4947-9da8-dd82432bedc5@github.com>

On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This changes the specification of `DateTimeFormatterBuilder.appendFraction` to more clearly specify that the formatter will throw an exception if you attempt to print a value outside of the value range of the given field. Changes suggested by @jodastephen in #6188.

Thanks Roger and Naoto. CSR has been filed and approved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6335

From redestad at openjdk.java.net  Thu Nov 11 20:40:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Nov 2021 20:40:39 GMT
Subject: <i18n dev> Integrated: 8276947: Clarify how
 DateTimeFormatterBuilder.appendFraction handles value ranges
In-Reply-To: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
References: <_3hNrBAfKpjxTflIiQ9yFO7obdnXglcUA3q3iYoA82U=.82b14950-c505-44c3-bfb1-5ac8eeeeeb92@github.com>
Message-ID: <GvqQy5APhNP3gequiO0UiOrDSDWFyKPFPS075cNEx0M=.8333a086-4da6-4cd2-8375-980ce595d13d@github.com>

On Wed, 10 Nov 2021 13:57:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This changes the specification of `DateTimeFormatterBuilder.appendFraction` to more clearly specify that the formatter will throw an exception if you attempt to print a value outside of the value range of the given field. Changes suggested by @jodastephen in #6188.

This pull request has now been integrated.

Changeset: 0ca0acf6
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0ca0acf63cb5cec4c62a9948956a04822d6f74a5
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges

Reviewed-by: rriggs, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/6335

From duke at openjdk.java.net  Thu Nov 11 22:30:39 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 11 Nov 2021 22:30:39 GMT
Subject: <i18n dev> Integrated: 8275197: Remove unused fields in
 ThaiBuddhistChronology
In-Reply-To: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
References: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
Message-ID: <sEgb17T156ZvSlIjmk63FEN5LxNr3veWFN8G3NenpOQ=.0b1cd540-e076-4de1-b9d3-c1981a271fea@github.com>

On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Remove 3 unused HashMap's.
> Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html
> I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155

This pull request has now been integrated.

Changeset: 1e941ded
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e941dedad0ff6282ca4c1d2d71512974c97fc5e
Stats:     37 lines in 1 file changed: 0 ins; 36 del; 1 mod

8275197: Remove unused fields in ThaiBuddhistChronology

Reviewed-by: naoto, rriggs, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/5917

From duke at openjdk.java.net  Fri Nov 12 16:33:36 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Nov 2021 16:33:36 GMT
Subject: <i18n dev> Integrated: 8274835: Remove unnecessary castings in
 java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <O0Owu_mCiF4GNzuc00dLjhWKMTSBbvJv6pRTUj4jntU=.29028df9-b4a1-47ab-be53-844b31dff671@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

This pull request has now been integrated.

Changeset: 5a2452c8
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a2452c80e64b8b7a1799caa1a8a6e9e6a7dab6d
Stats:     36 lines in 15 files changed: 1 ins; 4 del; 31 mod

8274835: Remove unnecessary castings in java.base

Reviewed-by: mullan, naoto, lancea, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5454

From itakiguchi at openjdk.java.net  Sun Nov 14 16:48:39 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 14 Nov 2021 16:48:39 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
Message-ID: <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>

On Wed, 10 Nov 2021 21:19:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - Langtools command's usage were grabled on Japanese Windows
>
> Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970

Hello @naotoj .
For PrintStream.getCharset(), following changes may be required.

+++ src/java.base/share/classes/java/io/OutputStreamWriter.java
+    Charset getCharset() {
+        return se.getCharset();
+    }

+++ src/java.base/share/classes/java/io/PrintStream.java
+    public Charset getCharset() {
+        return charOut.getCharset();
+    }

+++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java
+    public Charset getCharset() {
+        return cs;
+    }

For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler.
We need to use reflection, like:

+++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
+    private static Charset getCharset(PrintStream ps) {
+        try {
+            Method getCharset = PrintStream.class.getDeclaredMethod("getCharset");
+            return (Charset)getCharset.invoke(ps);
+        } catch (Exception e) {
+            return Charset.defaultCharset();
+        }
+    }

If we add following constructors against PrintWriter, we just change javap and jshell code.
But I cannot evaluate this code changes.

+++ src/java.base/share/classes/java/io/PrintWriter.java
+    public PrintWriter(PrintStream ps) {
+       this((OutputStream)ps, false, ps.getCharset());
+    }
+    public PrintWriter(PrintStream ps, boolean autoFlush) {
+       this((OutputStream)ps, autoFlush, ps.getCharset());
+    }

I really appreciate if you handle this kind of code change via JEP-400.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From pushkar.nk at in.ibm.com  Mon Nov 15 17:53:57 2021
From: pushkar.nk at in.ibm.com (Pushkar N Kulkarni)
Date: Mon, 15 Nov 2021 17:53:57 +0000
Subject: <i18n dev> Supporting charset GB18030-2005
Message-ID: <OFD925145F.DBED3928-ON0025878E.006236E8-0025878E.006252FD@ibm.com>


Hi there,


OpenJDK currently supports version 2000 of the GB18030 (https://en.wikipedia.org/wiki/GB_18030) character set viz. GB18030-2000. The character mappings corresponding to Unicode codepoints '\u1E3F' and '\uE7C7' were swapped in a new version of the character set named GB18030-2005. I learn that this corrected a mistake in version 2000. 

OpenJDK does not support version 2005 as yet. Can someone please help me with reasons for the same, if any?

We do have users requesting for 2005 support. While Linux (RHEL 7/8) has moved to supporting GB18030-2005 via glibc, Windows 10 and AIX 7.2 still have GB18030-2000 base. That means OpenJDK cannot move to GB18030-2005 base as yet. However, we can support both the versions until all the supported platforms move to GB18030-2005 base. Would that be an acceptable proposition?

If we can have an enhancement request opened, I'd be glad to contribute the GB18030-2005 charset implementation.

Thanks!
Pushkar N Kulkarni,
Developer, IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra



From serb at openjdk.java.net  Mon Nov 15 19:06:35 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 15 Nov 2021 19:06:35 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <I5HN2el5PXIfHuXN9QkVluBzNFGKLk3fFIsBDNSvinY=.5e36613d-f1a8-4cf0-b56e-b148b5bee623@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5943

From jjg at openjdk.java.net  Mon Nov 15 20:00:44 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 15 Nov 2021 20:00:44 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <mTywmbEWG4IgwxClYs8_pT_vZkse_Ey46SYv8ed3yoc=.7970b43c-fb38-4013-a388-05b440cc08e7@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi 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 five additional commits since the last revision:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Generally, I think it would be a good goal for JEP-400 to not require any source-code changes to any use-sites, at least for this common idiom of wrapping a `PrintStream` in a `PrintWriter`.  While we may have the ability to change JDK use-sites, we do not have the ability to change any usages outside of JDK, and we should try not to break those usages in the way that the JDK tools have been broken.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From naoto at openjdk.java.net  Mon Nov 15 21:18:34 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 15 Nov 2021 21:18:34 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <MSRlG2axHrLwJyzGDVFhYzuoenyO1WLsYpyJ9QhaaVw=.cc8352ba-9a4d-4b2d-ac19-8959c2061e1a@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

The gist of the issue is that `PrintWriter` (w/o explicit charset) uses the default charset, ignoring `PrintStream`'s charset. So  it basically is irrelevant of JEP400, but apparently, JEP400 made it visible as it keeps the System.out/err encoding in `native.encoding` while changing the default to `UTF-8`.
I am now in the process of creating a PR for the issue JDK-8276970, and will submit it shortly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From Alan.Bateman at oracle.com  Tue Nov 16 10:29:35 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Nov 2021 10:29:35 +0000
Subject: <i18n dev> Supporting charset GB18030-2005
In-Reply-To: <OFD925145F.DBED3928-ON0025878E.006236E8-0025878E.006252FD@ibm.com>
References: <OFD925145F.DBED3928-ON0025878E.006236E8-0025878E.006252FD@ibm.com>
Message-ID: <6c24853a-9b3b-5030-61c4-96194c6eeccd@oracle.com>

On 15/11/2021 17:53, Pushkar N Kulkarni wrote:
> Hi there,
>
>
> OpenJDK currently supports version 2000 of the GB18030 (https://en.wikipedia.org/wiki/GB_18030) character set viz. GB18030-2000. The character mappings corresponding to Unicode codepoints '\u1E3F' and '\uE7C7' were swapped in a new version of the character set named GB18030-2005. I learn that this corrected a mistake in version 2000.
>
> OpenJDK does not support version 2005 as yet. Can someone please help me with reasons for the same, if any?
>
> We do have users requesting for 2005 support. While Linux (RHEL 7/8) has moved to supporting GB18030-2005 via glibc, Windows 10 and AIX 7.2 still have GB18030-2000 base. That means OpenJDK cannot move to GB18030-2005 base as yet. However, we can support both the versions until all the supported platforms move to GB18030-2005 base. Would that be an acceptable proposition?
>
> If we can have an enhancement request opened, I'd be glad to contribute the GB18030-2005 charset implementation.

If I read this correctly, then your proposal is for GB18030 to continue 
to be GB18030-2000 but you would introduce a new charset GB18030 map to 
GB18030-2005 for the new version. Are you also proposing a system 
property or some means to have GB18030 be GB18030-2005 until the time is 
right to make it the default?

-Alan

From pushkar.nk at in.ibm.com  Tue Nov 16 19:02:08 2021
From: pushkar.nk at in.ibm.com (Pushkar N Kulkarni)
Date: Tue, 16 Nov 2021 19:02:08 +0000
Subject: <i18n dev> Supporting charset GB18030-2005
In-Reply-To: <6c24853a-9b3b-5030-61c4-96194c6eeccd@oracle.com>
References: <6c24853a-9b3b-5030-61c4-96194c6eeccd@oracle.com>,
 <OFD925145F.DBED3928-ON0025878E.006236E8-0025878E.006252FD@ibm.com>
Message-ID: <OFB336D73A.F63FD7C9-ON0025878F.00689105-0025878F.00689108@ibm.com>

Hi Alan,

Thanks. I appreciate your response.

Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to add a new character set with the name GB13080-2005. But I guess your suggestion of internally mapping one of the two versions (2000 or 2005) to "GB13080", based on the value of a new System property,  version 2000 being the default, could be a better approach.

Pushkar N Kulkarni,
Developer, IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra



-----"Alan Bateman" <Alan.Bateman at oracle.com> wrote: -----
To: "Pushkar N Kulkarni" <pushkar.nk at in.ibm.com>, i18n-dev at openjdk.java.net
From: "Alan Bateman" <Alan.Bateman at oracle.com>
Date: 11/16/2021 04:00PM
Cc: core-libs-dev at openjdk.java.net
Subject: [EXTERNAL] Re: <i18n dev> Supporting charset GB18030-2005

On 15/11/2021 17:53, Pushkar N Kulkarni wrote:
> Hi there,
>
>
> OpenJDK currently supports version 2000 of the GB18030 (https://en.wikipedia.org/wiki/GB_18030 ) character set viz. GB18030-2000. The character mappings corresponding to Unicode codepoints '\u1E3F' and '\uE7C7' were swapped in a new version of the character set named GB18030-2005. I learn that this corrected a mistake in version 2000.
>
> OpenJDK does not support version 2005 as yet. Can someone please help me with reasons for the same, if any?
>
> We do have users requesting for 2005 support. While Linux (RHEL 7/8) has moved to supporting GB18030-2005 via glibc, Windows 10 and AIX 7.2 still have GB18030-2000 base. That means OpenJDK cannot move to GB18030-2005 base as yet. However, we can support both the versions until all the supported platforms move to GB18030-2005 base. Would that be an acceptable proposition?
>
> If we can have an enhancement request opened, I'd be glad to contribute the GB18030-2005 charset implementation.

If I read this correctly, then your proposal is for GB18030 to continue 
to be GB18030-2000 but you would introduce a new charset GB18030 map to 
GB18030-2005 for the new version. Are you also proposing a system 
property or some means to have GB18030 be GB18030-2005 until the time is 
right to make it the default?

-Alan


From Alan.Bateman at oracle.com  Wed Nov 17 11:49:50 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Nov 2021 11:49:50 +0000
Subject: <i18n dev> Supporting charset GB18030-2005
In-Reply-To: <OFB336D73A.F63FD7C9-ON0025878F.00689105-0025878F.00689108@ibm.com>
References: <6c24853a-9b3b-5030-61c4-96194c6eeccd@oracle.com>
 <OFD925145F.DBED3928-ON0025878E.006236E8-0025878E.006252FD@ibm.com>
 <OFB336D73A.F63FD7C9-ON0025878F.00689105-0025878F.00689108@ibm.com>
Message-ID: <8e988871-bad1-d919-7afe-a23aa3d366fe@oracle.com>

On 16/11/2021 19:02, Pushkar N Kulkarni wrote:
> Hi Alan,
>
> Thanks. I appreciate your response.
>
> Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to add a new character set with the name GB13080-2005. But I guess your suggestion of internally mapping one of the two versions (2000 or 2005) to "GB13080", based on the value of a new System property,  version 2000 being the default, could be a better approach.
We could start out by adding GB18030-2005, as you suggest.

A potential next step would be to rename GB13080 to GB13080-2000, with 
"GB13080" as an alias. As it stands, the charset name is "GB13080" with 
"GB13080-2000" as an alias so it should be compatible with code that use 
Charset.forName. It's possible this change may be noticed by code that 
does lookups in other ways or expects getName to be match the name 
specified to forName so that would be a feature release only change.

If there is a strong need then it should be feasible to have a system 
property to change GB13080 but maybe it's not needed in the short/medium 
term when some operating systems are still using -2000.

-Alan

From aivanov at openjdk.java.net  Wed Nov 17 14:54:37 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 17 Nov 2021 14:54:37 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <usZ8Abd8HlU0tdT7MBFIw71TUOyvmvQ6RWlTrLumkH4=.f98b22c7-78ec-4c17-bbea-a8d9314b7b8d@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

There are a couple of classes where a space before the opening brace in the class declaration can be added: you're changing the declaration anyway. By adding the space there, the declaration will follow Java Code Conventions.

In some cases, you're remove unused imports. Does it make sense to convert all wildcard imports into explicit imports? I noticed wildcards imports have been replaced with explicit ones in JDK source code recently.

I do not suggest changing the imports in all the modified classes, only those where imports are modified.

For example, you're removing redundant imports in `XTextFieldPeer.java`, there are quite a few of them. There are also lots of explicit imports in the file. I think expanding wildcard imports to explicit ones and sorting them will make the file cleaner.

Another example where such a change seems appropriate is `XTextAreaPeer.java` where Swing classes are imported class by class but `java.awt.*` by wildcard.

What do you think?

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java line 3949:

> 3947:     @SuppressWarnings("serial") // Superclass is not serializable across versions
> 3948:     private static class ScrollableTabButton extends BasicArrowButton implements UIResource,
> 3949:                                                                             SwingConstants {

Maybe, wrap the line before implements?

src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 2300:

> 2298: 
> 2299: @SuppressWarnings("serial") // JDK-implementation class
> 2300:  static class PrintToFileErrorDialog extends Dialog implements ActionListener{

There's an extra space before `static` modifier which breaks the common indentation.
I'd also add a space before the opening brace, it's there in the following code of the class.

src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java line 165:

> 163:      */
> 164:     @SuppressWarnings("serial") // JDK-implementation class
> 165:      static class ScrollEvent extends PeerEvent {

There's an extra space before `static` modifier. Is it intentional?

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5943

From duke at openjdk.java.net  Wed Nov 17 19:25:15 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:25:15 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes [v2]
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  [PATCH] Change nested classes in java.desktop to static nested classes
  fix review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5943/files
  - new: https://git.openjdk.java.net/jdk/pull/5943/files/a9671a0e..1eeab86a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5943&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5943&range=00-01

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5943.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5943/head:pull/5943

PR: https://git.openjdk.java.net/jdk/pull/5943

From aivanov at openjdk.java.net  Wed Nov 17 19:25:18 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 17 Nov 2021 19:25:18 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes [v2]
In-Reply-To: <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
 <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
Message-ID: <MGWGQeVVbIK6vE-am2U5wqosMOihxBHWFnDs8Jkalg8=.fd352573-6149-43b0-843f-b586abed7ce7@github.com>

On Wed, 17 Nov 2021 19:21:49 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
>> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [PATCH] Change nested classes in java.desktop to static nested classes
>   fix review comments

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5943

From duke at openjdk.java.net  Wed Nov 17 19:25:27 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:25:27 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes [v2]
In-Reply-To: <usZ8Abd8HlU0tdT7MBFIw71TUOyvmvQ6RWlTrLumkH4=.f98b22c7-78ec-4c17-bbea-a8d9314b7b8d@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
 <usZ8Abd8HlU0tdT7MBFIw71TUOyvmvQ6RWlTrLumkH4=.f98b22c7-78ec-4c17-bbea-a8d9314b7b8d@github.com>
Message-ID: <XknssIAycNgSMx7qGOBFrm4LplD5_OjANEqaquJU0cg=.62c6c8fd-c47c-4686-b83a-38755b1b9c26@github.com>

On Wed, 17 Nov 2021 14:32:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   [PATCH] Change nested classes in java.desktop to static nested classes
>>   fix review comments
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java line 3949:
> 
>> 3947:     @SuppressWarnings("serial") // Superclass is not serializable across versions
>> 3948:     private static class ScrollableTabButton extends BasicArrowButton implements UIResource,
>> 3949:                                                                             SwingConstants {
> 
> Maybe, wrap the line before implements?

done

> src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 2300:
> 
>> 2298: 
>> 2299: @SuppressWarnings("serial") // JDK-implementation class
>> 2300:  static class PrintToFileErrorDialog extends Dialog implements ActionListener{
> 
> There's an extra space before `static` modifier which breaks the common indentation.
> I'd also add a space before the opening brace, it's there in the following code of the class.

fixed

> src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java line 165:
> 
>> 163:      */
>> 164:     @SuppressWarnings("serial") // JDK-implementation class
>> 165:      static class ScrollEvent extends PeerEvent {
> 
> There's an extra space before `static` modifier. Is it intentional?

fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/5943

From duke at openjdk.java.net  Wed Nov 17 19:35:23 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:35:23 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes [v3]
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <H-RYtqhP56gWRjhd6X78rUExRezD-J9PbEpALfrr2aQ=.39702f88-14af-43b1-a182-6029a4c53c53@github.com>

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  [PATCH] Change nested classes in java.desktop to static nested classes
  move opening brace to the same line where class is declared

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5943/files
  - new: https://git.openjdk.java.net/jdk/pull/5943/files/1eeab86a..de4deb36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5943&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5943&range=01-02

  Stats: 12 lines in 6 files changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5943.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5943/head:pull/5943

PR: https://git.openjdk.java.net/jdk/pull/5943

From duke at openjdk.java.net  Wed Nov 17 19:37:45 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 17 Nov 2021 19:37:45 GMT
Subject: <i18n dev> RFR: 8276794: Change nested classes in java.desktop
 to static nested classes [v2]
In-Reply-To: <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
 <SW4CHT966aVUkkAAoPvgKKiduDcKi9GVkBelW8YPEd0=.8d3aef66-9793-4888-9f0d-01963b8edfa3@github.com>
Message-ID: <He0pLcSO6Fh53vj5vNBopavbRCMHzr8SkMDkYAzmCog=.01b437b4-84c9-4988-a1b1-06428a48ccb2@github.com>

On Wed, 17 Nov 2021 19:25:15 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
>> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [PATCH] Change nested classes in java.desktop to static nested classes
>   fix review comments

I would prefer to postpone expanding import to another issue/PR. This one is already quite big.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5943

From serb at openjdk.java.net  Thu Nov 18 05:41:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Nov 2021 05:41:41 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
Message-ID: <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>

On Wed, 13 Oct 2021 07:35:16 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> 8274893: Update java.desktop classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8274893: Update java.desktop classes to use try-with-resources
>    close nested resources too
>  - [PATCH] Use try-with-resources to close resources in java.desktop

src/java.desktop/share/classes/com/sun/media/sound/StandardMidiFileReader.java line 150:

> 148:     public MidiFileFormat getMidiFileFormat(URL url) throws InvalidMidiDataException, IOException {
> 149:         try (InputStream urlStream = url.openStream()) { // throws IOException
> 150:             BufferedInputStream bis = new BufferedInputStream(urlStream, bisBufferSize);

Do we need to close the bis here and below as well?

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 463:

> 461:                         new InputStreamReader(is, ISO_8859_1));
> 462:                 defaultStyles.loadRules(r, null);
> 463:                 r.close();

the reader was not added to the try block, it will not be closed.

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 398:

> 396:                 Properties props = new Properties();
> 397:                 try (var is = new FileInputStream(f.getPath());
> 398:                      var bis = new BufferedInputStream(is))

It will be better to use the same pattern everywhere, since the types are used in other places it will be good to use it here as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817

From pushkar.nk at in.ibm.com  Thu Nov 18 08:11:29 2021
From: pushkar.nk at in.ibm.com (Pushkar N Kulkarni)
Date: Thu, 18 Nov 2021 08:11:29 +0000
Subject: <i18n dev> Supporting charset GB18030-2005
In-Reply-To: <8e988871-bad1-d919-7afe-a23aa3d366fe@oracle.com>
References: <8e988871-bad1-d919-7afe-a23aa3d366fe@oracle.com>,
 <6c24853a-9b3b-5030-61c4-96194c6eeccd@oracle.com>
 <OFD925145F.DBED3928-ON0025878E.006236E8-0025878E.006252FD@ibm.com>
 <OFB336D73A.F63FD7C9-ON0025878F.00689105-0025878F.00689108@ibm.com>
Message-ID: <OFBE1402FA.0BF582D2-ON00258791.002CC41E-00258791.002CFF2F@ibm.com>

Hi Alan,
 
 > We could start out by adding GB18030-2005, as you suggest.

Sure.
      
 > A potential next step would be to rename GB13080 to GB13080-2000, with "GB13080" as an alias. As it stands, the charset name is "GB13080" with "GB13080-2000" as an alias so it should be compatible with code that >   use Charset.forName.
 > It's possible this change may be noticed by code that does lookups in other ways or expects getName to be match the name specified to forName so that would be a feature release only change.

That's a good point.

 > If there is a strong need then it should be feasible to have a system property to change GB13080 but maybe it's not needed in the short/medium term when some operating systems are still using -2000.

I agree. 

Thanks for your inputs!      
      



Pushkar N Kulkarni,
Developer, IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra



-----"Alan Bateman" <Alan.Bateman at oracle.com> wrote: -----
To: "Pushkar N Kulkarni" <pushkar.nk at in.ibm.com>
From: "Alan Bateman" <Alan.Bateman at oracle.com>
Date: 11/17/2021 05:20PM
Cc: i18n-dev at openjdk.java.net, core-libs-dev at openjdk.java.net
Subject: [EXTERNAL] Re: <i18n dev> Supporting charset GB18030-2005

                                         On 16/11/2021 19:02, Pushkar N Kulkarni wrote: Hi Alan, Thanks. I appreciate your response. Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to add a new character set with the name GB13080-2005. But I guess          
                On 16/11/2021 19:02, Pushkar N Kulkarni wrote:
              
Hi Alan,



Thanks. I appreciate your response.



Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to add a new character set with the name GB13080-2005. But I guess your suggestion of internally mapping one of the two versions (2000 or 2005) to "GB13080", based on the value of a new System property,  version 2000 being the default, could be a better approach.

            We could start out by adding GB18030-2005, as you suggest.
      
      A potential next step would be to rename GB13080 to GB13080-2000,      with "GB13080" as an alias. As it stands, the charset name is      "GB13080" with "GB13080-2000" as an alias so it should be compatible      with code that use Charset.forName. It's possible this change may be      noticed by code that does lookups in other ways or expects getName      to be match the name specified to forName so that would be a feature      release only change.
      
      If there is a strong need then it should be feasible to have a      system property to change GB13080 but maybe it's not needed in the      short/medium term when some operating systems are still using -2000.
      
      -Alan
      
      

        

From duke at openjdk.java.net  Thu Nov 18 10:51:47 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 10:51:47 GMT
Subject: <i18n dev> Integrated: 8276794: Change nested classes in
 java.desktop to static nested classes
In-Reply-To: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
References: <bmr3XC0kxrzMmdWGOLnTvRKrDmzp6g5EhgIGuTwH2YQ=.aea4f720-7156-4121-8637-b950ef470922@github.com>
Message-ID: <XbsvldvEVzUPL0-DPd5Asbp0ENIaqhqdK-mtU7NWW74=.72e87359-2f6a-4b02-b2e0-5b9c33e323b3@github.com>

On Thu, 14 Oct 2021 07:47:33 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
> I updated only private and package-private classes. Didn't touch public/protected to not break external code.
> Similar cleanup in java.base - [JDK-8261880](https://bugs.openjdk.java.net/browse/JDK-8261880)

This pull request has now been integrated.

Changeset: 0a65e8b2
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a65e8b282fd41e57108422fbd140527d9697efd
Stats:     226 lines in 79 files changed: 3 ins; 53 del; 170 mod

8276794: Change nested classes in java.desktop to static nested classes

Reviewed-by: serb, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/5943

From duke at openjdk.java.net  Thu Nov 18 18:36:12 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 18:36:12 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v3]
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <S6y6z4BInR8rwrriKM_7M-yIOQqmctrhwhRbzcevlys=.d94aeba8-df69-4a9b-a32b-0ef9ef233e57@github.com>

> 8274893: Update java.desktop classes to use try-with-resources

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274893: Update java.desktop classes to use try-with-resources
  fix review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5817/files
  - new: https://git.openjdk.java.net/jdk/pull/5817/files/13bdbc0d..19ced6d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=01-02

  Stats: 17 lines in 3 files changed: 3 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5817/head:pull/5817

PR: https://git.openjdk.java.net/jdk/pull/5817

From duke at openjdk.java.net  Thu Nov 18 18:36:20 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 18:36:20 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
Message-ID: <kR7R52upKYWNj1Xy-MZ577miiV9htEq0Sj8iZCTxaOg=.a79be09c-5855-48e7-a38f-22b356861ec5@github.com>

On Thu, 18 Nov 2021 05:30:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8274893: Update java.desktop classes to use try-with-resources
>>    close nested resources too
>>  - [PATCH] Use try-with-resources to close resources in java.desktop
>
> src/java.desktop/share/classes/com/sun/media/sound/StandardMidiFileReader.java line 150:
> 
>> 148:     public MidiFileFormat getMidiFileFormat(URL url) throws InvalidMidiDataException, IOException {
>> 149:         try (InputStream urlStream = url.openStream()) { // throws IOException
>> 150:             BufferedInputStream bis = new BufferedInputStream(urlStream, bisBufferSize);
> 
> Do we need to close the bis here and below as well?

I'm not sure it's 100% needed to close BufferedInputStream/BufferedReader wrappers. It's more code style question. Updated.

> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 398:
> 
>> 396:                 Properties props = new Properties();
>> 397:                 try (var is = new FileInputStream(f.getPath());
>> 398:                      var bis = new BufferedInputStream(is))
> 
> It will be better to use the same pattern everywhere, since the types are used in other places it will be good to use it here as well.

as you wish

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817

From duke at openjdk.java.net  Thu Nov 18 18:36:22 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 18:36:22 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v3]
In-Reply-To: <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
Message-ID: <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>

On Thu, 18 Nov 2021 05:36:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274893: Update java.desktop classes to use try-with-resources
>>   fix review comments
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 463:
> 
>> 461:                         new InputStreamReader(is, ISO_8859_1));
>> 462:                 defaultStyles.loadRules(r, null);
>> 463:                 r.close();
> 
> the reader was not added to the try block, it will not be closed.

updated

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817

From bchristi at openjdk.java.net  Thu Nov 18 22:55:02 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 18 Nov 2021 22:55:02 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related methods
 for removal
Message-ID: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>

Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.

This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.

The CSR has been approved.
An automated test build+test run passes cleanly (FWIW :D ).

-------------

Commit messages:
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - Fix @since on @Deprecated for java.lang.Enum
 - Clarify conditions for removal of Object.finalize method
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276447
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

PR: https://git.openjdk.java.net/jdk/pull/6465

From itakiguchi at openjdk.java.net  Fri Nov 19 07:09:15 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 19 Nov 2021 07:09:15 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name COMPAT
Message-ID: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>

ncoding name COMPAT was defined for operating system encoding by JEP-400.
https://openjdk.java.net/jeps/400
But java does not accept "-encoding COMPAT".

-------------

Commit messages:
 - 8277398: javac does not accept encoding name COMPAT

Changes: https://git.openjdk.java.net/jdk/pull/6475/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6475&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277398
  Stats: 109 lines in 3 files changed: 106 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6475.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6475/head:pull/6475

PR: https://git.openjdk.java.net/jdk/pull/6475

From alanb at openjdk.java.net  Fri Nov 19 12:14:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Nov 2021 12:14:39 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <cfFe-LZYHTiECi-93Oy7XoVZmLtcla-yODnK4sMFRq8=.6cba0240-0687-484d-a60a-4e0864d9dcc9@github.com>

On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java line 283:

> 281:                     if (enc != null) {
> 282:                         encodingName = enc;
> 283:                     }

If we updating javac and javadoc --encoding to support "COMPAT" then we should list this in JEP 400.

Does javadoc use doPriv already, I don't know how common it would be to run javadoc with a SM set. If the doPriv stays then you can avoid the cast by changing it to:
PrivilegedAction<String> pa = () -> System.getProperty("native.encoding");
return AccessController.doPrivileged(pa);

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From alanb at openjdk.java.net  Fri Nov 19 17:31:53 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Nov 2021 17:31:53 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <s5uZ42EuMGyW0S1nktOZSh1I5BUeC-lGUK4-VLTAZbw=.151b63d2-7598-47a7-a3e1-a0d9d0617aa9@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6465

From rriggs at openjdk.java.net  Fri Nov 19 17:31:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 19 Nov 2021 17:31:47 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <g-OOLS12CnVzpJmzzDjU72acZU5_sb508fBLcLxhzoA=.4d7503a8-c2d2-4dd1-b92e-2c0b1a5a10a2@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6465

From naoto at openjdk.java.net  Fri Nov 19 17:35:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Nov 2021 17:35:09 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
 <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>
Message-ID: <7JYAnqIv4UFGDCnbFtovQrkFC-jUUmRPLrUfQsJn1po=.66ad8156-f70f-4ebe-8bc0-2a1ee8a6b1af@github.com>

On Sun, 14 Nov 2021 16:45:07 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970
>
> Hello @naotoj .
> For PrintStream.getCharset(), following changes may be required.
> 
> +++ src/java.base/share/classes/java/io/OutputStreamWriter.java
> +    Charset getCharset() {
> +        return se.getCharset();
> +    }
> 
> +++ src/java.base/share/classes/java/io/PrintStream.java
> +    public Charset getCharset() {
> +        return charOut.getCharset();
> +    }
> 
> +++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java
> +    public Charset getCharset() {
> +        return cs;
> +    }
> 
> For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler.
> We need to use reflection, like:
> 
> +++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
> +    private static Charset getCharset(PrintStream ps) {
> +        try {
> +            Method getCharset = PrintStream.class.getDeclaredMethod("getCharset");
> +            return (Charset)getCharset.invoke(ps);
> +        } catch (Exception e) {
> +            return Charset.defaultCharset();
> +        }
> +    }
> 
> If we add following constructors against PrintWriter, we just change javap and jshell code.
> But I cannot evaluate this code changes.
> 
> +++ src/java.base/share/classes/java/io/PrintWriter.java
> +    public PrintWriter(PrintStream ps) {
> +       this((OutputStream)ps, false, ps.getCharset());
> +    }
> +    public PrintWriter(PrintStream ps, boolean autoFlush) {
> +       this((OutputStream)ps, autoFlush, ps.getCharset());
> +    }
> 
> I really appreciate if you handle this kind of code change via JEP-400.

I think this PR can now safely be withdrawn, as https://github.com/openjdk/jdk/pull/6401 is now integrated. @takiguc, if you do not mind, I will create a PR for the remaining jshell issue. Please let me know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From lancea at openjdk.java.net  Fri Nov 19 17:47:57 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 17:47:57 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <rk3xCjJlKgbIZt3rUi_crNZx2qjbpzB_ylVbpFjrR58=.71b45eb7-a79f-48d7-bd1b-cf541ba99268@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From mchung at openjdk.java.net  Fri Nov 19 18:10:09 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 18:10:09 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

src/java.base/share/classes/java/lang/Object.java line 481:

> 479:      * system resources or to perform other cleanup.
> 480:      * <p>
> 481:      * <b>When running in a Java virtual machine in which finalization has been

Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From darcy at openjdk.java.net  Fri Nov 19 18:10:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 19 Nov 2021 18:10:08 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <H67a1T-dtaGUqeKSvlrfRWlTL64nxFUSN6jKOg0gmC4=.15c0752b-dae1-4e6a-8109-1f8478628d8f@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From bchristi at openjdk.java.net  Fri Nov 19 18:19:10 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 19 Nov 2021 18:19:10 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
Message-ID: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>

On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> src/java.base/share/classes/java/lang/Object.java line 481:
> 
>> 479:      * system resources or to perform other cleanup.
>> 480:      * <p>
>> 481:      * <b>When running in a Java virtual machine in which finalization has been
> 
> Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.

The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal.  That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From naoto at openjdk.java.net  Fri Nov 19 17:35:11 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Nov 2021 17:35:11 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <jTjoFY4oCoNDOgNM0rt_fpkqQY85C5b_0ICh2TgmE7Q=.b0a394df-7441-46bc-9580-2aeeb1cbdd98@github.com>

On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

Do we want this option in `javac`/`javadoc`? Should `-J-Dfile.encoding=COMPAT` suffice the need?
I don't think `COMPAT` is an encoding name, but a valid value to the system property `file.encoding`. If we wanted to regard `COMPAT` as an encoding alias to the native encoding, I would expect `Charset.forName("COMPAT")` would have to be modified, but I don't think we would do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From duke at openjdk.java.net  Fri Nov 19 18:51:17 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 19 Nov 2021 18:51:17 GMT
Subject: <i18n dev> Integrated: 8274949: Use String.contains() instead of
 String.indexOf() in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <_JpRagrNxERC0uIpZ8Vj3F9xZ1StAeNX4oYWmWHI080=.931977e5-28f3-4466-b59c-076af0db650d@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

This pull request has now been integrated.

Changeset: 66775543
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6677554374ade32c9f2ddaaa093064de8aebd831
Stats:     38 lines in 17 files changed: 0 ins; 3 del; 35 mod

8274949: Use String.contains() instead of String.indexOf() in java.base

Reviewed-by: weijun, dfuchs, vtewari, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/5559

From mchung at openjdk.java.net  Fri Nov 19 19:10:11 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 19:10:11 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <XQEqvCRazxICMGG28AwzLqjpFVc_le_-jemEcxzWWAA=.db4ee046-4961-4c30-8f23-f2ee57cd2ecc@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From mchung at openjdk.java.net  Fri Nov 19 19:10:12 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 19:10:12 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <kC6p_fpghxElTgc-b79F7h7YoihJGsBp2lgKMW5HQBY=.c2cad07b-7aca-4ff8-9a85-4c2bdad1cfe4@github.com>
 <4SEx_A8tpoVVTla7pEc_K935DJ4RlZhabwof3s3FKvY=.1a52f99d-3b32-462e-83dd-339c1223892d@github.com>
Message-ID: <YfMEhBgRnkNrn9LpnheH8NJNWnS5A7HEnbt_n0046jc=.9c0ccb5a-57a4-4e0e-a237-aac01051d0b3@github.com>

On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Object.java line 481:
>> 
>>> 479:      * system resources or to perform other cleanup.
>>> 480:      * <p>
>>> 481:      * <b>When running in a Java virtual machine in which finalization has been
>> 
>> Disabling finalization is not part of the Java SE spec.   This paragraph describes the implementation of HotSpot VM and I think it does not belong to this javadoc.
>
> The coupling between this change and [8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line option to disable finalization") is probably tighter than would be ideal.  That [CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization to be disabled in the SE Platform Spec and the JLS.

Thanks for pointing out that the CSR for JDK-8276422 ("Add command-line option to disable finalization") includes the change of the SE Platform Spec and JLS to allow an implementation for finalization to be disabled.   This makes senses now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From serb at openjdk.java.net  Fri Nov 19 19:29:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 19:29:10 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v3]
In-Reply-To: <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
 <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>
Message-ID: <HKGTf-VvaJjNCZVqnE6tXcKquDPkSOSbBeraanlBSP8=.ba21f4cb-82cf-4152-8db4-32674f0fcda6@github.com>

On Thu, 18 Nov 2021 18:32:30 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 463:
>> 
>>> 461:                         new InputStreamReader(is, ISO_8859_1));
>>> 462:                 defaultStyles.loadRules(r, null);
>>> 463:                 r.close();
>> 
>> the reader was not added to the try block, it will not be closed.
>
> updated

What about "new InputStreamReader()" here and below?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817

From serb at openjdk.java.net  Fri Nov 19 20:16:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Nov 2021 20:16:12 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <ukGuoG0O2Jh8RpaJ-WYcNiWFpAqRXZdiuwKR6w9v9VQ=.07b447cd-6c91-4b5f-86d9-c0be213bb0b7@github.com>

On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6465

From pushkar.nk at in.ibm.com  Mon Nov 22 06:14:39 2021
From: pushkar.nk at in.ibm.com (Pushkar N Kulkarni)
Date: Mon, 22 Nov 2021 06:14:39 +0000
Subject: <i18n dev> Supporting charset GB18030-2005
In-Reply-To: <OFBE1402FA.0BF582D2-ON00258791.002CC41E-00258791.002CFF2F@LocalDomain>
References: <OFBE1402FA.0BF582D2-ON00258791.002CC41E-00258791.002CFF2F@LocalDomain>,
 <8e988871-bad1-d919-7afe-a23aa3d366fe@oracle.com>,
 <6c24853a-9b3b-5030-61c4-96194c6eeccd@oracle.com>
 <OFD925145F.DBED3928-ON0025878E.006236E8-0025878E.006252FD@ibm.com>
 <OFB336D73A.F63FD7C9-ON0025878F.00689105-0025878F.00689108@ibm.com>
Message-ID: <OFE051F42E.A5BA1DB2-ON00258795.00224CFF-00258795.00224D01@ibm.com>

Ramanand kindly agreed to file the enhancement request for this: https://bugs.openjdk.java.net/browse/JDK-8277442


Pushkar N Kulkarni,
Developer, IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra



-----Pushkar N Kulkarni/India/IBM wrote: -----
To: "Alan Bateman" <Alan.Bateman at oracle.com>
From: Pushkar N Kulkarni/India/IBM
Date: 11/18/2021 01:41PM
Cc: i18n-dev at openjdk.java.net, core-libs-dev at openjdk.java.net
Subject: Re: [EXTERNAL] Re: <i18n dev> Supporting charset GB18030-2005

Hi Alan,
 
 > We could start out by adding GB18030-2005, as you suggest.

Sure.
      
 > A potential next step would be to rename GB13080 to GB13080-2000, with "GB13080" as an alias. As it stands, the charset name is "GB13080" with "GB13080-2000" as an alias so it should be compatible with code that >   use Charset.forName.
 > It's possible this change may be noticed by code that does lookups in other ways or expects getName to be match the name specified to forName so that would be a feature release only change.

That's a good point.

 > If there is a strong need then it should be feasible to have a system property to change GB13080 but maybe it's not needed in the short/medium term when some operating systems are still using -2000.

I agree. 

Thanks for your inputs!      
      



Pushkar N Kulkarni,
Developer, IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra



-----"Alan Bateman" <Alan.Bateman at oracle.com> wrote: -----
To: "Pushkar N Kulkarni" <pushkar.nk at in.ibm.com>
From: "Alan Bateman" <Alan.Bateman at oracle.com>
Date: 11/17/2021 05:20PM
Cc: i18n-dev at openjdk.java.net, core-libs-dev at openjdk.java.net
Subject: [EXTERNAL] Re: <i18n dev> Supporting charset GB18030-2005

                                         On 16/11/2021 19:02, Pushkar N Kulkarni wrote: Hi Alan, Thanks. I appreciate your response. Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to add a new character set with the name GB13080-2005. But I guess          ZjQcmQRYFpfptBannerStart            
      
        
  	This Message Is From an External Sender                
  This message came from outside your organization.                            ZjQcmQRYFpfptBannerEnd
                On 16/11/2021 19:02, Pushkar N Kulkarni wrote:
              
Hi Alan,



Thanks. I appreciate your response.



Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially hoping to add a new character set with the name GB13080-2005. But I guess your suggestion of internally mapping one of the two versions (2000 or 2005) to "GB13080", based on the value of a new System property,  version 2000 being the default, could be a better approach.

            We could start out by adding GB18030-2005, as you suggest.
      
      A potential next step would be to rename GB13080 to GB13080-2000,      with "GB13080" as an alias. As it stands, the charset name is      "GB13080" with "GB13080-2000" as an alias so it should be compatible      with code that use Charset.forName. It's possible this change may be      noticed by code that does lookups in other ways or expects getName      to be match the name specified to forName so that would be a feature      release only change.
      
      If there is a strong need then it should be feasible to have a      system property to change GB13080 but maybe it's not needed in the      short/medium term when some operating systems are still using -2000.
      
      -Alan
      
      

        

From itakiguchi at openjdk.java.net  Mon Nov 22 16:16:26 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 22 Nov 2021 16:16:26 GMT
Subject: <i18n dev> Withdrawn: 8274544: Langtools command's usage were
 garbled on Japanese Windows
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <kdA1hd2YKY1fqDH7n4kConX9tEu5do7J326l8JGIikk=.a4cfb71c-bf68-469b-9209-ebcfd6252777@github.com>

On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From itakiguchi at openjdk.java.net  Mon Nov 22 16:16:26 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 22 Nov 2021 16:16:26 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v5]
In-Reply-To: <7JYAnqIv4UFGDCnbFtovQrkFC-jUUmRPLrUfQsJn1po=.66ad8156-f70f-4ebe-8bc0-2a1ee8a6b1af@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
 <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>
 <7JYAnqIv4UFGDCnbFtovQrkFC-jUUmRPLrUfQsJn1po=.66ad8156-f70f-4ebe-8bc0-2a1ee8a6b1af@github.com>
Message-ID: <qtzbWJL3pfQnTa8FlearwmbutzMqsxIvTgpI4OnTyIw=.4bbca3e1-75f4-444e-b8a8-5475a57ba4a7@github.com>

On Fri, 19 Nov 2021 16:48:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> For PrintStream.getCharset(), following changes may be required.
>> 
>> +++ src/java.base/share/classes/java/io/OutputStreamWriter.java
>> +    Charset getCharset() {
>> +        return se.getCharset();
>> +    }
>> 
>> +++ src/java.base/share/classes/java/io/PrintStream.java
>> +    public Charset getCharset() {
>> +        return charOut.getCharset();
>> +    }
>> 
>> +++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java
>> +    public Charset getCharset() {
>> +        return cs;
>> +    }
>> 
>> For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler.
>> We need to use reflection, like:
>> 
>> +++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
>> +    private static Charset getCharset(PrintStream ps) {
>> +        try {
>> +            Method getCharset = PrintStream.class.getDeclaredMethod("getCharset");
>> +            return (Charset)getCharset.invoke(ps);
>> +        } catch (Exception e) {
>> +            return Charset.defaultCharset();
>> +        }
>> +    }
>> 
>> If we add following constructors against PrintWriter, we just change javap and jshell code.
>> But I cannot evaluate this code changes.
>> 
>> +++ src/java.base/share/classes/java/io/PrintWriter.java
>> +    public PrintWriter(PrintStream ps) {
>> +       this((OutputStream)ps, false, ps.getCharset());
>> +    }
>> +    public PrintWriter(PrintStream ps, boolean autoFlush) {
>> +       this((OutputStream)ps, autoFlush, ps.getCharset());
>> +    }
>> 
>> I really appreciate if you handle this kind of code change via JEP-400.
>
> I think this PR can now safely be withdrawn, as https://github.com/openjdk/jdk/pull/6401 is now integrated. @takiguc, if you do not mind, I will create a PR for the remaining jshell issue. Please let me know.

Thanks @naotoj .
I opened new pr via 8274784.
I'd like to close this pr since main issue was fixed by #6401.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From itakiguchi at openjdk.java.net  Mon Nov 22 16:18:47 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 22 Nov 2021 16:18:47 GMT
Subject: <i18n dev> RFR: 8274784: jshell: Garbled character was displayed by
 System.out.println(...) on Japanese Windows
Message-ID: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>

JEP-400 was implemented by JDK18-b13.
After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt.

System.out.println("\u3042")

Japanese "A" should be display ed, but garbled character was displayed.
Also saved jshell command list did not work as expected if Japanese character was there.

Following issue has some information
8274544: Langtools command's usage were garbled on Japanese Windows #5771
https://github.com/openjdk/jdk/pull/5771
This issue also happens on Linux ja_JP.eucjp locale.
RemoteExecutionControl.java change is required for this issue.

Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal.
AbstractTerminal.java change is required for this issue.

-------------

Commit messages:
 - 8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows

Changes: https://git.openjdk.java.net/jdk/pull/6505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6505&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274784
  Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6505/head:pull/6505

PR: https://git.openjdk.java.net/jdk/pull/6505

From itakiguchi at openjdk.java.net  Mon Nov 22 16:23:19 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 22 Nov 2021 16:23:19 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <IffFJlk85Md1HYFLR2PVepQZw9_Br4zKwMbKvBQzaIQ=.60fd962a-cc2a-43f0-943f-cf245f8a41b6@github.com>

On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

Thanks @AlanBateman and @naotoj .
I appreciate your good suggestions.
My consideration was not enough.
I think this issue should be handle via Charset alias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From naoto at openjdk.java.net  Mon Nov 22 19:51:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 22 Nov 2021 19:51:09 GMT
Subject: <i18n dev> RFR: 8274784: jshell: Garbled character was
 displayed by System.out.println(...) on Japanese Windows
In-Reply-To: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
References: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
Message-ID: <2clDVhebPGtoMvQ2ARFZvyyVfKrDjwoXCYFLaHkhDa8=.73603161-69de-483f-bfe8-b752a0369624@github.com>

On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 was implemented by JDK18-b13.
> After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt.
> 
> System.out.println("\u3042")
> 
> Japanese "A" should be display ed, but garbled character was displayed.
> Also saved jshell command list did not work as expected if Japanese character was there.
> 
> Following issue has some information
> 8274544: Langtools command's usage were garbled on Japanese Windows #5771
> https://github.com/openjdk/jdk/pull/5771
> This issue also happens on Linux ja_JP.eucjp locale.
> RemoteExecutionControl.java change is required for this issue.
> 
> Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal.
> AbstractTerminal.java change is required for this issue.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java line 60:

> 58:         this.type = type != null ? type : "ansi";
> 59:         this.encoding = encoding != null ? encoding :
> 60:             Charset.forName(new OutputStreamWriter(System.out).getEncoding(), Charset.defaultCharset());

I don't think `OutputStreamWriter` instance is needed here. 

System.out instanceof PrintStream ps ? ps.charset() : Charset.defaultEncoding();

would suffice.

src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java line 80:

> 78:             Charset.defaultCharset());
> 79:     }
> 80: 

I'd prefer not to introduce this static method, but just embed it into each location. The other comment in `AbstractTerminal.java` applies here too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6505

From itakiguchi at openjdk.java.net  Tue Nov 23 16:36:07 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 23 Nov 2021 16:36:07 GMT
Subject: <i18n dev> RFR: 8274784: jshell: Garbled character was
 displayed by System.out.println(...) on Japanese Windows
In-Reply-To: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
References: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
Message-ID: <apb-4sjJmO1QCAWNU-wg0bn4XtMfhGkOfpUJ5lIoIxE=.ebeb5b1e-b22a-45c1-8ad0-81632936baa1@github.com>

On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 was implemented by JDK18-b13.
> After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt.
> 
> System.out.println("\u3042")
> 
> Japanese "A" should be display ed, but garbled character was displayed.
> Also saved jshell command list did not work as expected if Japanese character was there.
> 
> Following issue has some information
> 8274544: Langtools command's usage were garbled on Japanese Windows #5771
> https://github.com/openjdk/jdk/pull/5771
> This issue also happens on Linux ja_JP.eucjp locale.
> RemoteExecutionControl.java change is required for this issue.
> 
> Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal.
> AbstractTerminal.java change is required for this issue.

Thanks @naotoj .
I appreciate your suggestion.
I misread PrintStream.charset() spec.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6505

From naoto at openjdk.java.net  Tue Nov 23 17:13:26 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 23 Nov 2021 17:13:26 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST
Message-ID: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>

This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.

-------------

Commit messages:
 - 8177819: DateTimeFormatterBuilder zone parsing should recognise DST

Changes: https://git.openjdk.java.net/jdk/pull/6527/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6527&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8177819
  Stats: 112 lines in 5 files changed: 61 ins; 0 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6527.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6527/head:pull/6527

PR: https://git.openjdk.java.net/jdk/pull/6527

From jjg at openjdk.java.net  Tue Nov 23 20:10:10 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 23 Nov 2021 20:10:10 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT
In-Reply-To: <cfFe-LZYHTiECi-93Oy7XoVZmLtcla-yODnK4sMFRq8=.6cba0240-0687-484d-a60a-4e0864d9dcc9@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <cfFe-LZYHTiECi-93Oy7XoVZmLtcla-yODnK4sMFRq8=.6cba0240-0687-484d-a60a-4e0864d9dcc9@github.com>
Message-ID: <x8S-Zg7EyWFyevwBsmF-U6tULcAey4teYgZdrHgyV9A=.f4fac962-692e-4429-b399-3cbc99ed85e2@github.com>

On Fri, 19 Nov 2021 12:11:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java line 283:
> 
>> 281:                     if (enc != null) {
>> 282:                         encodingName = enc;
>> 283:                     }
> 
> If we updating javac and javadoc --encoding to support "COMPAT" then we should list this in JEP 400.
> 
> Does javadoc use doPriv already, I don't know how common it would be to run javadoc with a SM set. If the doPriv stays then you can avoid the cast by changing it to:
> PrivilegedAction<String> pa = () -> System.getProperty("native.encoding");
> return AccessController.doPrivileged(pa);

javac and javadoc do not have privileged code. I am loathe to change that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From duke at openjdk.java.net  Tue Nov 23 20:52:40 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Nov 2021 20:52:40 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v4]
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <4-SKWxMIwTELnjjaNtCMiLopBp2n1-vpCPnEl4Gst6s=.e04c81b2-d0ed-4366-9b5b-f3eac4a660a5@github.com>

> 8274893: Update java.desktop classes to use try-with-resources

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274893: Update java.desktop classes to use try-with-resources
  close nested streams too to unify code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5817/files
  - new: https://git.openjdk.java.net/jdk/pull/5817/files/19ced6d9..483b0cfd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=02-03

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5817/head:pull/5817

PR: https://git.openjdk.java.net/jdk/pull/5817

From duke at openjdk.java.net  Tue Nov 23 20:52:41 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Nov 2021 20:52:41 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v4]
In-Reply-To: <HKGTf-VvaJjNCZVqnE6tXcKquDPkSOSbBeraanlBSP8=.ba21f4cb-82cf-4152-8db4-32674f0fcda6@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>
 <0TqXqT-I0fAChKQOB5lDYeIIxG-wqzDjF22lFYWyHC0=.984aefe4-21e4-4fbe-81bf-15a3547d88bf@github.com>
 <evHZiymXk5g7z5wYB2EzoHBx9HTs8xpNHAd3prGDvDc=.3e020003-99ef-4394-96d2-1ab2c7c14dd3@github.com>
 <HKGTf-VvaJjNCZVqnE6tXcKquDPkSOSbBeraanlBSP8=.ba21f4cb-82cf-4152-8db4-32674f0fcda6@github.com>
Message-ID: <6ViRv9hu4_EDbUi5PqA54VwCOnkyluV9mK3E8EDwOco=.5c01f75d-4533-445f-8a30-4f140ee31039@github.com>

On Fri, 19 Nov 2021 19:24:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> updated
>
> What about "new InputStreamReader()" here and below?

added it to `try` too

-------------

PR: https://git.openjdk.java.net/jdk/pull/5817

From naoto at openjdk.java.net  Tue Nov 23 23:50:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 23 Nov 2021 23:50:36 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v2]
In-Reply-To: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
Message-ID: <D-4oGRVSw3zhNT-z4NvwjdFrH2_ea1qGL3a_klTUn6E=.b3fca3c9-fc84-4073-b063-08c9dc58d691@github.com>

> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refined wording

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6527/files
  - new: https://git.openjdk.java.net/jdk/pull/6527/files/40daaa29..99ad3cad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6527&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6527&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6527.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6527/head:pull/6527

PR: https://git.openjdk.java.net/jdk/pull/6527

From itakiguchi at openjdk.java.net  Wed Nov 24 03:05:32 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 24 Nov 2021 03:05:32 GMT
Subject: <i18n dev> RFR: 8274784: jshell: Garbled character was
 displayed by System.out.println(...) on Japanese Windows [v2]
In-Reply-To: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
References: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
Message-ID: <k1rJwVBKL9xlwgbfTNRHV31yFgBT0npcQ1JxuNNVNgw=.928cfdfe-581a-46c9-952f-e468af16b7c3@github.com>

> JEP-400 was implemented by JDK18-b13.
> After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt.
> 
> System.out.println("\u3042")
> 
> Japanese "A" should be display ed, but garbled character was displayed.
> Also saved jshell command list did not work as expected if Japanese character was there.
> 
> Following issue has some information
> 8274544: Langtools command's usage were garbled on Japanese Windows #5771
> https://github.com/openjdk/jdk/pull/5771
> This issue also happens on Linux ja_JP.eucjp locale.
> RemoteExecutionControl.java change is required for this issue.
> 
> Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal.
> AbstractTerminal.java change is required for this issue.

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6505/files
  - new: https://git.openjdk.java.net/jdk/pull/6505/files/63e6e7bd..8ca6252e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6505&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6505&range=00-01

  Stats: 13 lines in 2 files changed: 0 ins; 10 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6505/head:pull/6505

PR: https://git.openjdk.java.net/jdk/pull/6505

From itakiguchi at openjdk.java.net  Wed Nov 24 04:08:43 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 24 Nov 2021 04:08:43 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8277398: javac does not accept encoding name COMPAT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6475/files
  - new: https://git.openjdk.java.net/jdk/pull/6475/files/a1b329e2..94d0c2c7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6475&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6475&range=00-01

  Stats: 192 lines in 6 files changed: 83 ins; 106 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6475.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6475/head:pull/6475

PR: https://git.openjdk.java.net/jdk/pull/6475

From alanb at openjdk.java.net  Wed Nov 24 08:51:10 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Nov 2021 08:51:10 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <6gCZ5DkejqB-BWoOfwm11qzMtxNxuETGBdVQZP3b50Q=.51c7b8ff-e1bd-49dd-8b8d-00159ffa9eee@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

I see this PR has been re-purposed to add "COMPAT" as a charset that can be specified to Charset.forName. I don't think we should do that.  "COMPAT" is a special value for the file.encoding property, it's not meant to be in the charset tables as proposed here. The system property "native.encoding" was added in Java 17 as a standard way to obtain the encoding, you can pass its value to Charset.forName. I think we need a clear summary as to what the issue is, is -J-Dfile.encoding=COMPAT working or not?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From naoto at openjdk.java.net  Wed Nov 24 13:58:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 13:58:05 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <ZVFU4z2WX4tHRZx47ROiBc3b1iIlSd6e47VYT0eyXt0=.d6406a1c-4f2e-42f6-beee-44538d7f8640@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

Sorry if I didn't make myself clear, but I totally agree with Alan. `COMPAT` is meant for apps for their migration to JDK18, not something we would want to promote as a feature. `Charset.forName("COMPAT")` was an example we would not do, leading to my point that we should not add the proposed javac/javadoc compiler flag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From itakiguchi at openjdk.java.net  Wed Nov 24 14:39:07 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 24 Nov 2021 14:39:07 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <6gCZ5DkejqB-BWoOfwm11qzMtxNxuETGBdVQZP3b50Q=.51c7b8ff-e1bd-49dd-8b8d-00159ffa9eee@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <6gCZ5DkejqB-BWoOfwm11qzMtxNxuETGBdVQZP3b50Q=.51c7b8ff-e1bd-49dd-8b8d-00159ffa9eee@github.com>
Message-ID: <ITcPgw0Bop1aUELJSN_-TZSNw30YyOJ15lO1QI1heiU=.9b6ec3f1-bdd8-4548-9b0f-bb63c64ee46b@github.com>

On Wed, 24 Nov 2021 08:47:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277398: javac does not accept encoding name COMPAT
>
> I see this PR has been re-purposed to add "COMPAT" as a charset that can be specified to Charset.forName. I don't think we should do that.  "COMPAT" is a special value for the file.encoding property, it's not meant to be in the charset tables as proposed here. The system property "native.encoding" was added in Java 17 as a standard way to obtain the encoding, you can pass its value to Charset.forName. I think we need a clear summary as to what the issue is, is -J-Dfile.encoding=COMPAT working or not?

Hello @AlanBateman and @naotoj .
I'd like to show some commands output.
As you told me, -J-Dfile.encoding=COMPAT works for compilation.
Hello.java is encoded by EUC-JP.

$ export LANG=ja_JP.eucjp
$ cat Hello.java
public class Hello {
  public static void main(String[] args) throws Exception {
    System.out.println("?????");
  }
}
$ xxd Hello.java
0000000: 7075 626c 6963 2063 6c61 7373 2048 656c  public class Hel
0000010: 6c6f 207b 0a20 2070 7562 6c69 6320 7374  lo {.  public st
0000020: 6174 6963 2076 6f69 6420 6d61 696e 2853  atic void main(S
0000030: 7472 696e 675b 5d20 6172 6773 2920 7468  tring[] args) th
0000040: 726f 7773 2045 7863 6570 7469 6f6e 207b  rows Exception {
0000050: 0a20 2020 2053 7973 7465 6d2e 6f75 742e  .    System.out.
0000060: 7072 696e 746c 6e28 22a4 b3a4 f3a4 cba4  println(".......
0000070: c1a4 cf22 293b 0a20 207d 0a7d 0a         ...");.  }.}.
$ build/linux-x86_64-server-release/images/jdk/bin/javac -J-Dfile.encoding=COMPAT Hello.java
$ build/linux-x86_64-server-release/images/jdk/bin/java Hello
?????
$ build/linux-x86_64-server-release/images/jdk/bin/javac -J-Dfile.encoding=COMPAT -verbose Hello.java 2>&1 | head
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???????]
[13??????????]
[/modules/jdk.internal.vm.compiler/module-info.class?????]
[/modules/jdk.incubator.foreign/module-info.class?????]
[/modules/jdk.xml.dom/module-info.class?????]
[/modules/jdk.jdwp.agent/module-info.class?????]
[/modules/jdk.editpad/module-info.class?????]
[/modules/jdk.crypto.ec/module-info.class?????]
[/modules/java.management.rmi/module-info.class?????]
[/modules/java.management/module-info.class?????]

When I use -Xstdout option for javac, javac's output is redirect to file.


$ build/linux-x86_64-server-release/images/jdk/bin/javac -Xstdout out.log -J-Dfile.encoding=COMPAT -verbose Hello.java

According to head command, out.log was encoded by EUC-JP.
But I'd like to get UTF-8 encoded out.log. 

$ head out.log
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???????]
[13??????????]
[/modules/jdk.nio.mapmode/module-info.class?????]
[/modules/jdk.security.auth/module-info.class?????]
[/modules/jdk.internal.vm.compiler.management/module-info.class?????]
[/modules/java.scripting/module-info.class?????]
[/modules/java.datatransfer/module-info.class?????]
[/modules/jdk.attach/module-info.class?????]
[/modules/jdk.management.agent/module-info.class?????]
[/modules/jdk.jdi/module-info.class?????]

If I use -encoding option against javac command, out.log was encoded by UTF-8.

$ build/linux-x86_64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep encoding
    file.encoding = UTF-8
    native.encoding = EUC-JP-LINUX
    sun.io.unicode.encoding = UnicodeLittle
    sun.jnu.encoding = EUC-JP-LINUX
$ build/linux-x86_64-server-release/images/jdk/bin/javac -Xstdout out.log -encoding EUC-JP-LINUX -verbose Hello.java
$ head out.log
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???
$ head out.log | iconv -f UTF-8 -t EUC-JP
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???????]
[12??????????]
[/modules/jdk.jdi/module-info.class?????]
[/modules/jdk.internal.jvmstat/module-info.class?????]
[/modules/jdk.jartool/module-info.class?????]
[/modules/jdk.compiler/module-info.class?????]
[/modules/jdk.unsupported.desktop/module-info.class?????]
[/modules/java.desktop/module-info.class?????]
[/modules/java.xml/module-info.class?????]
[/modules/jdk.jcmd/module-info.class?????]

I don't want to find out encoding name each locale or platform.
javac and javadoc should be support COMPAT encoding name or COMPAT charset should be supported.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From naoto at openjdk.java.net  Wed Nov 24 18:39:16 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 18:39:16 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <_QbaoDO0VE5FNiLn4P7MzcNmgmuQbEz91_4giSGKFkA=.0310a8b1-a171-4de5-a0a3-7ea8d3564188@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

Sorry, but I am kind of lost what you are expecting here. All the logs that you provided seem to be working exactly what is expected. Are you expecting `COMPAT` to auto-detect the source file (Hello.java) encoding?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From naoto at openjdk.java.net  Wed Nov 24 18:46:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 18:46:15 GMT
Subject: <i18n dev> RFR: 8274784: jshell: Garbled character was
 displayed by System.out.println(...) on Japanese Windows [v2]
In-Reply-To: <k1rJwVBKL9xlwgbfTNRHV31yFgBT0npcQ1JxuNNVNgw=.928cfdfe-581a-46c9-952f-e468af16b7c3@github.com>
References: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
 <k1rJwVBKL9xlwgbfTNRHV31yFgBT0npcQ1JxuNNVNgw=.928cfdfe-581a-46c9-952f-e468af16b7c3@github.com>
Message-ID: <cOQRS6kpG-e19Gy6KEIodQygwNUc_faLUWy4aHZ845s=.f4a7e39a-4489-45c5-b466-7ac612a6c3c2@github.com>

On Wed, 24 Nov 2021 03:05:32 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 was implemented by JDK18-b13.
>> After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt.
>> 
>> System.out.println("\u3042")
>> 
>> Japanese "A" should be display ed, but garbled character was displayed.
>> Also saved jshell command list did not work as expected if Japanese character was there.
>> 
>> Following issue has some information
>> 8274544: Langtools command's usage were garbled on Japanese Windows #5771
>> https://github.com/openjdk/jdk/pull/5771
>> This issue also happens on Linux ja_JP.eucjp locale.
>> RemoteExecutionControl.java change is required for this issue.
>> 
>> Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal.
>> AbstractTerminal.java change is required for this issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows

Looks good to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6505

From duke at openjdk.java.net  Wed Nov 24 20:59:09 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 24 Nov 2021 20:59:09 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <CYMTaWsxy2D8Z0X3M0nuL_7eCFqSAjnpJGRUiw2Jo1w=.e1c97b62-cb29-4597-b91d-e2f0edb3bb9c@github.com>

On Sat, 11 Sep 2021 14:59:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

not yet, bot

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482

From joehw at openjdk.java.net  Wed Nov 24 21:38:05 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 24 Nov 2021 21:38:05 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v2]
In-Reply-To: <D-4oGRVSw3zhNT-z4NvwjdFrH2_ea1qGL3a_klTUn6E=.b3fca3c9-fc84-4073-b063-08c9dc58d691@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <D-4oGRVSw3zhNT-z4NvwjdFrH2_ea1qGL3a_klTUn6E=.b3fca3c9-fc84-4073-b063-08c9dc58d691@github.com>
Message-ID: <20wq89Ukhi0d8oNpoVEwbHEyYMHw69lPJVq8ov_pC_0=.c90b6c60-f08b-4833-b23a-3b0faf6170ae@github.com>

On Tue, 23 Nov 2021 23:50:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording

For the compatibility assessment, it looks like an incompatible change since apps that expect DST will get a different offset at the overlap. The risk is low, perhaps because of the rare use case? That additional explanation might be helpful.

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 509:

> 507:  * parsed from the zone name that does not imply daylight saving time, then
> 508:  * {@link ChronoZonedDateTime#withLaterOffsetAtOverlap()} is issued
> 509:  * to use the standard offset at the overlap, before forming the instant.

Is the standard offset the subject instead of the withLaterOffsetAtOverlap method? Calling the method seems to be an impl detail to me. We might rephrase the sentence to sth. like:
If the {@code ZoneId} parsed does not indicate daylight saving time, the standard offset will be used at the local time-line overlap as specified in the {@link ChronoZonedDateTime#withLaterOffsetAtOverlap()} method to form the instant.

src/java.base/share/classes/java/time/format/Parsed.java line 139:

> 137:      * The parsed zone name type.
> 138:      */
> 139:     int zoneNameType = -1;

Could be an Enum if that helps with readability.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6527

From itakiguchi at openjdk.java.net  Wed Nov 24 22:49:03 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 24 Nov 2021 22:49:03 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <_QbaoDO0VE5FNiLn4P7MzcNmgmuQbEz91_4giSGKFkA=.0310a8b1-a171-4de5-a0a3-7ea8d3564188@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <_QbaoDO0VE5FNiLn4P7MzcNmgmuQbEz91_4giSGKFkA=.0310a8b1-a171-4de5-a0a3-7ea8d3564188@github.com>
Message-ID: <VMSKOLxfyyIfUPFSz-aDNsowH9AN8c7aMZquVXHSLBo=.05938046-e2a5-4ed3-8faf-9dbc64e9b806@github.com>

On Wed, 24 Nov 2021 18:35:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277398: javac does not accept encoding name COMPAT
>
> Sorry, but I am kind of lost what you are expecting here. All the logs that you provided seem to be working exactly what is expected. Are you expecting `COMPAT` to auto-detect the source file (Hello.java) encoding?

Hello @naotoj .
I'm sorry, my explanation was not enough.
I prefer to use `-encoding XXX` option for javac instead of `-J-Dfile.encoding=COMPAT` since working behavior is not same.
But I don't want to find out native encoding name `XXX` before compilation.
Native encoding name is not easy to find out without executing java,
Locale's charmap name was `EUC-JP`, but Java's encoding name was `EUC-JP-LINUX` in the above case.
I think another option is required to reference native encoding.
`-encoding COMPAT` is one example.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From naoto at openjdk.java.net  Wed Nov 24 23:25:22 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 23:25:22 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v3]
In-Reply-To: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
Message-ID: <ykoiUdxeydiDnkwSLRVQOYGRfQ2mVD9zp5Lqy_qhFNw=.b6d04959-b553-41b2-8882-6b4ddbe99fd3@github.com>

> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Replaced integer literals.
 - Refined wording #2

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6527/files
  - new: https://git.openjdk.java.net/jdk/pull/6527/files/99ad3cad..89c894ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6527&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6527&range=01-02

  Stats: 18 lines in 4 files changed: 2 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6527.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6527/head:pull/6527

PR: https://git.openjdk.java.net/jdk/pull/6527

From naoto at openjdk.java.net  Wed Nov 24 23:25:23 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 23:25:23 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v2]
In-Reply-To: <D-4oGRVSw3zhNT-z4NvwjdFrH2_ea1qGL3a_klTUn6E=.b3fca3c9-fc84-4073-b063-08c9dc58d691@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <D-4oGRVSw3zhNT-z4NvwjdFrH2_ea1qGL3a_klTUn6E=.b3fca3c9-fc84-4073-b063-08c9dc58d691@github.com>
Message-ID: <rzs53xRKnZtixIeoH7r_rBuLXhL_KKf6SlxnKThPbaI=.171cfec8-ab43-4d2e-9aa5-ce9a7156786d@github.com>

On Tue, 23 Nov 2021 23:50:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording

Thanks, Joe. Refined the wording in the compatibility assessment in the CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6527

From naoto at openjdk.java.net  Wed Nov 24 23:25:25 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 23:25:25 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v2]
In-Reply-To: <20wq89Ukhi0d8oNpoVEwbHEyYMHw69lPJVq8ov_pC_0=.c90b6c60-f08b-4833-b23a-3b0faf6170ae@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <D-4oGRVSw3zhNT-z4NvwjdFrH2_ea1qGL3a_klTUn6E=.b3fca3c9-fc84-4073-b063-08c9dc58d691@github.com>
 <20wq89Ukhi0d8oNpoVEwbHEyYMHw69lPJVq8ov_pC_0=.c90b6c60-f08b-4833-b23a-3b0faf6170ae@github.com>
Message-ID: <mro9ZQLeNDkC4vU5ETdrtJwZph-7QESZrwUWKPaiZ-s=.ebea47d6-1151-49cf-92a1-f57df5459013@github.com>

On Wed, 24 Nov 2021 21:27:15 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refined wording
>
> src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 509:
> 
>> 507:  * parsed from the zone name that does not imply daylight saving time, then
>> 508:  * {@link ChronoZonedDateTime#withLaterOffsetAtOverlap()} is issued
>> 509:  * to use the standard offset at the overlap, before forming the instant.
> 
> Is the standard offset the subject instead of the withLaterOffsetAtOverlap method? Calling the method seems to be an impl detail to me. We might rephrase the sentence to sth. like:
> If the {@code ZoneId} parsed does not indicate daylight saving time, the standard offset will be used at the local time-line overlap as specified in the {@link ChronoZonedDateTime#withLaterOffsetAtOverlap()} method to form the instant.

Removed the method, and made `standard offset` the subject of the sentence.

> src/java.base/share/classes/java/time/format/Parsed.java line 139:
> 
>> 137:      * The parsed zone name type.
>> 138:      */
>> 139:     int zoneNameType = -1;
> 
> Could be an Enum if that helps with readability.

Since the index needs some calculation, I left it as `int`. Changed to use the constant fields for better readability.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6527

From naoto at openjdk.java.net  Thu Nov 25 00:00:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 25 Nov 2021 00:00:07 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <qnTF4Od1wHzZMF9Y7acPSs6jso_unZDuhMYHvl-J4lY=.54e1caee-1f36-4849-a45d-92c7ba167c48@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

If you give `-J-Dfile.encoding=COMPAT`, you don't need to know the native encoding name beforehand or at all, do you? All things are done in `EUC-JP` under the cover.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From joehw at openjdk.java.net  Thu Nov 25 00:11:04 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 25 Nov 2021 00:11:04 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v3]
In-Reply-To: <ykoiUdxeydiDnkwSLRVQOYGRfQ2mVD9zp5Lqy_qhFNw=.b6d04959-b553-41b2-8882-6b4ddbe99fd3@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <ykoiUdxeydiDnkwSLRVQOYGRfQ2mVD9zp5Lqy_qhFNw=.b6d04959-b553-41b2-8882-6b4ddbe99fd3@github.com>
Message-ID: <ZKbpkDUKbwyqsWYeXLN_ynvVYGFa9P9L85Zm_Emh_t8=.727883a6-a34a-44a7-a98c-8b637c1fdf71@github.com>

On Wed, 24 Nov 2021 23:25:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replaced integer literals.
>  - Refined wording #2

Thanks Naoto. The change Look good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6527

From itakiguchi at openjdk.java.net  Thu Nov 25 01:02:09 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 25 Nov 2021 01:02:09 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

As I explained before, output file encoding which is created by `-Xstdout` option is changed to native encoding instead of UTF-8 by `-J-Dfile.encoding=COMPAT`.
In case of Linux ja_JP.eucjp locale, your explanation may be acceptable.
But how  about Windows platform ?
How can user find encoding name without running java ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From scolebourne at openjdk.java.net  Thu Nov 25 08:30:10 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 25 Nov 2021 08:30:10 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v3]
In-Reply-To: <ykoiUdxeydiDnkwSLRVQOYGRfQ2mVD9zp5Lqy_qhFNw=.b6d04959-b553-41b2-8882-6b4ddbe99fd3@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <ykoiUdxeydiDnkwSLRVQOYGRfQ2mVD9zp5Lqy_qhFNw=.b6d04959-b553-41b2-8882-6b4ddbe99fd3@github.com>
Message-ID: <Dky7dASUaI3r0q0KTU-Za1PdmhxS4jeCv_Gjg2auW7Y=.d8bba6b3-17a3-416a-a47d-809c68b676a1@github.com>

On Wed, 24 Nov 2021 23:25:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replaced integer literals.
>  - Refined wording #2

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 508:

> 506:  * of {@link ChronoLocalDateTime#atZone(ZoneId)}. If the {@code ZoneId} was
> 507:  * parsed from the zone name that does not indicate daylight saving time, then
> 508:  * the standard offset will be used at the local time-line overlap.

As written, I would read it as being the generic zone name that gets altered, rather than a zone name that explicitly indicates "winter" time. maybe:

"If the {@code ZoneId} was parsed from a zone name that indicates whether daylight saving time in in operation or not, then that fact will be used to select the correct offset at the local time-line overlap."

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 4906:

> 4904:         private static class LENIENT extends CI {
> 4905: 
> 4906:             private LENIENT(String k, String v, int t, PrefixTree child) {

Is class `LENIENT` actually in use?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6527

From duke at openjdk.java.net  Fri Nov 26 12:54:21 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 26 Nov 2021 12:54:21 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code
Message-ID: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>

Instead of something like

long x;
long y;
return (x < y) ? -1 : ((x == y) ? 0 : 1);

we can use `return Long.compare(x, y);`

All replacements are done with IDE.

-------------

Commit messages:
 - 8277868: Use Comparable.compare() instead of surrogate code

Changes: https://git.openjdk.java.net/jdk/pull/6575/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6575&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277868
  Stats: 70 lines in 12 files changed: 2 ins; 44 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6575/head:pull/6575

PR: https://git.openjdk.java.net/jdk/pull/6575

From dfuchs at openjdk.java.net  Fri Nov 26 15:37:14 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 26 Nov 2021 15:37:14 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <lT1XZ3C4vlGYZ5ZehcpQzJciNEABanCJOh8aGMl6Nwo=.f124dce7-1d8f-4f9c-89c3-6017ff9e2eda@github.com>

On Fri, 26 Nov 2021 12:46:59 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

Changes to java.net look good. Please obtain approval from reviewers in the other areas before integrating.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575

From aivanov at openjdk.java.net  Sat Nov 27 18:54:05 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 27 Nov 2021 18:54:05 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>

On Sat, 11 Sep 2021 14:59:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

src/java.desktop/macosx/classes/com/apple/laf/AquaRootPaneUI.java line 78:

> 76:         final Component parent = c.getParent();
> 77: 
> 78:         if (parent instanceof JFrame frameParent) {

The `frameParent` variable was declared `final` before.
Suggestion:

        if (parent instanceof final JFrame frameParent) {

src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java line 148:

> 146:     protected static TableColumn getTableColumn(final JTableHeader target, final Object value) {
> 147:         if (!(value instanceof Integer idx)) return null;
> 148:         final int columnIndex = idx;

Probably, this expression could be simplified?
Suggestion:

        if (!(value instanceof final Integer columnIndex)) return null;

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 247:

> 245:         }},
> 246:         new Property<CPlatformWindow>(WINDOW_DOCUMENT_FILE) { public void applyProperty(final CPlatformWindow c, final Object value) {
> 247:             if (!(value instanceof java.io.File f)) {

Is `file` a better name?

src/java.desktop/share/classes/javax/swing/JOptionPane.java line 2336:

> 2334:         if (icon instanceof Serializable ser) {
> 2335:             values.addElement("icon");
> 2336:             values.addElement(ser);

I suggest omitting `ser` variable declaration: it's not used as `Serializable`, checking with `instanceof` is enough. This comment applies to all similar if-conditions below.

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1338:

> 1336:         }
> 1337:         // Save the popup, if it's Serializable.
> 1338:         if (popup instanceof Serializable ser) {

Suggestion:

        if (popup instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/JTree.java line 3132:

> 3130:         s.defaultWriteObject();
> 3131:         // Save the cellRenderer, if it's Serializable.
> 3132:         if (cellRenderer instanceof Serializable ser) {

Suggestion:

        if (cellRenderer instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java line 1301:

> 1299:         s.defaultWriteObject();
> 1300:         // Save the userObject, if it's Serializable.
> 1301:         if (userObject instanceof Serializable ser) {

Suggestion:

        if (userObject instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java line 694:

> 692:         s.defaultWriteObject();
> 693:         // Save the root, if it's Serializable.
> 694:         if (root instanceof Serializable ser) {

Suggestion:

        if (root instanceof Serializable) {

src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java line 1221:

> 1219:         s.defaultWriteObject();
> 1220:         // Save the rowMapper, if it implements Serializable
> 1221:         if (rowMapper instanceof Serializable ser) {

Suggestion:

        if (rowMapper instanceof Serializable) {

src/java.desktop/unix/classes/sun/awt/X11/XWindow.java line 312:

> 310:         }
> 311: 
> 312:         return window.getContentWindow();

Is the branch where 0 was returned impossible?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482

From duke at openjdk.java.net  Sat Nov 27 22:54:16 2021
From: duke at openjdk.java.net (Michael Bien)
Date: Sat, 27 Nov 2021 22:54:16 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <FePjU3YtcoGQx5qyfQX4eeb32FD48zgkuaVPlpSI_9s=.4cecb850-3bce-4e7f-b5ce-517eb7ea65f3@github.com>

On Fri, 26 Nov 2021 12:46:59 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 249:

> 247: 
> 248:         private static int sign(int num) {
> 249:             return Integer.compare(num, 0);

=> Integer.signum(num)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575

From itakiguchi at openjdk.java.net  Mon Nov 29 00:15:06 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 29 Nov 2021 00:15:06 GMT
Subject: <i18n dev> Integrated: 8274784: jshell: Garbled character was
 displayed by System.out.println(...) on Japanese Windows
In-Reply-To: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
References: <QhpztoLLxgeVEyw8YMhsMv0Mxp860YUm0UfrTackY9g=.9835b8c8-70a9-4be5-8950-1bf7e4a2bf16@github.com>
Message-ID: <I8d4Qxsx_2swr0ovbjxPD8vhZbXkniudp-jaWXpL-KA=.f239e9f4-50df-4058-871d-a34f356be262@github.com>

On Mon, 22 Nov 2021 16:08:58 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 was implemented by JDK18-b13.
> After JDK18-b13, garbled character was displayed by following code on Japanese Windows' command prompt.
> 
> System.out.println("\u3042")
> 
> Japanese "A" should be display ed, but garbled character was displayed.
> Also saved jshell command list did not work as expected if Japanese character was there.
> 
> Following issue has some information
> 8274544: Langtools command's usage were garbled on Japanese Windows #5771
> https://github.com/openjdk/jdk/pull/5771
> This issue also happens on Linux ja_JP.eucjp locale.
> RemoteExecutionControl.java change is required for this issue.
> 
> Also we cannot input Japanese character on Linux ja_JP.eucjp locale terminal.
> AbstractTerminal.java change is required for this issue.

This pull request has now been integrated.

Changeset: 8f9eb620
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8f9eb620acbc447cf9124b1fe5574a9f02115f45
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8274784: jshell: Garbled character was displayed by System.out.println(...) on Japanese Windows

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/6505

From duke at openjdk.java.net  Mon Nov 29 08:05:08 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 29 Nov 2021 08:05:08 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop
In-Reply-To: <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
Message-ID: <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>

On Sat, 27 Nov 2021 16:37:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Updated code checks both non-null and instance of a class in java.desktop module classes.
>> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
>> Similar cleanups
>> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
>> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaRootPaneUI.java line 78:
> 
>> 76:         final Component parent = c.getParent();
>> 77: 
>> 78:         if (parent instanceof JFrame frameParent) {
> 
> The `frameParent` variable was declared `final` before.
> Suggestion:
> 
>         if (parent instanceof final JFrame frameParent) {

Does it really worth keeping `final` here?
In my opinion it makes code unnecessary longer and harder to read in this case

> src/java.desktop/unix/classes/sun/awt/X11/XWindow.java line 312:
> 
>> 310:         }
>> 311: 
>> 312:         return window.getContentWindow();
> 
> Is the branch where 0 was returned impossible?

Yes. It was impossible.
Only way out of this cycle is when `peer instanceof XWindow` is `true`
https://github.com/openjdk/jdk/blob/0c7a4b8aa8bb672e87aae7090494719db018b9b1/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java#L306-L310

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482

From duke at openjdk.java.net  Mon Nov 29 08:17:41 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 29 Nov 2021 08:17:41 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop [v2]
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <13h9kfZ5bm6SzxmSe-1NjltlocI-qRZgA40Ihy-_QXI=.4ab29473-afea-4bc3-b887-abc372143a22@github.com>

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop
  apply review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5482/files
  - new: https://git.openjdk.java.net/jdk/pull/5482/files/250ba2c4..5a8cf2fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5482&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5482&range=00-01

  Stats: 32 lines in 8 files changed: 0 ins; 1 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5482/head:pull/5482

PR: https://git.openjdk.java.net/jdk/pull/5482

From duke at openjdk.java.net  Mon Nov 29 08:17:53 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 29 Nov 2021 08:17:53 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop [v2]
In-Reply-To: <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
Message-ID: <MwTBY51lFn3B2eMsLym-Z0o77g_KzPt5Bd1JXfQhuJE=.0e894be2-97c3-4182-afbf-1a7993bbc38b@github.com>

On Sat, 27 Nov 2021 16:27:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop
>>   apply review comments
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java line 148:
> 
>> 146:     protected static TableColumn getTableColumn(final JTableHeader target, final Object value) {
>> 147:         if (!(value instanceof Integer idx)) return null;
>> 148:         final int columnIndex = idx;
> 
> Probably, this expression could be simplified?
> Suggestion:
> 
>         if (!(value instanceof final Integer columnIndex)) return null;

done

> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 247:
> 
>> 245:         }},
>> 246:         new Property<CPlatformWindow>(WINDOW_DOCUMENT_FILE) { public void applyProperty(final CPlatformWindow c, final Object value) {
>> 247:             if (!(value instanceof java.io.File f)) {
> 
> Is `file` a better name?

updated

> src/java.desktop/share/classes/javax/swing/JOptionPane.java line 2336:
> 
>> 2334:         if (icon instanceof Serializable ser) {
>> 2335:             values.addElement("icon");
>> 2336:             values.addElement(ser);
> 
> I suggest omitting `ser` variable declaration: it's not used as `Serializable`, checking with `instanceof` is enough. This comment applies to all similar if-conditions below.

ok

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1338:
> 
>> 1336:         }
>> 1337:         // Save the popup, if it's Serializable.
>> 1338:         if (popup instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (popup instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/JTree.java line 3132:
> 
>> 3130:         s.defaultWriteObject();
>> 3131:         // Save the cellRenderer, if it's Serializable.
>> 3132:         if (cellRenderer instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (cellRenderer instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java line 1301:
> 
>> 1299:         s.defaultWriteObject();
>> 1300:         // Save the userObject, if it's Serializable.
>> 1301:         if (userObject instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (userObject instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java line 694:
> 
>> 692:         s.defaultWriteObject();
>> 693:         // Save the root, if it's Serializable.
>> 694:         if (root instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (root instanceof Serializable) {

updated

> src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java line 1221:
> 
>> 1219:         s.defaultWriteObject();
>> 1220:         // Save the rowMapper, if it implements Serializable
>> 1221:         if (rowMapper instanceof Serializable ser) {
> 
> Suggestion:
> 
>         if (rowMapper instanceof Serializable) {

updated

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482

From duke at openjdk.java.net  Mon Nov 29 08:18:47 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 29 Nov 2021 08:18:47 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v2]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8277868: Use Integer.signum() in BasicTableUI

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/8fa8242a..6744a562

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6575&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6575&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6575/head:pull/6575

PR: https://git.openjdk.java.net/jdk/pull/6575

From duke at openjdk.java.net  Mon Nov 29 08:18:50 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 29 Nov 2021 08:18:50 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v2]
In-Reply-To: <FePjU3YtcoGQx5qyfQX4eeb32FD48zgkuaVPlpSI_9s=.4cecb850-3bce-4e7f-b5ce-517eb7ea65f3@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <FePjU3YtcoGQx5qyfQX4eeb32FD48zgkuaVPlpSI_9s=.4cecb850-3bce-4e7f-b5ce-517eb7ea65f3@github.com>
Message-ID: <J_1CFL2TOKhoTP9aRpby8TkVZFZusYE8fxP4ZssRkeU=.4c08f82b-edf8-447b-b8bb-e036465563cb@github.com>

On Sat, 27 Nov 2021 22:50:55 GMT, Michael Bien <duke at openjdk.java.net> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 249:
> 
>> 247: 
>> 248:         private static int sign(int num) {
>> 249:             return Integer.compare(num, 0);
> 
> => Integer.signum(num)

Done!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575

From aivanov at openjdk.java.net  Mon Nov 29 11:20:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 29 Nov 2021 11:20:17 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop [v2]
In-Reply-To: <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
 <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
Message-ID: <AeEWZbGNBoruJxZyWGkiRP_0FVNCLE6gI5i_Iwx1bLA=.19095e1e-71a3-4dd4-b62a-5542d75a6c1c@github.com>

On Mon, 29 Nov 2021 08:00:19 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.desktop/unix/classes/sun/awt/X11/XWindow.java line 312:
>> 
>>> 310:         }
>>> 311: 
>>> 312:         return window.getContentWindow();
>> 
>> Is the branch where 0 was returned impossible?
>
> Yes. It was impossible.
> Only way out of this cycle is when `peer instanceof XWindow` is `true`
> https://github.com/openjdk/jdk/blob/0c7a4b8aa8bb672e87aae7090494719db018b9b1/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java#L306-L310

Thanks, I just wanted to confirm my own understanding.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482

From aivanov at openjdk.java.net  Mon Nov 29 11:23:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 29 Nov 2021 11:23:11 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop [v2]
In-Reply-To: <13h9kfZ5bm6SzxmSe-1NjltlocI-qRZgA40Ihy-_QXI=.4ab29473-afea-4bc3-b887-abc372143a22@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <13h9kfZ5bm6SzxmSe-1NjltlocI-qRZgA40Ihy-_QXI=.4ab29473-afea-4bc3-b887-abc372143a22@github.com>
Message-ID: <NXbSZQKsXkynrVaRmHlIA2dC27DAzMsag4fQdSX7EVQ=.8b0fb80b-31be-49eb-bb24-ac316dab236f@github.com>

On Mon, 29 Nov 2021 08:17:41 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> Updated code checks both non-null and instance of a class in java.desktop module classes.
>> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
>> Similar cleanups
>> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
>> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop
>   apply review comments

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482

From aivanov at openjdk.java.net  Mon Nov 29 11:23:12 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 29 Nov 2021 11:23:12 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop [v2]
In-Reply-To: <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
 <tRXWyvjxILGa6Ueq9XfxU9Q52I2NylXnz38Ik_5RFmo=.b478e5ed-ac16-44d6-9550-267d74e9fdd9@github.com>
 <HNZ6Zc-qVuD5J5QTHUWY2DkfnSNaJiytNM4mdZHXOh8=.723e0011-1ef1-43b1-b1e5-8d08d4b96551@github.com>
Message-ID: <DNbDrBxvJbq0N8aVGQKi0_rcFjHuW-2cJYtREFoUORw=.65f3a4e7-d609-4507-ab34-ee6549578c0b@github.com>

On Mon, 29 Nov 2021 08:01:56 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaRootPaneUI.java line 78:
>> 
>>> 76:         final Component parent = c.getParent();
>>> 77: 
>>> 78:         if (parent instanceof JFrame frameParent) {
>> 
>> The `frameParent` variable was declared `final` before.
>> Suggestion:
>> 
>>         if (parent instanceof final JFrame frameParent) {
>
> Does it really worth keeping `final` here?
> In my opinion it makes code unnecessary longer and harder to read in this case

Agree, `final` doesn't add much value, it's clear the value of `frameParent` doesn't change in the following three lines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5482

From naoto at openjdk.java.net  Mon Nov 29 17:32:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 29 Nov 2021 17:32:08 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>
Message-ID: <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@github.com>

On Thu, 25 Nov 2021 00:58:47 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> But how about Windows platform ?

If the user specifies `-J-Dfile.encoding=COMPAT`, all operations are done in `MS932` on Japanese Windows.

> How can user find encoding name without running java ?

I still don't get why the user needs to know the encoding if they specifies `COMPAT` property.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From naoto at openjdk.java.net  Mon Nov 29 17:41:34 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 29 Nov 2021 17:41:34 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v4]
In-Reply-To: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
Message-ID: <m3UtyMyftc4fZddcVZ99ZQBLxr-DTsZxLCLt1_Y5xw8=.f65c4e7e-80c1-4d0f-b97c-0fc535055272@github.com>

> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refined wording. Removed `LENIENT` parser. Added tests for CI.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6527/files
  - new: https://git.openjdk.java.net/jdk/pull/6527/files/89c894ae..2be302f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6527&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6527&range=02-03

  Stats: 97 lines in 3 files changed: 12 ins; 83 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6527.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6527/head:pull/6527

PR: https://git.openjdk.java.net/jdk/pull/6527

From naoto at openjdk.java.net  Mon Nov 29 17:41:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 29 Nov 2021 17:41:40 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v3]
In-Reply-To: <Dky7dASUaI3r0q0KTU-Za1PdmhxS4jeCv_Gjg2auW7Y=.d8bba6b3-17a3-416a-a47d-809c68b676a1@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <ykoiUdxeydiDnkwSLRVQOYGRfQ2mVD9zp5Lqy_qhFNw=.b6d04959-b553-41b2-8882-6b4ddbe99fd3@github.com>
 <Dky7dASUaI3r0q0KTU-Za1PdmhxS4jeCv_Gjg2auW7Y=.d8bba6b3-17a3-416a-a47d-809c68b676a1@github.com>
Message-ID: <UzCRc9tGy5AzS2XXZwegwKUMA0IN0DnZEefrnE6YgkQ=.c847be6e-392f-4625-8051-287866358d71@github.com>

On Thu, 25 Nov 2021 08:26:56 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replaced integer literals.
>>  - Refined wording #2
>
> src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 508:
> 
>> 506:  * of {@link ChronoLocalDateTime#atZone(ZoneId)}. If the {@code ZoneId} was
>> 507:  * parsed from the zone name that does not indicate daylight saving time, then
>> 508:  * the standard offset will be used at the local time-line overlap.
> 
> As written, I would read it as being the generic zone name that gets altered, rather than a zone name that explicitly indicates "winter" time. maybe:
> 
> "If the {@code ZoneId} was parsed from a zone name that indicates whether daylight saving time in in operation or not, then that fact will be used to select the correct offset at the local time-line overlap."

Modified as suggested.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 4906:
> 
>> 4904:         private static class LENIENT extends CI {
>> 4905: 
>> 4906:             private LENIENT(String k, String v, int t, PrefixTree child) {
> 
> Is class `LENIENT` actually in use?

Removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6527

From naoto at openjdk.java.net  Mon Nov 29 18:55:19 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 29 Nov 2021 18:55:19 GMT
Subject: <i18n dev> RFR: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently
Message-ID: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>

Fixing tests that fail at DST->STD offset transition. Simply skipping the tests on that occasion.

-------------

Commit messages:
 - 8190748: java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest fail intermittently

Changes: https://git.openjdk.java.net/jdk/pull/6598/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6598&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8190748
  Stats: 21 lines in 2 files changed: 14 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6598.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6598/head:pull/6598

PR: https://git.openjdk.java.net/jdk/pull/6598

From rriggs at openjdk.java.net  Mon Nov 29 20:16:09 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 29 Nov 2021 20:16:09 GMT
Subject: <i18n dev> RFR: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently
In-Reply-To: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
References: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
Message-ID: <O0_o-k60vTV-FPc-z8nstgedS3jWXsDo8yHCbp6CT7o=.ae8e58d9-fcb1-434b-9b3e-f9ec41e1ad90@github.com>

On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing tests that fail at DST->STD offset transition. Simply skipping the tests on that occasion.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6598

From joehw at openjdk.java.net  Mon Nov 29 21:05:00 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 29 Nov 2021 21:05:00 GMT
Subject: <i18n dev> RFR: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently
In-Reply-To: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
References: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
Message-ID: <hkjtDkKuvpL6fr-MJLzwv8LK19SIycFPJD6hbMx9tsI=.9229b50f-2106-45da-8773-779afc40a3ea@github.com>

On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing tests that fail at DST->STD offset transition. Simply skipping the tests on that occasion.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6598

From lancea at openjdk.java.net  Mon Nov 29 21:13:04 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 29 Nov 2021 21:13:04 GMT
Subject: <i18n dev> RFR: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently
In-Reply-To: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
References: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
Message-ID: <TgUY4kRwzSV8HkpvZEDryI-AtlP4KaG-aZO9o7jNT0g=.d9ee1199-7277-4465-99ee-a19a0fa756e2@github.com>

On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing tests that fail at DST->STD offset transition. Simply skipping the tests on that occasion.

test/jdk/java/text/Format/DateFormat/DateFormatTest.java line 349:

> 347:         var defZone = ZoneId.systemDefault();
> 348:         if (defZone.getRules().getTransition(date1.toInstant().atZone(defZone).toLocalDateTime()) != null) {
> 349:             logln("At the offset transition. Round trip test skipped.");

Should the message be more inlined with the test name vs indicate Round trip test is skipped?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6598

From naoto at openjdk.java.net  Mon Nov 29 21:59:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 29 Nov 2021 21:59:35 GMT
Subject: <i18n dev> RFR: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently [v2]
In-Reply-To: <TgUY4kRwzSV8HkpvZEDryI-AtlP4KaG-aZO9o7jNT0g=.d9ee1199-7277-4465-99ee-a19a0fa756e2@github.com>
References: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
 <TgUY4kRwzSV8HkpvZEDryI-AtlP4KaG-aZO9o7jNT0g=.d9ee1199-7277-4465-99ee-a19a0fa756e2@github.com>
Message-ID: <fM1g3KWB-g6Cj_WAKbfAnlCCPefhJbkUFzdInWGGMqU=.86c33434-7671-419d-bc5d-ddd8f363fff0@github.com>

On Mon, 29 Nov 2021 21:09:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed to not skipping the test in DateFormatTest.java
>
> test/jdk/java/text/Format/DateFormat/DateFormatTest.java line 349:
> 
>> 347:         var defZone = ZoneId.systemDefault();
>> 348:         if (defZone.getRules().getTransition(date1.toInstant().atZone(defZone).toLocalDateTime()) != null) {
>> 349:             logln("At the offset transition. Round trip test skipped.");
> 
> Should the message be more inlined with the test name vs indicate Round trip test is skipped?

I changed the test not to skip even at the overlap, by explicitly giving the zone pattern. Unfortunately, this cannot be applied to the other location in `NonGregorianFormatTest`, because the argument is a bare `DateFormat`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6598

From naoto at openjdk.java.net  Mon Nov 29 21:59:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 29 Nov 2021 21:59:31 GMT
Subject: <i18n dev> RFR: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently [v2]
In-Reply-To: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
References: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
Message-ID: <9-DbpcVeegzwGdzJojFuAjnvAXPoFoxYUjvbY5rVYys=.ce898a73-0e09-4bea-bfc3-544b6fd71a63@github.com>

> Fixing tests that fail at DST->STD offset transition. Simply skipping the tests on that occasion.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Changed to not skipping the test in DateFormatTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6598/files
  - new: https://git.openjdk.java.net/jdk/pull/6598/files/8fee6741..ecbedb09

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6598&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6598&range=00-01

  Stats: 11 lines in 1 file changed: 2 ins; 8 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6598.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6598/head:pull/6598

PR: https://git.openjdk.java.net/jdk/pull/6598

From rriggs at openjdk.java.net  Tue Nov 30 21:06:09 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 30 Nov 2021 21:06:09 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v2]
In-Reply-To: <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
Message-ID: <UF7L_-UyjOPrjT0YxgBBcgzcqXnF3ecehk6GPVhQuMA=.d0969a24-13a7-4c26-aec0-2cfd7fdda0f4@github.com>

On Mon, 29 Nov 2021 08:18:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Use Integer.signum() in BasicTableUI

The core-libs file changes look fine.
A 'client' reviewer should take a look too.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6575

From lancea at openjdk.java.net  Tue Nov 30 21:48:10 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 30 Nov 2021 21:48:10 GMT
Subject: <i18n dev> RFR: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently [v2]
In-Reply-To: <9-DbpcVeegzwGdzJojFuAjnvAXPoFoxYUjvbY5rVYys=.ce898a73-0e09-4bea-bfc3-544b6fd71a63@github.com>
References: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
 <9-DbpcVeegzwGdzJojFuAjnvAXPoFoxYUjvbY5rVYys=.ce898a73-0e09-4bea-bfc3-544b6fd71a63@github.com>
Message-ID: <Mr-q5jeQjhJb3MAYPVWwUaDfxD5fFaGap3inj7NPMi0=.56a3b550-a6c7-46a7-a891-d7e74e269dce@github.com>

On Mon, 29 Nov 2021 21:59:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing tests that fail at DST->STD offset transition. Simply skipping the tests on that occasion.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed to not skipping the test in DateFormatTest.java

looks good to me

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6598

From naoto at openjdk.java.net  Tue Nov 30 22:45:44 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 30 Nov 2021 22:45:44 GMT
Subject: <i18n dev> Integrated: 8190748:
 java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest
 fail intermittently
In-Reply-To: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
References: <IeoOV-9ntNAd8ZywXZBWghRAViU84gdYHVKVvbreowU=.74a569c4-5ca9-4539-8d4f-ca7851438b20@github.com>
Message-ID: <D7DG8z6foVwAQTu8hxWXaKuLWtMs2RyS81ztGmEbQjo=.4906c10a-acae-4db6-b684-1fc58f1f2c98@github.com>

On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing tests that fail at DST->STD offset transition. Simply skipping the tests on that occasion.

This pull request has now been integrated.

Changeset: f1c20e91
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1c20e91d822c6df4c5da895f2abd6305e00bf8b
Stats:     12 lines in 2 files changed: 6 ins; 0 del; 6 mod

8190748: java/text/Format/DateFormat/DateFormatTest.java and NonGregorianFormatTest fail intermittently

Reviewed-by: rriggs, joehw, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/6598