From jlu at openjdk.org  Wed Mar  1 00:39:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Mar 2023 00:39:22 GMT
Subject: <i18n dev> Integrated: 8282319: java.util.Locale method to stream
 available Locales
In-Reply-To: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
References: <QxcV7IwdW13WfT0X0PKyWBWpo_rP588AgHIYiUu3E_Q=.82b88828-e8ec-4f3c-a75a-ec88b589d4e2@github.com>
Message-ID: <xPKJsjWRbus9A8cQ9dwUlVHFcHqdUSfb_ebujVTNsGU=.28bbcc8d-4316-4a38-8115-d0a5a93e398d@github.com>

On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR adds a new method to java.util.Locale which returns Stream<Locale>
> 
> The contents of the Stream are composed of the same underlying elements as Locale.getAvailableLocales().
> 
> This method allows streaming of the Locale array without creating a defensive copy.

This pull request has now been integrated.

Changeset: 7e47d51e
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e47d51e10eef7b3bead636d20ff392e7b1dd185
Stats:     116 lines in 3 files changed: 113 ins; 1 del; 2 mod

8282319: java.util.Locale method to stream available Locales

Reviewed-by: stsypanov, naoto, lancea, rriggs

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

PR: https://git.openjdk.org/jdk/pull/12269

From stsypanov at openjdk.org  Wed Mar  1 13:37:07 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 1 Mar 2023 13:37:07 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <5WPSbOxpK4B9suNeRfrL93MSbq8wABAMB_fhI1raCiU=.f15f94e2-811a-4501-a11c-15560a3dabb8@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Let's wait

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

PR: https://git.openjdk.org/jdk/pull/12328

From naoto at openjdk.org  Wed Mar  1 19:59:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 Mar 2023 19:59:05 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
Message-ID: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>

This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.

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

Commit messages:
 - 8303039: Utilize `coverageLevels.txt`

Changes: https://git.openjdk.org/jdk/pull/12812/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12812&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303039
  Stats: 318 lines in 4 files changed: 314 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12812.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12812/head:pull/12812

PR: https://git.openjdk.org/jdk/pull/12812

From jlu at openjdk.org  Wed Mar  1 22:03:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Mar 2023 22:03:57 GMT
Subject: <i18n dev> RFR: 8303275: Use {@Return and @linkplain in Locale and
 related classes
Message-ID: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>

This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain.

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

Commit messages:
 - fix conflicts
 - Locale copyright
 - Use @linkplain and {@return in Locale
 - Use {@return and spacing in LSPP
 - Use {@return and @linkplain in LSP

Changes: https://git.openjdk.org/jdk/pull/12780/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12780&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303275
  Stats: 107 lines in 3 files changed: 11 ins; 19 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/12780.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12780/head:pull/12780

PR: https://git.openjdk.org/jdk/pull/12780

From jlu at openjdk.org  Wed Mar  1 22:04:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Mar 2023 22:04:12 GMT
Subject: <i18n dev> RFR: 8303275: Use {@Return and @linkplain in Locale
 and related classes
In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
Message-ID: <rg2x5OSTifqL7YSSZW9aqHe5zW4G1anGEtacLzlx0rY=.fae9e317-77ec-40fb-825d-68950681a987@github.com>

On Tue, 28 Feb 2023 00:09:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain.

src/java.base/share/classes/java/util/Locale.java line 1200:

> 1198: 
> 1199:     /**
> 1200:      * {@return an array of installed locales}

Same as above, differs with "all"

src/java.base/share/classes/java/util/Locale.java line 1239:

> 1237: 
> 1238:     /**
> 1239:      * {@return a {@code Set} of ISO3166 country codes for the specified type}

This and other instances will have the Returns ... and @return ... differ by a single word. Such as

_Returns a {@code Set} of ISO3166 country..._ 
vs 
_ at return a {@code Set} of ISO country..._

{@return is used when the Returns ... and @return ... are identical. 

I want to double check that using {@return for these instances is acceptable (even though they are technically not identical), if not I can revert them.

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 151:

> 149: 
> 150:     /**
> 151:      * {@return an array of the available locales for all the provider classes}

Same as above, differs with "the"

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 161:

> 159: 
> 160:     /**
> 161:      * {@return an array of the available locales}

Same as above, differs with "the"

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

PR: https://git.openjdk.org/jdk/pull/12780

From jlu at openjdk.org  Wed Mar  1 22:06:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Mar 2023 22:06:13 GMT
Subject: <i18n dev> RFR: 8303472: Display name for region TR
Message-ID: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>

This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name).



This change targets both the CLDR and COMPAT data.

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

Commit messages:
 - Spot change TR for COMPAT
 - Spot change TR region name

Changes: https://git.openjdk.org/jdk/pull/12816/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12816&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303472
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12816.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12816/head:pull/12816

PR: https://git.openjdk.org/jdk/pull/12816

From naoto at openjdk.org  Wed Mar  1 22:58:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 Mar 2023 22:58:22 GMT
Subject: <i18n dev> RFR: 8303472: Display name for region TR
In-Reply-To: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
References: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
Message-ID: <n_KehQqzmBIzae88d1SDl8hAIIyNv0syBk5yuiC04o8=.a99374aa-104b-4cd7-a6cc-44d577037c6a@github.com>

On Wed, 1 Mar 2023 21:58:00 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name).
> 
> 
> 
> This change targets both the CLDR and COMPAT data.

Please supply test cases with these changes (`sun/text/resources/LocaleDataTest.java`), also copyright year changes for COMPAT properties.
Otherwise LGTM

src/java.base/share/classes/sun/util/resources/LocaleNames.properties line 1097:

> 1095: TN=Tunisia
> 1096: TO=Tonga
> 1097: TR=T?rkiye

I believe this is fine, but please confirm that this ends up correct u-umlaut when you get the text. It is somewhat a rare case where ISO-8859-1 has the character and the byte sequence differs between ISO-8859-1 and UTF-8.

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

PR: https://git.openjdk.org/jdk/pull/12816

From duke at openjdk.org  Wed Mar  1 23:14:06 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Wed, 1 Mar 2023 23:14:06 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
Message-ID: <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>

On Wed, 1 Mar 2023 19:50:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

make/data/cldr/common/properties/coverageLevels.txt line 2:

> 1: #	coverageLevels.txt
> 2: #	Copyright ? 2022 Unicode, Inc.

older version?

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1212:

> 1210:                     a -> Locale.forLanguageTag(a[0].trim().replaceAll("_", "-")),
> 1211:                     a -> a[1].trim(),
> 1212:                     (v1, v2) -> v2,

this will grab all listed entries.  Right now, that will get you basic and above.  Ideally you would include if `v1` is one of `(basic|moderate|modern|comprehensive)` ??I'm proposing to add `core` or maybe even `undefined` locales in this list (though no consensus yet)

make/jdk/src/classes/build/tools/cldrconverter/OtherCommonLocales.properties line 140:

> 138: 
> 139: # Not listed, but existed
> 140: sr-Latn=Serbian (Latin)

[CLDR-16449](https://unicode-org.atlassian.net/browse/CLDR-16449)

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

PR: https://git.openjdk.org/jdk/pull/12812

From duke at openjdk.org  Wed Mar  1 23:14:09 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Wed, 1 Mar 2023 23:14:09 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>
Message-ID: <NyAHP1NxqxSU2VKmMCUOYpF5-2nuUF3wi4OHCGxSxtU=.719bfe30-3c72-4b58-81d3-f7229a57f159@github.com>

On Wed, 1 Mar 2023 23:02:06 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.
>
> make/data/cldr/common/properties/coverageLevels.txt line 2:
> 
>> 1: #	coverageLevels.txt
>> 2: #	Copyright ? 2022 Unicode, Inc.
> 
> older version?

is this from the alpha2 drop? or v42's?

> make/jdk/src/classes/build/tools/cldrconverter/OtherCommonLocales.properties line 140:
> 
>> 138: 
>> 139: # Not listed, but existed
>> 140: sr-Latn=Serbian (Latin)
> 
> [CLDR-16449](https://unicode-org.atlassian.net/browse/CLDR-16449)

you might want to give yourself a task to periodically review this file.

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

PR: https://git.openjdk.org/jdk/pull/12812

From duke at openjdk.org  Wed Mar  1 23:17:06 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Wed, 1 Mar 2023 23:17:06 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
Message-ID: <G5NKyBGxlBvTgzK4Y3NaOsyQmdKokA3oop4zvgyfrd0=.132b98e4-7aa7-4e7f-9486-6b8c8a1ed785@github.com>

On Wed, 1 Mar 2023 19:50:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.

my openjdk name should be `srl` ???i'm still there https://openjdk.org/census#srl

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

PR: https://git.openjdk.org/jdk/pull/12812

From naoto at openjdk.org  Wed Mar  1 23:23:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 Mar 2023 23:23:13 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <NyAHP1NxqxSU2VKmMCUOYpF5-2nuUF3wi4OHCGxSxtU=.719bfe30-3c72-4b58-81d3-f7229a57f159@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>
 <NyAHP1NxqxSU2VKmMCUOYpF5-2nuUF3wi4OHCGxSxtU=.719bfe30-3c72-4b58-81d3-f7229a57f159@github.com>
Message-ID: <4_1vLEFwWP1R-W4kolNqlOnjvB8dvkNam6dCd-Pb8i8=.dc93be58-f4f2-4edc-843f-d8eea2c1377f@github.com>

On Wed, 1 Mar 2023 23:02:33 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> make/data/cldr/common/properties/coverageLevels.txt line 2:
>> 
>>> 1: #	coverageLevels.txt
>>> 2: #	Copyright ? 2022 Unicode, Inc.
>> 
>> older version?
>
> is this from the alpha2 drop? or v42's?

Yes, this is the file from the released CLDR v42. We have not integrated v43 yet.

>> make/jdk/src/classes/build/tools/cldrconverter/OtherCommonLocales.properties line 140:
>> 
>>> 138: 
>>> 139: # Not listed, but existed
>>> 140: sr-Latn=Serbian (Latin)
>> 
>> [CLDR-16449](https://unicode-org.atlassian.net/browse/CLDR-16449)
>
> you might want to give yourself a task to periodically review this file.

Thanks!

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

PR: https://git.openjdk.org/jdk/pull/12812

From duke at openjdk.org  Wed Mar  1 23:23:14 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Wed, 1 Mar 2023 23:23:14 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <4_1vLEFwWP1R-W4kolNqlOnjvB8dvkNam6dCd-Pb8i8=.dc93be58-f4f2-4edc-843f-d8eea2c1377f@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>
 <NyAHP1NxqxSU2VKmMCUOYpF5-2nuUF3wi4OHCGxSxtU=.719bfe30-3c72-4b58-81d3-f7229a57f159@github.com>
 <4_1vLEFwWP1R-W4kolNqlOnjvB8dvkNam6dCd-Pb8i8=.dc93be58-f4f2-4edc-843f-d8eea2c1377f@github.com>
Message-ID: <pqn0KAwUBRCMs4U2dvpK7h9e_pYJx-dGwnAP6el7Wpc=.8a11727f-754d-4d9d-97f4-69d8e21ea051@github.com>

On Wed, 1 Mar 2023 23:18:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> is this from the alpha2 drop? or v42's?
>
> Yes, this is the file from the released CLDR v42. We have not integrated v43 yet.

this is great groundwork.

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

PR: https://git.openjdk.org/jdk/pull/12812

From naoto at openjdk.org  Wed Mar  1 23:23:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 Mar 2023 23:23:16 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>
Message-ID: <QUWNMalmxySM95Y2RB-dRDUVADlDnoLAUa6DZeQf1uY=.630f28a0-7fb5-491a-8636-4a88873f58a5@github.com>

On Wed, 1 Mar 2023 23:06:10 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.
>
> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1212:
> 
>> 1210:                     a -> Locale.forLanguageTag(a[0].trim().replaceAll("_", "-")),
>> 1211:                     a -> a[1].trim(),
>> 1212:                     (v1, v2) -> v2,
> 
> this will grab all listed entries.  Right now, that will get you basic and above.  Ideally you would include if `v1` is one of `(basic|moderate|modern|comprehensive)` ??I'm proposing to add `core` or maybe even `undefined` locales in this list (though no consensus yet)

OK, will filter explicitly for those levels.

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

PR: https://git.openjdk.org/jdk/pull/12812

From duke at openjdk.org  Wed Mar  1 23:23:17 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Wed, 1 Mar 2023 23:23:17 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <QUWNMalmxySM95Y2RB-dRDUVADlDnoLAUa6DZeQf1uY=.630f28a0-7fb5-491a-8636-4a88873f58a5@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <d9whnAsmkSfFtBkeGsbgrCEhUSK4CQsNYx5Hn-_19uk=.44c16c3f-d830-47cf-a17b-1977fa9bf513@github.com>
 <QUWNMalmxySM95Y2RB-dRDUVADlDnoLAUa6DZeQf1uY=.630f28a0-7fb5-491a-8636-4a88873f58a5@github.com>
Message-ID: <WbV1Nt-vbNeWniQQ-eHfRpveP9cCifecXpdwhzW8eR0=.c8ddb9e4-ac2f-4597-845d-3bbe4e6a53cd@github.com>

On Wed, 1 Mar 2023 23:19:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1212:
>> 
>>> 1210:                     a -> Locale.forLanguageTag(a[0].trim().replaceAll("_", "-")),
>>> 1211:                     a -> a[1].trim(),
>>> 1212:                     (v1, v2) -> v2,
>> 
>> this will grab all listed entries.  Right now, that will get you basic and above.  Ideally you would include if `v1` is one of `(basic|moderate|modern|comprehensive)` ??I'm proposing to add `core` or maybe even `undefined` locales in this list (though no consensus yet)
>
> OK, will filter explicitly for those levels.

the whole set is `undetermined|core|basic|moderate|modern|comprehensive` you could use an enum and then you can select just one.

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

PR: https://git.openjdk.org/jdk/pull/12812

From jlu at openjdk.org  Wed Mar  1 23:45:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Mar 2023 23:45:47 GMT
Subject: <i18n dev> RFR: 8303472: Display name for region TR [v2]
In-Reply-To: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
References: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
Message-ID: <y_-RlVlwutucne0wIcDhi0KCYBF4eW75t6lHr_jzX8o=.f58eed5a-9ad2-45c8-b25e-b67e6075e3aa@github.com>

> This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name).
> 
> 
> 
> This change targets both the CLDR and COMPAT data.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Supply test with changes, use unicode escapes to be consistent
 - copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12816/files
  - new: https://git.openjdk.org/jdk/pull/12816/files/c996ca27..5bedc6a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12816&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12816&range=00-01

  Stats: 9 lines in 4 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12816.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12816/head:pull/12816

PR: https://git.openjdk.org/jdk/pull/12816

From jlu at openjdk.org  Wed Mar  1 23:45:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Mar 2023 23:45:49 GMT
Subject: <i18n dev> RFR: 8303472: Display name for region TR [v2]
In-Reply-To: <n_KehQqzmBIzae88d1SDl8hAIIyNv0syBk5yuiC04o8=.a99374aa-104b-4cd7-a6cc-44d577037c6a@github.com>
References: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
 <n_KehQqzmBIzae88d1SDl8hAIIyNv0syBk5yuiC04o8=.a99374aa-104b-4cd7-a6cc-44d577037c6a@github.com>
Message-ID: <8qco8EfF_4-QLAxJa-u95-6VA0pdna680KVGBkVxCxk=.66dbfadc-294b-4b0c-819b-64be6f831d18@github.com>

On Wed, 1 Mar 2023 22:52:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Supply test with changes, use unicode escapes to be consistent
>>  - copyright year
>
> src/java.base/share/classes/sun/util/resources/LocaleNames.properties line 1097:
> 
>> 1095: TN=Tunisia
>> 1096: TO=Tonga
>> 1097: TR=T?rkiye
> 
> I believe this is fine, but please confirm that this ends up correct u-umlaut when you get the text. It is somewhat a rare case where ISO-8859-1 has the character and the byte sequence differs between ISO-8859-1 and UTF-8.

Thanks for pointing that out, I switched it to just be a unicode escaped ?, as that would be more consistent with the rest of the file. I also added the changes to the test files like you suggested.

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

PR: https://git.openjdk.org/jdk/pull/12816

From naoto at openjdk.org  Thu Mar  2 01:03:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Mar 2023 01:03:20 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt` [v2]
In-Reply-To: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
Message-ID: <ZVWwhJrTUDIZnwHc3jjc7I5t6rNnv_umuPZC_sn8HJk=.d2c882a8-7e3c-40fa-a595-de9c4507a93f@github.com>

> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.

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

  Explicitly filter coverage levels

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12812/files
  - new: https://git.openjdk.org/jdk/pull/12812/files/2d0f16f3..8ae9ba61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12812&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12812&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12812

From duke at openjdk.org  Thu Mar  2 01:11:05 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Thu, 2 Mar 2023 01:11:05 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt` [v2]
In-Reply-To: <ZVWwhJrTUDIZnwHc3jjc7I5t6rNnv_umuPZC_sn8HJk=.d2c882a8-7e3c-40fa-a595-de9c4507a93f@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <ZVWwhJrTUDIZnwHc3jjc7I5t6rNnv_umuPZC_sn8HJk=.d2c882a8-7e3c-40fa-a595-de9c4507a93f@github.com>
Message-ID: <og2EuTr4Zk4af-yV7C0H8qyw6gvX9qdFVcv51vgcx_w=.a4de1fe6-8045-4a17-9b39-c13492be6726@github.com>

On Thu, 2 Mar 2023 01:03:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly filter coverage levels

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/12812

From jpai at openjdk.org  Thu Mar  2 01:18:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 2 Mar 2023 01:18:05 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <G5NKyBGxlBvTgzK4Y3NaOsyQmdKokA3oop4zvgyfrd0=.132b98e4-7aa7-4e7f-9486-6b8c8a1ed785@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <G5NKyBGxlBvTgzK4Y3NaOsyQmdKokA3oop4zvgyfrd0=.132b98e4-7aa7-4e7f-9486-6b8c8a1ed785@github.com>
Message-ID: <H-n7hShz7gYSIyJX0N3Y6dL9WvYbOsqqCknEW3H8Vp4=.c5e6f056-023a-4da3-90a8-56858af840f3@github.com>

On Wed, 1 Mar 2023 23:13:55 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

> my openjdk name should be `srl`  ? i'm still there https://openjdk.org/census#srl

Hello Steven, please follow the instructions here to have your github account linked to the OpenJDK id https://wiki.openjdk.org/display/SKARA/Skara#Skara-AssociatingyourGitHubaccountandyourOpenJDKusername.

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

PR: https://git.openjdk.org/jdk/pull/12812

From jlaskey at openjdk.org  Thu Mar  2 11:14:36 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 2 Mar 2023 11:14:36 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v42]
In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
Message-ID: <vTJqNaX9fjbIH3HI8trEPzWajVLisZxpt3VH3yzcu1c=.dc19b7bf-aa94-4bc8-8035-6b47490fa6bc@github.com>

On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighten up reporting of string template errors (fewer messages)

Can I get some signing reviewers of the CSR https://bugs.openjdk.org/browse/JDK-8286021 ?

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

PR: https://git.openjdk.org/jdk/pull/10889

From prappo at openjdk.org  Thu Mar  2 12:13:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Mar 2023 12:13:14 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly invisible
 doc comments
Message-ID: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>

Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.

The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:


    diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
    --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
    +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
    @@ -17084,7 +17084,7 @@
                      throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
     <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
     <div class="block"><code>readObject</code> is called to restore the state of the
    - (@code BasicPermission} from a stream.</div>
    + <code>BasicPermission</code> from a stream.</div>
     <dl class="notes">
     <dt>Parameters:</dt>
     <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>

Notes
-----

* I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
* I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
* I will update copyright years after (and if) the fix had been approved, as required.

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

Commit messages:
 - Initial commit

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

PR: https://git.openjdk.org/jdk/pull/12826

From mullan at openjdk.org  Thu Mar  2 13:24:07 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Mar 2023 13:24:07 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <GCwAXDcnMpAJDHxB9QMEP9UmwTYemW62F7RUdNaEVk8=.8b73051d-d3a8-4fac-ac48-efc3864d33bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

security related changes look fine.

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

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From naoto at openjdk.org  Thu Mar  2 16:17:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Mar 2023 16:17:08 GMT
Subject: <i18n dev> RFR: 8303472: Display name for region TR [v2]
In-Reply-To: <y_-RlVlwutucne0wIcDhi0KCYBF4eW75t6lHr_jzX8o=.f58eed5a-9ad2-45c8-b25e-b67e6075e3aa@github.com>
References: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
 <y_-RlVlwutucne0wIcDhi0KCYBF4eW75t6lHr_jzX8o=.f58eed5a-9ad2-45c8-b25e-b67e6075e3aa@github.com>
Message-ID: <pWbtGWD09LaN2mRrcf0CtY6mpaKUsI5kkQAi5x8VPiI=.fb0124dd-4451-4906-9721-f9f3df12f0f9@github.com>

On Wed, 1 Mar 2023 23:45:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name).
>> 
>> 
>> 
>> This change targets both the CLDR and COMPAT data.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Supply test with changes, use unicode escapes to be consistent
>  - copyright year

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12816

From iris at openjdk.org  Thu Mar  2 16:42:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 2 Mar 2023 16:42:18 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt` [v2]
In-Reply-To: <ZVWwhJrTUDIZnwHc3jjc7I5t6rNnv_umuPZC_sn8HJk=.d2c882a8-7e3c-40fa-a595-de9c4507a93f@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <ZVWwhJrTUDIZnwHc3jjc7I5t6rNnv_umuPZC_sn8HJk=.d2c882a8-7e3c-40fa-a595-de9c4507a93f@github.com>
Message-ID: <uSqxlFl3F94P97GnkRAjZGJADfe_7Kc6sNZQo-VlItU=.49d2708e-ef54-4ccd-9a0e-7dff12304fbf@github.com>

On Thu, 2 Mar 2023 01:03:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly filter coverage levels

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12812

From duke at openjdk.org  Thu Mar  2 16:45:08 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Thu, 2 Mar 2023 16:45:08 GMT
Subject: <i18n dev> RFR: 8303472: Display name for region TR [v2]
In-Reply-To: <y_-RlVlwutucne0wIcDhi0KCYBF4eW75t6lHr_jzX8o=.f58eed5a-9ad2-45c8-b25e-b67e6075e3aa@github.com>
References: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
 <y_-RlVlwutucne0wIcDhi0KCYBF4eW75t6lHr_jzX8o=.f58eed5a-9ad2-45c8-b25e-b67e6075e3aa@github.com>
Message-ID: <yEYrXgahwCycnlVlQZtG4L0iOtfxpiOCeX-O0XuWWiQ=.6f8b3d8b-e9db-455b-aab5-7616e9581721@github.com>

On Wed, 1 Mar 2023 23:45:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name).
>> 
>> 
>> 
>> This change targets both the CLDR and COMPAT data.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Supply test with changes, use unicode escapes to be consistent
>  - copyright year

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/12816

From naoto at openjdk.org  Thu Mar  2 16:47:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Mar 2023 16:47:08 GMT
Subject: <i18n dev> RFR: 8303275: Use {@Return and @linkplain in Locale
 and related classes
In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
Message-ID: <P4SrlvJq79Q76FJbVb9eVy8ChNb-xwmROQcMJ5cF3wM=.1aa232a7-436a-4aba-84cf-abd4299ca0bd@github.com>

On Tue, 28 Feb 2023 00:09:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain.

src/java.base/share/classes/java/util/Locale.java line 2075:

> 2073:      * user. This will be the values returned by getDisplayLanguage(),
> 2074:      * getDisplayScript(), getDisplayCountry(), getDisplayVariant() and
> 2075:      * optional {@linkplain Locale##def_locale_extension Unicode extensions}

Can `Locale` be removed? It seems redundant. There are other locations with the same situation in this class.

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

PR: https://git.openjdk.org/jdk/pull/12780

From joehw at openjdk.org  Thu Mar  2 17:32:16 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 2 Mar 2023 17:32:16 GMT
Subject: <i18n dev> RFR: 8303039: Utilize `coverageLevels.txt` [v2]
In-Reply-To: <ZVWwhJrTUDIZnwHc3jjc7I5t6rNnv_umuPZC_sn8HJk=.d2c882a8-7e3c-40fa-a595-de9c4507a93f@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
 <ZVWwhJrTUDIZnwHc3jjc7I5t6rNnv_umuPZC_sn8HJk=.d2c882a8-7e3c-40fa-a595-de9c4507a93f@github.com>
Message-ID: <YtZnb0ZVf_84jUxxtdzVtKTODi3hsYK9sHRufMVDWsI=.368becc6-d5d7-4395-96e6-09ef2246dc8f@github.com>

On Thu, 2 Mar 2023 01:03:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly filter coverage levels

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12812

From naoto at openjdk.org  Thu Mar  2 18:35:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Mar 2023 18:35:24 GMT
Subject: <i18n dev> Integrated: 8303039: Utilize `coverageLevels.txt`
In-Reply-To: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
References: <ZToJOc97U6MOBNGKaRkiR2ZGX6JVmI2ww2gEJ_e4ZHg=.aa2d7898-c8e9-42e0-b85b-294de2e8ad5d@github.com>
Message-ID: <JQ3J3UKWus502AI_CVfoPDhaXhW5nLyRshChxTlhuUI=.42d680b9-df6b-4faa-9c60-ed55638e9f68@github.com>

On Wed, 1 Mar 2023 19:50:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a pre-requisite for supporting CLDR v43, where they combine `seeds` locales with `common` locales (https://cldr.unicode.org/index/downloads/cldr-43#h.7s25aqdv767e). In order to have the same coverage level of locales, CLDRConverter tool needs to comb through the locale files based on the `coverageLevels.txt` file, (and the ones we already included as of v42). Confirmed the same set of locales is generated before and after this modification.

This pull request has now been integrated.

Changeset: 0b635579
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b6355794101bda9de623016ce88f8abbb314f63
Stats:     319 lines in 4 files changed: 315 ins; 1 del; 3 mod

8303039: Utilize `coverageLevels.txt`

Reviewed-by: iris, joehw

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

PR: https://git.openjdk.org/jdk/pull/12812

From jlu at openjdk.org  Thu Mar  2 19:38:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 2 Mar 2023 19:38:29 GMT
Subject: <i18n dev> RFR: 8303275: Use {@Return and @linkplain in Locale
 and related classes [v2]
In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
Message-ID: <SfFF9-maagnDpYjM9RjoDTo0NPuguKXsCbUHK6pkaCM=.bee03251-70ba-4321-9cd9-ef140d539d68@github.com>

> This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove prefix Locale for in-class linkplains

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12780/files
  - new: https://git.openjdk.org/jdk/pull/12780/files/cfbbfa0a..5850ca02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12780&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12780&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12780.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12780/head:pull/12780

PR: https://git.openjdk.org/jdk/pull/12780

From jlu at openjdk.org  Thu Mar  2 19:38:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 2 Mar 2023 19:38:31 GMT
Subject: <i18n dev> RFR: 8303275: Use {@Return and @linkplain in Locale
 and related classes [v2]
In-Reply-To: <P4SrlvJq79Q76FJbVb9eVy8ChNb-xwmROQcMJ5cF3wM=.1aa232a7-436a-4aba-84cf-abd4299ca0bd@github.com>
References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
 <P4SrlvJq79Q76FJbVb9eVy8ChNb-xwmROQcMJ5cF3wM=.1aa232a7-436a-4aba-84cf-abd4299ca0bd@github.com>
Message-ID: <ji_7byCizpCmtfBQUgNo35jk8W-_FF3tyREZTc2IEI4=.9ea3f1e7-0ace-4220-aff6-c58ff872cd89@github.com>

On Thu, 2 Mar 2023 16:43:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove prefix Locale for in-class linkplains
>
> src/java.base/share/classes/java/util/Locale.java line 2075:
> 
>> 2073:      * user. This will be the values returned by getDisplayLanguage(),
>> 2074:      * getDisplayScript(), getDisplayCountry(), getDisplayVariant() and
>> 2075:      * optional {@linkplain Locale##def_locale_extension Unicode extensions}
> 
> Can `Locale` be removed? It seems redundant. There are other locations with the same situation in this class.

Yes, removed this and the other instances of `@linkplain` that use the _Locale_ prefix. I left the ones in `Locale.Builder` and `Locale.LanguageRange` since they are generated with different html pages and need the _Locale_ link.

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

PR: https://git.openjdk.org/jdk/pull/12780

From naoto at openjdk.org  Thu Mar  2 20:24:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Mar 2023 20:24:06 GMT
Subject: <i18n dev> RFR: 8303275: Use {@Return and @linkplain in Locale
 and related classes [v2]
In-Reply-To: <SfFF9-maagnDpYjM9RjoDTo0NPuguKXsCbUHK6pkaCM=.bee03251-70ba-4321-9cd9-ef140d539d68@github.com>
References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
 <SfFF9-maagnDpYjM9RjoDTo0NPuguKXsCbUHK6pkaCM=.bee03251-70ba-4321-9cd9-ef140d539d68@github.com>
Message-ID: <CT_sb515v5NNNGjyhXwQr65tOBtnz0vqkQaxyr2uCYM=.6724748a-87d9-466e-a2c3-1f96ec987f18@github.com>

On Thu, 2 Mar 2023 19:38:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove prefix Locale for in-class linkplains

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12780

From prr at openjdk.org  Thu Mar  2 21:29:04 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Mar 2023 21:29:04 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <LDJs1K7coRg4R4EWiETtoqjNIaZchHUjyKAg2madLSM=.11763787-9322-4863-8ca9-242447a9c6de@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

java.desktop changes are fine

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From cjplummer at openjdk.org  Thu Mar  2 22:18:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Mar 2023 22:18:08 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <63UHTjtrUOVGBTwRt_M4QJ7aqBnuAGqekNTTTl3GM74=.ddedac04-ff87-40b9-9ea7-6b6d26d9d202@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

The SA changes (jdk.hotspot.agent) look fine.

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From jlu at openjdk.org  Thu Mar  2 23:49:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 2 Mar 2023 23:49:00 GMT
Subject: <i18n dev> RFR: 6453901: (cal) clean up sun.util.calendar classes
Message-ID: <m8hQFxg6ARXeI0XCLMJ1GHUQeukizv6zIqNDtuSSJXU=.425b0254-1f8f-457b-9ebc-3a4ec9233ce9@github.com>

This PR includes cleanup changes to the sun.util.calendar package only.

The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed.


Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403

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

Commit messages:
 - Additional unused method: CalendarDate.addSeconds()
 - Merge branch 'master' into 6453901-CalCleanUp
 - Copyright years
 - Unused methods, imports, variables. Pattern instance, Java array dec

Changes: https://git.openjdk.org/jdk/pull/12817/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12817&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6453901
  Stats: 211 lines in 10 files changed: 1 ins; 182 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/12817.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12817/head:pull/12817

PR: https://git.openjdk.org/jdk/pull/12817

From aivanov at openjdk.org  Fri Mar  3 08:28:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 08:28:19 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Looks good to me.

I looked through all the changes, paying more attention to the client area.

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:

> 255: 
> 256:     /**
> 257:      * @return true iff the BSM method type exactly matches

I assume ?iff? should ?if??

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:

> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged

Is it ??has a {@code throws} clause???

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From prappo at openjdk.org  Fri Mar  3 09:41:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:41:06 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>

On Thu, 2 Mar 2023 16:23:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
> 
>> 255: 
>> 256:     /**
>> 257:      * @return true iff the BSM method type exactly matches
> 
> I assume ?iff? should ?if??

Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)

@cl4es (Claes Redestad), as the author of those lines would you like to chime in?

Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`

While there's a similarly-name method with slightly different parameters, I refrained from using it:
`java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

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

PR: https://git.openjdk.org/jdk/pull/12826

From prappo at openjdk.org  Fri Mar  3 09:44:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:44:13 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <5TgKeBVz0u1hCa1qOiC7Y46DJvUtDIsDa1wv2I4tAX8=.8575f968-0685-450d-8d77-16523cd7531a@github.com>

On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:
> 
>> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
>> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
>> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged
> 
> Is it ??has a {@code throws} clause???

Thanks! I'll add this to a separate PR.

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

PR: https://git.openjdk.org/jdk/pull/12826

From redestad at openjdk.org  Fri Mar  3 10:12:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 3 Mar 2023 10:12:13 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
Message-ID: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>

On Fri, 3 Mar 2023 09:38:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
>> 
>>> 255: 
>>> 256:     /**
>>> 257:      * @return true iff the BSM method type exactly matches
>> 
>> I assume ?iff? should ?if??
>
> Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)
> 
> @cl4es (Claes Redestad), as the author of those lines would you like to chime in?
> 
> Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`
> 
> While there's a similarly-name method with slightly different parameters, I refrained from using it:
> `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".

The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.

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

PR: https://git.openjdk.org/jdk/pull/12826

From aivanov at openjdk.org  Fri Mar  3 11:34:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 11:34:16 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
Message-ID: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>

On Fri, 3 Mar 2023 10:09:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.

I've never come across it before. With your explanations, it makes perfect sense.

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

PR: https://git.openjdk.org/jdk/pull/12826

From jlu at openjdk.org  Fri Mar  3 17:22:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 Mar 2023 17:22:29 GMT
Subject: <i18n dev> Integrated: 8303472: Display name for region TR
In-Reply-To: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
References: <GPEknhMDI2Cxsm9OWSLuuDetaLhmga9mxAV4zGi_dQM=.b5f4fb64-cd12-4da6-82ef-22d813e2abfd@github.com>
Message-ID: <OXdK7dT1riel6YF6a1Ny3257eP4ZpxDm615Vpc0b-E4=.d6a9408f-d48a-4b03-86c9-c0e1bbcfbfae@github.com>

On Wed, 1 Mar 2023 21:58:00 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR changes the English name for the region `TR`, from `Turkey` to `T?rkiye`. Although this change is included in the upcoming CLDR v43, it should be applied as a spot change so that it can be back-ported properly (As it is a common English region name).
> 
> 
> 
> This change targets both the CLDR and COMPAT data.

This pull request has now been integrated.

Changeset: e3016c11
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3016c11425f7f915eaf20b6e02a9ec0c9ec8690
Stats:     11 lines in 5 files changed: 6 ins; 0 del; 5 mod

8303472: Display name for region TR

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/12816

From naoto at openjdk.org  Fri Mar  3 18:01:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 Mar 2023 18:01:11 GMT
Subject: <i18n dev> RFR: 6453901: (cal) clean up sun.util.calendar
 classes
In-Reply-To: <m8hQFxg6ARXeI0XCLMJ1GHUQeukizv6zIqNDtuSSJXU=.425b0254-1f8f-457b-9ebc-3a4ec9233ce9@github.com>
References: <m8hQFxg6ARXeI0XCLMJ1GHUQeukizv6zIqNDtuSSJXU=.425b0254-1f8f-457b-9ebc-3a4ec9233ce9@github.com>
Message-ID: <O7EBEN7yYVJRG2nHCygKmxIJzxH1mEtbdOsCS_EdjGA=.ea813591-ff16-4f1e-82b6-ac026696970f@github.com>

On Wed, 1 Mar 2023 21:58:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR includes cleanup changes to the sun.util.calendar package only.
> 
> The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed.
> 
> 
> Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403

Nice cleanup for removing dead code.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12817

From lancea at openjdk.org  Fri Mar  3 18:07:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 3 Mar 2023 18:07:21 GMT
Subject: <i18n dev> RFR: 6453901: (cal) clean up sun.util.calendar
 classes
In-Reply-To: <m8hQFxg6ARXeI0XCLMJ1GHUQeukizv6zIqNDtuSSJXU=.425b0254-1f8f-457b-9ebc-3a4ec9233ce9@github.com>
References: <m8hQFxg6ARXeI0XCLMJ1GHUQeukizv6zIqNDtuSSJXU=.425b0254-1f8f-457b-9ebc-3a4ec9233ce9@github.com>
Message-ID: <DQuMtp3z41ByBridSnp5j2ipF7DBLXw9llkcACtjfB8=.7dae278a-1b68-4a34-a269-e488517e8127@github.com>

On Wed, 1 Mar 2023 21:58:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR includes cleanup changes to the sun.util.calendar package only.
> 
> The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed.
> 
> 
> Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12817

From rriggs at openjdk.org  Fri Mar  3 20:27:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Mar 2023 20:27:53 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v42]
In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
Message-ID: <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>

On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighten up reporting of string template errors (fewer messages)

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 37:

> 35: 
> 36: /**
> 37:  * Policies using this additional interface have the flexibility to specialize

Since it is 'sealed' it may clarify the use to say "Builtin policies"...

src/java.base/share/classes/java/lang/template/StringProcessor.java line 49:

> 47:  * @implNote Implementations using {@link StringProcessor} are equivalent to implementations using
> 48:  * {@code TemplateProcessor<String>} or {@code ValidatingProcessor<String, RuntimeException>},
> 49:  * however, StringProcessor is cleaner and easier to understand.

Split into two sentences.

Suggestion:

 * {@code TemplateProcessor<String>} or {@code ValidatingProcessor<String, RuntimeException>}.
 * However, StringProcessor is cleaner and easier to understand.

src/java.base/share/classes/java/lang/template/StringProcessor.java line 58:

> 56:     /**
> 57:      * Constructs a {@link String} based on the template fragments and values in the
> 58:      * supplied {@link StringTemplate} object.

Some inconsistency in the use of link/linkplain and the capitalization of stringTemplate, the instance or the type.
(As compared to TemplateProcessor.process(stringTemplate))
Suggestion:

     * supplied {@link StringTemplate} object.

src/java.base/share/classes/java/util/FormatProcessor.java line 42:

> 40:  * {@link Formatter} specifications and values found in the {@link StringTemplate}.
> 41:  * Unlike {@link Formatter}, {@link FormatProcessor} uses the value from the
> 42:  * embedded expression that immediately follows, no whitespace, after the

Suggestion:

 * embedded expression that immediately follows, without whitespace, the

src/java.base/share/classes/java/util/FormatProcessor.java line 66:

> 64:  * <p>
> 65:  * {@link FormatProcessor}  format specification uses and exceptions are the same as
> 66:  * those of {@link Formatter}.

Suggestion:

 * The {@link FormatProcessor} format specification uses and exceptions are the same as
 * those of {@link Formatter}.

src/java.base/share/classes/java/util/FormatProcessor.java line 80:

> 78:  * int x = 10;
> 79:  * int y = 20;
> 80:  * String result = thaiFMT."%d\{x} + %d\{y} = %d\{x + y}";

The inclusion of format specifiers that yield the same results as the default (%s) may mislead developers into thinking they need the format specifier. Making the examples look more complicated than necessary.
Can the examples, show customized output.

Suggestion:

 * String result = thaiFMT."%d{x} + %d{y} = %d{x + y}";

src/java.base/share/classes/java/util/FormatProcessor.java line 134:

> 132:      * format string from the fragments, gathers up the values and
> 133:      * evaluates the expression
> 134:      * {@code new Formatter(locale).format(format, values).toString()}.

Should this be described using the "as if"... phrasing to avoid a literal requirement in the spec that is inflexible?

src/java.base/share/classes/java/util/FormatProcessor.java line 175:

> 173:      * {@link FormatProcessor#FMT} ({@code static final FormatProcessor}).
> 174:      * <p>
> 175:      * Other {@link FormatProcessor} can be specialized if stored as static final.

Suggestion:

     * Other {@link FormatProcessor}s can be specialized if stored as a static final.

src/java.base/share/classes/java/util/FormatProcessor.java line 187:

> 185:      * @throws  IllegalFormatException
> 186:      *          If a format specifier contains an illegal syntax, a format
> 187:      *          specifier that is incompatible with the given arguments,

Suggestion:

     *          specifier is incompatible with the given arguments,

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

PR: https://git.openjdk.org/jdk/pull/10889

From naoto at openjdk.org  Fri Mar  3 20:59:07 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 Mar 2023 20:59:07 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not accept
 the "UTC+XX" zone id
Message-ID: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>

This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.

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

Commit messages:
 - 8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id

Changes: https://git.openjdk.org/jdk/pull/12868/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303440
  Stats: 81 lines in 2 files changed: 79 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12868.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12868/head:pull/12868

PR: https://git.openjdk.org/jdk/pull/12868

From naoto at openjdk.org  Fri Mar  3 21:10:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 Mar 2023 21:10:57 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v2]
In-Reply-To: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
Message-ID: <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>

> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.

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

  now() -> of() to avoid DST

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12868/files
  - new: https://git.openjdk.org/jdk/pull/12868/files/966b8f67..5cda8482

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12868

From iris at openjdk.org  Sat Mar  4 00:27:12 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 4 Mar 2023 00:27:12 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v2]
In-Reply-To: <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
Message-ID: <7MUDfOoFZHqhXDwn_VQ7wTxIIDqeQEwtSliHgzGDtX8=.c487aca5-6858-4fdf-99cc-c76421feb2d0@github.com>

On Fri, 3 Mar 2023 21:10:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   now() -> of() to avoid DST

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12868

From jpai at openjdk.org  Sat Mar  4 01:40:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 4 Mar 2023 01:40:06 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v2]
In-Reply-To: <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
Message-ID: <zYpgL8W6R07crRrJIfzq410zIxYST1BVACa5x0Z2qyc=.0eaa9152-e5a3-4454-aa7e-450b819f5bd4@github.com>

On Fri, 3 Mar 2023 21:10:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   now() -> of() to avoid DST

test/jdk/java/time/test/java/time/format/TestUTCParse.java line 27:

> 25:  * @modules jdk.localedata
> 26:  * @bug 8303440
> 27:  * @summary Test parsing "UTC-XX:XX" text works correctly

Hello Naoto, I haven't tried it, but without a `@run testng` instruction, does jtreg have the ability to auto infer this as a testng testcase?

test/jdk/java/time/test/java/time/format/TestUTCParse.java line 48:

> 46:         // Assuming CLDR's SHORT name for "America/Los_Angeles"
> 47:         // produces "UTC\u212208:00"
> 48:         System.setProperty("java.locale.providers", "CLDR");

Since this updates a system property (that's recognized by code even outside of this test), perhaps we should use `@run testng/othervm` to prevent interfering with other tests?

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

PR: https://git.openjdk.org/jdk/pull/12868

From jpai at openjdk.org  Sat Mar  4 01:44:14 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 4 Mar 2023 01:44:14 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v2]
In-Reply-To: <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
Message-ID: <_c06I5fjMUnVswxoFmSD-Myn6XWgZQzJZtCNo3uDtaE=.b613cc1f-2728-4334-9d56-20a711aed12a@github.com>

On Fri, 3 Mar 2023 21:10:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   now() -> of() to avoid DST

test/jdk/java/time/test/java/time/format/TestUTCParse.java line 63:

> 61:     public void testUTCShortNameRoundTrip() {
> 62:         var fmt = DateTimeFormatter.ofPattern("z", Locale.FRANCE);
> 63:         var now = ZonedDateTime.of(2023, 3, 3, 0, 0, 0, 0, ZoneId.of("America/Los_Angeles"));

Nit, this is no longer `now`. Should it renamed to avoid confusion?

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

PR: https://git.openjdk.org/jdk/pull/12868

From naoto at openjdk.org  Sat Mar  4 02:22:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 4 Mar 2023 02:22:39 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v3]
In-Reply-To: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
Message-ID: <Dnn_rZE7F5BXQrRmVzFrT5bU-L756d7sGJtEo_W7fQU=.2667d1d5-b6b8-4cb7-b730-1f78c578cf73@github.com>

> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.

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

  now -> zdt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12868/files
  - new: https://git.openjdk.org/jdk/pull/12868/files/5cda8482..e61d4fc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12868&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12868.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12868/head:pull/12868

PR: https://git.openjdk.org/jdk/pull/12868

From naoto at openjdk.org  Sat Mar  4 02:22:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 4 Mar 2023 02:22:39 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v2]
In-Reply-To: <zYpgL8W6R07crRrJIfzq410zIxYST1BVACa5x0Z2qyc=.0eaa9152-e5a3-4454-aa7e-450b819f5bd4@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
 <zYpgL8W6R07crRrJIfzq410zIxYST1BVACa5x0Z2qyc=.0eaa9152-e5a3-4454-aa7e-450b819f5bd4@github.com>
Message-ID: <_6lBAijzJqHagDhACqUPbhIjcrRDt6TCFDKSQYLYtbM=.70a6ec61-44e4-4753-a908-5243f9a44d79@github.com>

On Sat, 4 Mar 2023 01:36:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   now() -> of() to avoid DST
>
> test/jdk/java/time/test/java/time/format/TestUTCParse.java line 27:
> 
>> 25:  * @modules jdk.localedata
>> 26:  * @bug 8303440
>> 27:  * @summary Test parsing "UTC-XX:XX" text works correctly
> 
> Hello Naoto, I haven't tried it, but without a `@run testng` instruction, does jtreg have the ability to auto infer this as a testng testcase?

Thanks for the review, Jai!
The default test behavior under `java/time` directory is defined in `java/time/test/TEST.properties` file, where it directs they are run using `TestNG`.

> test/jdk/java/time/test/java/time/format/TestUTCParse.java line 48:
> 
>> 46:         // Assuming CLDR's SHORT name for "America/Los_Angeles"
>> 47:         // produces "UTC\u212208:00"
>> 48:         System.setProperty("java.locale.providers", "CLDR");
> 
> Since this updates a system property (that's recognized by code even outside of this test), perhaps we should use `@run testng/othervm` to prevent interfering with other tests?

And the `TEST.properties` directs tests to be run under `othervm` mode.

> test/jdk/java/time/test/java/time/format/TestUTCParse.java line 63:
> 
>> 61:     public void testUTCShortNameRoundTrip() {
>> 62:         var fmt = DateTimeFormatter.ofPattern("z", Locale.FRANCE);
>> 63:         var now = ZonedDateTime.of(2023, 3, 3, 0, 0, 0, 0, ZoneId.of("America/Los_Angeles"));
> 
> Nit, this is no longer `now`. Should it renamed to avoid confusion?

Good catch. Modified.

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

PR: https://git.openjdk.org/jdk/pull/12868

From jpai at openjdk.org  Sat Mar  4 05:00:13 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 4 Mar 2023 05:00:13 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v2]
In-Reply-To: <_6lBAijzJqHagDhACqUPbhIjcrRDt6TCFDKSQYLYtbM=.70a6ec61-44e4-4753-a908-5243f9a44d79@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <LhqWLx5DQ10ZHQdK75EgrT5cTpLONG2nKMYFJG_OVvA=.1c8aedc9-9880-42f2-8bba-3e37a9e1c540@github.com>
 <zYpgL8W6R07crRrJIfzq410zIxYST1BVACa5x0Z2qyc=.0eaa9152-e5a3-4454-aa7e-450b819f5bd4@github.com>
 <_6lBAijzJqHagDhACqUPbhIjcrRDt6TCFDKSQYLYtbM=.70a6ec61-44e4-4753-a908-5243f9a44d79@github.com>
Message-ID: <ox2_Q8YhJ5_YVxSpB_5U1DFp_OFhzt39JKLYeilqpkA=.df72844c-b9dc-495c-adc6-cbd4dad395e1@github.com>

On Sat, 4 Mar 2023 02:18:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/time/test/java/time/format/TestUTCParse.java line 48:
>> 
>>> 46:         // Assuming CLDR's SHORT name for "America/Los_Angeles"
>>> 47:         // produces "UTC\u212208:00"
>>> 48:         System.setProperty("java.locale.providers", "CLDR");
>> 
>> Since this updates a system property (that's recognized by code even outside of this test), perhaps we should use `@run testng/othervm` to prevent interfering with other tests?
>
> And the `TEST.properties` directs tests to be run under `othervm` mode.

Thank you Naoto for that detail, I wasn't aware of it.

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

PR: https://git.openjdk.org/jdk/pull/12868

From jpai at openjdk.org  Sat Mar  4 05:00:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 4 Mar 2023 05:00:11 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v3]
In-Reply-To: <Dnn_rZE7F5BXQrRmVzFrT5bU-L756d7sGJtEo_W7fQU=.2667d1d5-b6b8-4cb7-b730-1f78c578cf73@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <Dnn_rZE7F5BXQrRmVzFrT5bU-L756d7sGJtEo_W7fQU=.2667d1d5-b6b8-4cb7-b730-1f78c578cf73@github.com>
Message-ID: <mpafiSHcKE9qlab16wHKmS7uAfcubGHn3e1YHy-Rcx8=.43b546cf-35ab-4706-860e-3ba77ca7b49c@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Sat, 4 Mar 2023 02:22:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   now -> zdt

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12868

From duke at openjdk.org  Sun Mar  5 23:21:57 2023
From: duke at openjdk.org (Marius Volkhart)
Date: Sun, 5 Mar 2023 23:21:57 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v42]
In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
Message-ID: <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com>

On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighten up reporting of string template errors (fewer messages)

src/java.base/share/classes/java/lang/template/Carriers.java line 396:

> 394: 
> 395:     /**
> 396:      * Wrapper object for carrier data. Instances types are stored in the {@code objects}

Suggestion:

     * Wrapper object for carrier data. Instance types are stored in the {@code objects}

src/java.base/share/classes/java/lang/template/StringTemplate.java line 76:

> 74:  * produced that returns the same lists from {@link StringTemplate#fragments()} and
> 75:  * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template
> 76:  * processor uses these lists to yield an interpolated string. the value of {@code s} will

Suggestion:

 * processor uses these lists to yield an interpolated string. The value of {@code s} will

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Mar  6 14:11:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 14:11:55 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v42]
In-Reply-To: <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
Message-ID: <rZpmZXi7OSqOON9_-Z33gBv_M3nRoFL-dHqdWwPI6-o=.0350abc4-144f-49aa-bab8-b954e2bc2ec1@github.com>

On Fri, 3 Mar 2023 19:42:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten up reporting of string template errors (fewer messages)
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 66:
> 
>> 64:  * <p>
>> 65:  * {@link FormatProcessor}  format specification uses and exceptions are the same as
>> 66:  * those of {@link Formatter}.
> 
> Suggestion:
> 
>  * The {@link FormatProcessor} format specification uses and exceptions are the same as
>  * those of {@link Formatter}.

Changing.

> src/java.base/share/classes/java/util/FormatProcessor.java line 134:
> 
>> 132:      * format string from the fragments, gathers up the values and
>> 133:      * evaluates the expression
>> 134:      * {@code new Formatter(locale).format(format, values).toString()}.
> 
> Should this be described using the "as if"... phrasing to avoid a literal requirement in the spec that is inflexible?

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 175:
> 
>> 173:      * {@link FormatProcessor#FMT} ({@code static final FormatProcessor}).
>> 174:      * <p>
>> 175:      * Other {@link FormatProcessor} can be specialized if stored as static final.
> 
> Suggestion:
> 
>      * Other {@link FormatProcessor}s can be specialized if stored as a static final.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 187:
> 
>> 185:      * @throws  IllegalFormatException
>> 186:      *          If a format specifier contains an illegal syntax, a format
>> 187:      *          specifier that is incompatible with the given arguments,
> 
> Suggestion:
> 
>      *          specifier is incompatible with the given arguments,

Existing statement is consistent with those in Formatter. Reads more correctly as is.

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Mar  6 14:24:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 14:24:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v42]
In-Reply-To: <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com>
Message-ID: <zVyfERYFLGsagsRz660qFFH0FzpZkVBUA1dhlVULPkM=.374fe8fc-56a1-4cc9-9419-599e23a0796f@github.com>

On Sat, 4 Mar 2023 19:34:36 GMT, Marius Volkhart <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten up reporting of string template errors (fewer messages)
>
> src/java.base/share/classes/java/lang/template/Carriers.java line 396:
> 
>> 394: 
>> 395:     /**
>> 396:      * Wrapper object for carrier data. Instances types are stored in the {@code objects}
> 
> Suggestion:
> 
>      * Wrapper object for carrier data. Instance types are stored in the {@code objects}

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 76:
> 
>> 74:  * produced that returns the same lists from {@link StringTemplate#fragments()} and
>> 75:  * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template
>> 76:  * processor uses these lists to yield an interpolated string. the value of {@code s} will
> 
> Suggestion:
> 
>  * processor uses these lists to yield an interpolated string. The value of {@code s} will

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Mar  6 14:24:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 14:24:18 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v42]
In-Reply-To: <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
Message-ID: <1o1R5JiEv0hfQDksNEHsYwPv0BmLwKlK81xeqx_0arI=.5663b84d-5273-44ee-9ab4-f28400b1441a@github.com>

On Fri, 3 Mar 2023 20:17:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten up reporting of string template errors (fewer messages)
>
> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 37:
> 
>> 35: 
>> 36: /**
>> 37:  * Policies using this additional interface have the flexibility to specialize
> 
> Since it is 'sealed' it may clarify the use to say "Builtin policies"...

Changing

> src/java.base/share/classes/java/lang/template/StringProcessor.java line 58:
> 
>> 56:     /**
>> 57:      * Constructs a {@link String} based on the template fragments and values in the
>> 58:      * supplied {@link StringTemplate} object.
> 
> Some inconsistency in the use of link/linkplain and the capitalization of stringTemplate, the instance or the type.
> (As compared to TemplateProcessor.process(stringTemplate))
> Suggestion:
> 
>      * supplied {@link StringTemplate} object.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 42:
> 
>> 40:  * {@link Formatter} specifications and values found in the {@link StringTemplate}.
>> 41:  * Unlike {@link Formatter}, {@link FormatProcessor} uses the value from the
>> 42:  * embedded expression that immediately follows, no whitespace, after the
> 
> Suggestion:
> 
>  * embedded expression that immediately follows, without whitespace, the

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 80:
> 
>> 78:  * int x = 10;
>> 79:  * int y = 20;
>> 80:  * String result = thaiFMT."%d\{x} + %d\{y} = %d\{x + y}";
> 
> The inclusion of format specifiers that yield the same results as the default (%s) may mislead developers into thinking they need the format specifier. Making the examples look more complicated than necessary.
> Can the examples, show customized output.
> 
> Suggestion:
> 
>  * String result = thaiFMT."%d{x} + %d{y} = %d{x + y}";

Changing

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

PR: https://git.openjdk.org/jdk/pull/10889

From rriggs at openjdk.org  Mon Mar  6 15:55:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Mar 2023 15:55:32 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v3]
In-Reply-To: <Dnn_rZE7F5BXQrRmVzFrT5bU-L756d7sGJtEo_W7fQU=.2667d1d5-b6b8-4cb7-b730-1f78c578cf73@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <Dnn_rZE7F5BXQrRmVzFrT5bU-L756d7sGJtEo_W7fQU=.2667d1d5-b6b8-4cb7-b730-1f78c578cf73@github.com>
Message-ID: <-vsDsyWuF_MWHZtADr1CjMRtd4nLxiSHdPrsPBMu9-Q=.460fc7ad-d44d-4a9b-bb32-b55f2340bb11@github.com>

On Sat, 4 Mar 2023 02:22:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   now -> zdt

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12868

From lancea at openjdk.org  Mon Mar  6 16:25:19 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 6 Mar 2023 16:25:19 GMT
Subject: <i18n dev> RFR: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id [v3]
In-Reply-To: <Dnn_rZE7F5BXQrRmVzFrT5bU-L756d7sGJtEo_W7fQU=.2667d1d5-b6b8-4cb7-b730-1f78c578cf73@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
 <Dnn_rZE7F5BXQrRmVzFrT5bU-L756d7sGJtEo_W7fQU=.2667d1d5-b6b8-4cb7-b730-1f78c578cf73@github.com>
Message-ID: <WpJsHNE9Ab6xY_XTaBlnt8bbZmtTs0Q68hjKxP79un4=.b9afd4b7-30a9-4af7-99e9-93ff34f7afb5@github.com>

On Sat, 4 Mar 2023 02:22:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   now -> zdt

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12868

From naoto at openjdk.org  Mon Mar  6 17:26:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 Mar 2023 17:26:43 GMT
Subject: <i18n dev> Integrated: 8303440: The "ZonedDateTime.parse" may not
 accept the "UTC+XX" zone id
In-Reply-To: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
References: <HxwXGhnPG3eGpwU7hMTqJPYVmOBMwh_ensQs_sDrzGE=.3bacfa93-6ab7-4f28-9f8d-e3e518a43ff3@github.com>
Message-ID: <9rQzO54BU5-16VvHggj93ua9_AuZHUOon0UGC03sr44=.e55c19c3-94cf-4265-aab9-9248244bb76a@github.com>

On Fri, 3 Mar 2023 20:51:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This change is to fix a regression caused by the fix to [JDK-8234347](https://bugs.openjdk.org/browse/JDK-8234347). The previous fix was simply disabling offset-based parsing if the parser was text-based. Instead, check if it is an offset or not by explicitly comparing the character with '+'/'-' and continue offset parsing if it is.

This pull request has now been integrated.

Changeset: cfb0a25a
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cfb0a25a4ee1a9cebd88c84fa622c46fe1c89bae
Stats:     81 lines in 2 files changed: 79 ins; 0 del; 2 mod

8303440: The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id

Reviewed-by: iris, jpai, rriggs, lancea

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

PR: https://git.openjdk.org/jdk/pull/12868

From jlaskey at openjdk.org  Mon Mar  6 19:16:31 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 19:16:31 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v43]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_G-pacG_MK2x2hRQogujTpfZ7w5xT1Ep0ekHgs1w1-s=.fc5cf7fa-fa65-4256-aaa6-7ac036fb47ec@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge branch 'master' into 8285932
 - Javadoc corrections and bug fix for StringTemplate::combine
 - Tighten up reporting of string template errors (fewer messages)
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - ... and 49 more: https://git.openjdk.org/jdk/compare/cfb0a25a...5d79f650

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=42
  Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From prappo at openjdk.org  Mon Mar  6 20:22:48 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Mar 2023 20:22:48 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments [v2]
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8303480
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12826/files
  - new: https://git.openjdk.org/jdk/pull/12826/files/d2f4a553..87166408

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=00-01

  Stats: 13433 lines in 415 files changed: 9003 ins; 2610 del; 1820 mod
  Patch: https://git.openjdk.org/jdk/pull/12826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826

PR: https://git.openjdk.org/jdk/pull/12826

From jjg at openjdk.org  Mon Mar  6 20:31:18 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:31:18 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments [v2]
In-Reply-To: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
 <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
Message-ID: <ZXfrODW3U49MwVjsf7erqcN1x3lsi5dyU5SSaETKruY=.616faeb3-663f-4191-8bec-8fc0c9eba48d@github.com>

On Fri, 3 Mar 2023 11:31:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".
>> 
>> The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.
>
>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.
> 
> I've never come across it before. With your explanations, it makes perfect sense.

I would recommend (separately) changing `iff` to the expanded form `if and only if`

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

PR: https://git.openjdk.org/jdk/pull/12826

From jjg at openjdk.org  Mon Mar  6 20:36:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:36:13 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <ztCzFqlAYLpzLdZY0K_GgKPNNOvqF9FNTbDh5ZEg-lk=.3aa6a92b-a286-4760-bdc4-425f48e53a6f@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12826

From lancea at openjdk.org  Mon Mar  6 20:39:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 6 Mar 2023 20:39:17 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <RWgaYiwcqLzeKKbnHxAAnPlwk1ndum8VkwVOnvJAbMM=.e0a4507f-dd64-41c8-89c6-70ceb8d34995@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12826

From rriggs at openjdk.org  Mon Mar  6 21:29:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Mar 2023 21:29:08 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <xJn3JEoOJduXQZ9MF4uueB3KdIC4T_3roLNAWSQ8mZM=.4d80d353-a5e3-4cc4-87b3-320643f8cc36@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12826

From itakiguchi at openjdk.org  Tue Mar  7 09:51:29 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 7 Mar 2023 09:51:29 GMT
Subject: <i18n dev> Withdrawn: 8299811: SHIFT_JIS compatible charsets should
 be in java.base module on Linux platform
In-Reply-To: <F3MT8z0x-PopuExzmVxnNSXeJMijOHPN1DVVPlUnTps=.7fde4810-4ee9-4c5b-91fb-50c27ce37ea4@github.com>
References: <F3MT8z0x-PopuExzmVxnNSXeJMijOHPN1DVVPlUnTps=.7fde4810-4ee9-4c5b-91fb-50c27ce37ea4@github.com>
Message-ID: <epS_NmeqNgKxZWbn97iWGFrBfuBcvCya3O1lQaE6f2w=.ef790d74-cd93-49b0-a81a-56772d3a72a3@github.com>

On Mon, 9 Jan 2023 17:28:20 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On Japanese environment, following SHIFT_JIS compatible charsets are there:
> * PCK (x-PCK)
> * MS932 (windows-31j)
> * IBM943C (x-IBM943C)
> 
> According to make/data/charsetmapping/charsets,
> PCK and MS932 are independent charset and have no dependencies on others.
> 
> On RHEL8, SHIFT_JIS encoding is supported
> 
> $ env LANG=ja_JP.sjis locale charmap
> SHIFT_JIS
> 
> According to make/data/charsetmapping/stdcs-linux,
> SJIS (SHIFT_JIS) is in there, also MS932 and PCK are there.
> This means these are in java.base module on Linux platform.
> But IBM943C is not in stdcs-linux.
> I think IBM943C also should be in java.base module because of compatibility.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/11908

From itakiguchi at openjdk.org  Tue Mar  7 09:51:28 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 7 Mar 2023 09:51:28 GMT
Subject: <i18n dev> RFR: 8299811: SHIFT_JIS compatible charsets should
 be in java.base module on Linux platform
In-Reply-To: <F3MT8z0x-PopuExzmVxnNSXeJMijOHPN1DVVPlUnTps=.7fde4810-4ee9-4c5b-91fb-50c27ce37ea4@github.com>
References: <F3MT8z0x-PopuExzmVxnNSXeJMijOHPN1DVVPlUnTps=.7fde4810-4ee9-4c5b-91fb-50c27ce37ea4@github.com>
Message-ID: <wAI2IAMZUlHZA-0npm7bhBfF5Mmvil-4AnhQTcllLiw=.1012179f-5bad-4c38-9a59-9c164e492bf1@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 9 Jan 2023 17:28:20 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On Japanese environment, following SHIFT_JIS compatible charsets are there:
> * PCK (x-PCK)
> * MS932 (windows-31j)
> * IBM943C (x-IBM943C)
> 
> According to make/data/charsetmapping/charsets,
> PCK and MS932 are independent charset and have no dependencies on others.
> 
> On RHEL8, SHIFT_JIS encoding is supported
> 
> $ env LANG=ja_JP.sjis locale charmap
> SHIFT_JIS
> 
> According to make/data/charsetmapping/stdcs-linux,
> SJIS (SHIFT_JIS) is in there, also MS932 and PCK are there.
> This means these are in java.base module on Linux platform.
> But IBM943C is not in stdcs-linux.
> I think IBM943C also should be in java.base module because of compatibility.

I'd like to close this PR.
Thanks.

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

PR: https://git.openjdk.org/jdk/pull/11908

From ihse at openjdk.org  Tue Mar  7 11:19:08 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Mar 2023 11:19:08 GMT
Subject: <i18n dev> RFR: 8303480: Miscellaneous fixes to mostly
 invisible doc comments [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <jtMAFBGGsxnmsPk8rzwnle3YNCoW9AMBfy69IAW5jT0=.2980eb41-64af-4b4b-8826-86f5a6ea6477@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by ihse (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12826

From prappo at openjdk.org  Tue Mar  7 15:35:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 15:35:51 GMT
Subject: <i18n dev> Integrated: 8303480: Miscellaneous fixes to mostly
 invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <bX8VasBimwapkC8a4jdbxSSzCrgVWVZmukOp-odUBTs=.afe4dd0d-9ed0-4cd8-8b8d-92285c7d58bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

This pull request has now been integrated.

Changeset: 45a616a8
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a616a891e4a4b0e77b1f2fa040522f4a99d172
Stats:     75 lines in 39 files changed: 0 ins; 0 del; 75 mod

8303480: Miscellaneous fixes to mostly invisible doc comments

Reviewed-by: mullan, prr, cjplummer, aivanov, jjg, lancea, rriggs, ihse

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

PR: https://git.openjdk.org/jdk/pull/12826

From jlu at openjdk.org  Tue Mar  7 18:22:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 7 Mar 2023 18:22:30 GMT
Subject: <i18n dev> Integrated: 8303275: Use {@Return and @linkplain in
 Locale and related classes
In-Reply-To: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
References: <9XzLdPaTCaYpzrJStx2riu1ZTMIYEgZOkPIy_CgK5jk=.0ec33845-108e-4651-9e6e-6be6c7cc3ef4@github.com>
Message-ID: <acYJ9ptQYaiELRgXOBrqr2igzqSffxQyHYMlAi0NUJ4=.f8abc7c6-22a8-43aa-91c3-093aebd7b2a1@github.com>

On Tue, 28 Feb 2023 00:09:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and LocaleServiceProviderPool to use {@return and @linkplain.

This pull request has now been integrated.

Changeset: acf89961
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acf899612f9b6c4fdd919c40a92ce9c40b3744ed
Stats:     107 lines in 3 files changed: 11 ins; 19 del; 77 mod

8303275: Use {@Return and @linkplain in Locale and related classes

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/12780

From jlu at openjdk.org  Tue Mar  7 18:34:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 7 Mar 2023 18:34:21 GMT
Subject: <i18n dev> Integrated: 6453901: (cal) clean up sun.util.calendar
 classes
In-Reply-To: <m8hQFxg6ARXeI0XCLMJ1GHUQeukizv6zIqNDtuSSJXU=.425b0254-1f8f-457b-9ebc-3a4ec9233ce9@github.com>
References: <m8hQFxg6ARXeI0XCLMJ1GHUQeukizv6zIqNDtuSSJXU=.425b0254-1f8f-457b-9ebc-3a4ec9233ce9@github.com>
Message-ID: <sfVR6d_s61C9uakNJmY9KBsC_5AwCSoyOW85bwNaJBo=.f1e7d9c1-ef2c-4d31-ad5d-f201cdbab6c1@github.com>

On Wed, 1 Mar 2023 21:58:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR includes cleanup changes to the sun.util.calendar package only.
> 
> The changes include removing unused methods, imports, adjusting incorrect links, and using newer syntax patterns. Since there are no plans to promote any of these classes to java.calendar, these unused methods can be removed.
> 
> 
> Mach5: https://mach5.us.oracle.com/mdash/jobs/jclu-jdk2-20230228-2223-42671403

This pull request has now been integrated.

Changeset: f1f4e1de
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1f4e1de445cbec44f871791e93d4dd566c232f1
Stats:     211 lines in 10 files changed: 1 ins; 182 del; 28 mod

6453901: (cal) clean up sun.util.calendar classes

Reviewed-by: naoto, lancea

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

PR: https://git.openjdk.org/jdk/pull/12817

From jlu at openjdk.org  Tue Mar  7 23:05:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 7 Mar 2023 23:05:13 GMT
Subject: <i18n dev> RFR: 8171156: Class java.util.LocaleISOData has outdated
 information for country Code NP
Message-ID: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com>

The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for Nepal. 

According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the [UN](https://www.un.int/protocol/sites/www.un.int/files/Protocol%20and%20Liaison%20Service/officialnamesofcountries.pdf), Nepal's formal name should be  `Federal Democratic Republic of Nepal`, not `Kingdom of Nepal`. It is only a comment, however there is no reason it should not be corrected.

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

Commit messages:
 - Update Nepal formal name in ISO 3166 table

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

PR: https://git.openjdk.org/jdk/pull/12912

From naoto at openjdk.org  Tue Mar  7 23:48:07 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 Mar 2023 23:48:07 GMT
Subject: <i18n dev> RFR: 8171156: Class java.util.LocaleISOData has
 outdated information for country Code NP
In-Reply-To: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com>
References: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com>
Message-ID: <I0vIVzQs2SXkTAGZgyk4fLthpYjCPt5K1o6ZqZHloKY=.94d46d80-7469-4194-803a-10f2733ae4b5@github.com>

On Tue, 7 Mar 2023 22:55:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for Nepal. 
> 
> According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the [UN](https://www.un.int/protocol/sites/www.un.int/files/Protocol%20and%20Liaison%20Service/officialnamesofcountries.pdf), Nepal's formal name should be  `Federal Democratic Republic of Nepal`, not `Kingdom of Nepal`. It is only a comment, however there is no reason it should not be corrected.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12912

From duke at openjdk.org  Wed Mar  8 20:16:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Mar 2023 20:16:00 GMT
Subject: <i18n dev> =?utf-8?q?RFR=3A_8303833=3A_java=2Eutil=2ELocaleISODa?=
 =?utf-8?q?ta_has_wrong_comments_for_=27Norwegian_Bokm=C3=A5l=27_and_=27Vo?=
 =?utf-8?b?bGFww7xrJw==?=
Message-ID: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>

Please review this comment-only PR which fixes incorrect language names  'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData:

`+ "nb" + "nob"  // Norwegian Bokm?l`
`+ "vo" + "vol"  // Volap?k`

These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now.

For context: 'Norwegian bokm?l'  is the most common written form of the Norwegian language:

https://en.wikipedia.org/wiki/Bokm%C3%A5l

'Volap?k' is a constructed language: 

https://en.wikipedia.org/wiki/Volap%C3%BCk

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

Commit messages:
 - Fix comment for "Norwegian Bokm?l" and "Volap?k"

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

PR: https://git.openjdk.org/jdk/pull/12932

From naoto at openjdk.org  Wed Mar  8 20:42:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Mar 2023 20:42:02 GMT
Subject: <i18n dev> 
 =?utf-8?q?RFR=3A_8303833=3A_java=2Eutil=2ELocaleISODa?=
 =?utf-8?q?ta_has_wrong_comments_for_=27Norwegian_Bokm=C3=A5l=27_and_=27Vo?=
 =?utf-8?b?bGFww7xrJw==?=
In-Reply-To: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
References: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
Message-ID: <V7BkEXSKRPJSkDbOUIF64mTO1_NmbF_AeveNJNhOawE=.072903d1-d7d1-4974-a611-88c460c7e7a6@github.com>

On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this comment-only PR which fixes incorrect language names  'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData:
> 
> `+ "nb" + "nob"  // Norwegian Bokm?l`
> `+ "vo" + "vol"  // Volap?k`
> 
> These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now.
> 
> For context: 'Norwegian bokm?l'  is the most common written form of the Norwegian language:
> 
> https://en.wikipedia.org/wiki/Bokm%C3%A5l
> 
> 'Volap?k' is a constructed language: 
> 
> https://en.wikipedia.org/wiki/Volap%C3%BCk

Looks good. The copyright year remains the same but it will be corrected with the other LocaleISOData fix, so it is OK.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12932

From duke at openjdk.org  Wed Mar  8 21:16:06 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Wed, 8 Mar 2023 21:16:06 GMT
Subject: <i18n dev> 
 =?utf-8?q?RFR=3A_8303833=3A_java=2Eutil=2ELocaleISODa?=
 =?utf-8?q?ta_has_wrong_comments_for_=27Norwegian_Bokm=C3=A5l=27_and_=27Vo?=
 =?utf-8?b?bGFww7xrJw==?=
In-Reply-To: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
References: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
Message-ID: <OdRK6TuJ-YTn0rJqhjHpCG87oXFycV6QqmRnraNyet4=.75aa9330-8dde-4de9-ae91-66489700c693@github.com>

On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this comment-only PR which fixes incorrect language names  'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData:
> 
> `+ "nb" + "nob"  // Norwegian Bokm?l`
> `+ "vo" + "vol"  // Volap?k`
> 
> These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now.
> 
> For context: 'Norwegian bokm?l'  is the most common written form of the Norwegian language:
> 
> https://en.wikipedia.org/wiki/Bokm%C3%A5l
> 
> 'Volap?k' is a constructed language: 
> 
> https://en.wikipedia.org/wiki/Volap%C3%BCk

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/12932

From duke at openjdk.org  Wed Mar  8 21:20:13 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Mar 2023 21:20:13 GMT
Subject: <i18n dev> 
 =?utf-8?q?RFR=3A_8303833=3A_java=2Eutil=2ELocaleISODa?=
 =?utf-8?q?ta_has_wrong_comments_for_=27Norwegian_Bokm=C3=A5l=27_and_=27Vo?=
 =?utf-8?b?bGFww7xrJw==?=
In-Reply-To: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
References: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
Message-ID: <WOrlDro0ebvedWcveSC2EaegSfQ5nkm0zt1RK-a8I8c=.4f6e7722-2486-48bc-8272-83557dde7861@github.com>

On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this comment-only PR which fixes incorrect language names  'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData:
> 
> `+ "nb" + "nob"  // Norwegian Bokm?l`
> `+ "vo" + "vol"  // Volap?k`
> 
> These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now.
> 
> For context: 'Norwegian bokm?l'  is the most common written form of the Norwegian language:
> 
> https://en.wikipedia.org/wiki/Bokm%C3%A5l
> 
> 'Volap?k' is a constructed language: 
> 
> https://en.wikipedia.org/wiki/Volap%C3%BCk

Thanks Naoto and Steven!  I could claim that the change was too trivial for a copyright update, but I'd rather be honest and say I just forgot. Also, I'm not a lawyer :-)

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

PR: https://git.openjdk.org/jdk/pull/12932

From duke at openjdk.org  Wed Mar  8 21:28:29 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 8 Mar 2023 21:28:29 GMT
Subject: <i18n dev> =?utf-8?q?Integrated=3A_8303833=3A_java=2Eutil=2ELoca?=
 =?utf-8?q?leISOData_has_wrong_comments_for_=27Norwegian_Bokm=C3=A5l=27_an?=
 =?utf-8?b?ZCAnVm9sYXDDvGsn?=
In-Reply-To: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
References: <ugjAW8Dw4OHaQdU03FK5H_yTvc9obDkqC-775pwG7xg=.8b51c564-bcff-49cb-929f-c7467fa2fcfc@github.com>
Message-ID: <wnbpJkXxk7KpIMGNJ57AhpHWqg26g5CzYDYdDYFxRds=.f2779b03-1d6b-4f7e-a28e-a4a819c95382@github.com>

On Wed, 8 Mar 2023 19:57:43 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this comment-only PR which fixes incorrect language names  'Norwegian Bokm?l' and 'Volap?k' in the comments in LocaleISOData:
> 
> `+ "nb" + "nob"  // Norwegian Bokm?l`
> `+ "vo" + "vol"  // Volap?k`
> 
> These encoding issues seem to have been around since Duke imported the file in 2007. Let's fix them now.
> 
> For context: 'Norwegian bokm?l'  is the most common written form of the Norwegian language:
> 
> https://en.wikipedia.org/wiki/Bokm%C3%A5l
> 
> 'Volap?k' is a constructed language: 
> 
> https://en.wikipedia.org/wiki/Volap%C3%BCk

This pull request has now been integrated.

Changeset: 05ceb37a
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05ceb37a2c036580d445c5a7759db74633c090fe
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8303833: java.util.LocaleISOData has wrong comments for 'Norwegian Bokm?l' and 'Volap?k'

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/12932

From jlu at openjdk.org  Thu Mar  9 00:13:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 9 Mar 2023 00:13:21 GMT
Subject: <i18n dev> Integrated: 8171156: Class java.util.LocaleISOData has
 outdated information for country Code NP
In-Reply-To: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com>
References: <0CQdEFn8R2OO_XAG5RSmSYgN-jm8-G0tv7SuETPD8-4=.d6cd8746-0a64-47f5-a38d-cce5ede7009d@github.com>
Message-ID: <YN5RM8aG6GZcWEFlEkfzbRlESeacsAlMYQQi0eNY6kQ=.c966b43f-2a52-446b-baec-08d89252f362@github.com>

On Tue, 7 Mar 2023 22:55:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for Nepal. 
> 
> According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the [UN](https://www.un.int/protocol/sites/www.un.int/files/Protocol%20and%20Liaison%20Service/officialnamesofcountries.pdf), Nepal's formal name should be  `Federal Democratic Republic of Nepal`, not `Kingdom of Nepal`. It is only a comment, however there is no reason it should not be corrected.

This pull request has now been integrated.

Changeset: 02875e77
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02875e77fd01c39aee6f2f0900ea5605b40a8780
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8171156: Class java.util.LocaleISOData has outdated information for country Code NP

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/12912

From jlu at openjdk.org  Thu Mar  9 17:59:26 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 9 Mar 2023 17:59:26 GMT
Subject: <i18n dev> RFR: 8303853: Update ISO 3166 country codes table
Message-ID: <a31UAqyURLWqhD_KbaX4Xfyffn_JRsgLOJvP84r0jUU=.c8720c6e-0b04-4629-a4e4-6599afe855c3@github.com>

This PR incorporates all of the missing updates to ensure that `java.util.LocaleISOData.isoCountryTable` is on par with the official [ISO 3166 data](https://www.iso.org/obp/ui/#search/code/).

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

Commit messages:
 - 2006-03-29 fix
 - 2007-09-21 fix
 - 2003-07-23 fix
 - 2013-02-06 update
 - 2012-08-02 update
 - 2012-02-15 update
 - 2011-11-08 update
 - 2011-08-09 update
 - 2011-06-12 update
 - 2010-02-22 update
 - ... and 1 more: https://git.openjdk.org/jdk/compare/f3abc406...a2be3546

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

PR: https://git.openjdk.org/jdk/pull/12954

From naoto at openjdk.org  Thu Mar  9 18:28:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 Mar 2023 18:28:54 GMT
Subject: <i18n dev> RFR: 8303853: Update ISO 3166 country codes table
In-Reply-To: <a31UAqyURLWqhD_KbaX4Xfyffn_JRsgLOJvP84r0jUU=.c8720c6e-0b04-4629-a4e4-6599afe855c3@github.com>
References: <a31UAqyURLWqhD_KbaX4Xfyffn_JRsgLOJvP84r0jUU=.c8720c6e-0b04-4629-a4e4-6599afe855c3@github.com>
Message-ID: <PJy4SKkxxsUORa_19mu23TPjGJwnLR3b4jiQaxQHdQs=.0a7b42c4-25f2-4209-81bd-15dec0f4d9df@github.com>

On Thu, 9 Mar 2023 17:50:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR incorporates all of the missing updates to ensure that `java.util.LocaleISOData.isoCountryTable` is on par with the official [ISO 3166 data](https://www.iso.org/obp/ui/#search/code/).

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12954

From jlaskey at openjdk.org  Fri Mar 10 13:35:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Mar 2023 13:35:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v44]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_ts4xtDO0xFOvi6L7tZeqYzVuC3Nx5zq6JgFu-pazWM=.4b432013-5cd6-4f9b-9086-3608f3ec339b@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - Correction
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Javadoc corrections and bug fix for StringTemplate::combine
 - Tighten up reporting of string template errors (fewer messages)
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - ... and 51 more: https://git.openjdk.org/jdk/compare/68b5eef4...50456b32

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=43
  Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlu at openjdk.org  Fri Mar 10 17:36:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 10 Mar 2023 17:36:13 GMT
Subject: <i18n dev> RFR: 8303917: Update ISO 639 language codes table
Message-ID: <MOENoJ2KcvUifb9Gl6LLSWwQ90P-JyouAgSWFS1BB3A=.34e7d11d-bde8-4749-854f-f91e55261082@github.com>

This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.).

In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed.

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

Commit messages:
 - Minor changes / cleanup
 - Update ISO 639 test data
 - NC updates, revert Moldavian change
 - 2009-09-01 Name Change
 -  2008-11-03: Deprecate Moldavian/mo/mol

Changes: https://git.openjdk.org/jdk/pull/12980/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12980&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303917
  Stats: 843 lines in 2 files changed: 64 ins; 626 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/12980.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12980/head:pull/12980

PR: https://git.openjdk.org/jdk/pull/12980

From jlu at openjdk.org  Fri Mar 10 17:42:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 10 Mar 2023 17:42:17 GMT
Subject: <i18n dev> Integrated: 8303853: Update ISO 3166 country codes table
In-Reply-To: <a31UAqyURLWqhD_KbaX4Xfyffn_JRsgLOJvP84r0jUU=.c8720c6e-0b04-4629-a4e4-6599afe855c3@github.com>
References: <a31UAqyURLWqhD_KbaX4Xfyffn_JRsgLOJvP84r0jUU=.c8720c6e-0b04-4629-a4e4-6599afe855c3@github.com>
Message-ID: <wBvSvY5vacxQg0SiLVznyhZBKEpxw7sDKDSf_MsAdVU=.c2b4668f-1e69-40fc-8cfa-3b0d28cebd4e@github.com>

On Thu, 9 Mar 2023 17:50:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR incorporates all of the missing updates to ensure that `java.util.LocaleISOData.isoCountryTable` is on par with the official [ISO 3166 data](https://www.iso.org/obp/ui/#search/code/).

This pull request has now been integrated.

Changeset: a3358b10
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3358b10cab44a97404aee8c1d07d580930fd199
Stats:     15 lines in 1 file changed: 0 ins; 0 del; 15 mod

8303853: Update ISO 3166 country codes table

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/12954

From naoto at openjdk.org  Fri Mar 10 22:17:30 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 10 Mar 2023 22:17:30 GMT
Subject: <i18n dev> RFR: 8303917: Update ISO 639 language codes table
In-Reply-To: <MOENoJ2KcvUifb9Gl6LLSWwQ90P-JyouAgSWFS1BB3A=.34e7d11d-bde8-4749-854f-f91e55261082@github.com>
References: <MOENoJ2KcvUifb9Gl6LLSWwQ90P-JyouAgSWFS1BB3A=.34e7d11d-bde8-4749-854f-f91e55261082@github.com>
Message-ID: <hZCdXoFh55MJxtzYrMjdYI80tanwXTOdy4dEQGUpKNU=.8dd64a42-0e41-494f-b415-4f9a6c31ffe8@github.com>

On Fri, 10 Mar 2023 17:27:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.).
> 
> In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed.

Looks good.

test/jdk/java/util/Locale/Bug4175998Test.java line 284:

> 282:                 System.out.print("\""+iso639_2B+"\",");
> 283:                 System.out.print("\""+iso639_2T+"\"");
> 284:                 System.out.println("},");

Could be simplified like

System.out.printf("""
    {"%s","%s","%s"},
""", iso639_1, iso639_2B, iso639_2T);

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12980

From duke at openjdk.org  Sun Mar 12 17:43:15 2023
From: duke at openjdk.org (Jeremy)
Date: Sun, 12 Mar 2023 17:43:15 GMT
Subject: <i18n dev> RFR: JDK-8303950: translucent windows flicker
Message-ID: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>

I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)

In short:
This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`

I left more detailed notes here about the proposed resolution:
https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c

I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

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

Commit messages:
 - 8303950: fixing false negative
 - 8303950: avoid letting Window.paint(..) call g.fillRect(..)
 - 8303950: adding failing test to identify problem
 - Merge pull request #4 from openjdk/master
 - Merge pull request #3 from openjdk/master
 - Merge pull request #2 from openjdk/master
 - Merge pull request #1 from openjdk/master

Changes: https://git.openjdk.org/jdk/pull/12993/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303950
  Stats: 246 lines in 4 files changed: 241 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12993.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12993/head:pull/12993

PR: https://git.openjdk.org/jdk/pull/12993

From jlu at openjdk.org  Mon Mar 13 16:58:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 13 Mar 2023 16:58:09 GMT
Subject: <i18n dev> RFR: 8303917: Update ISO 639 language codes table
 [v2]
In-Reply-To: <MOENoJ2KcvUifb9Gl6LLSWwQ90P-JyouAgSWFS1BB3A=.34e7d11d-bde8-4749-854f-f91e55261082@github.com>
References: <MOENoJ2KcvUifb9Gl6LLSWwQ90P-JyouAgSWFS1BB3A=.34e7d11d-bde8-4749-854f-f91e55261082@github.com>
Message-ID: <RC00dsv3YsJNBS2FpakOrLas8NEcfXZL08_sLmhTwA8=.6582bdcc-75b7-4b2c-90a8-25181a76f944@github.com>

> This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.).
> 
> In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Simplfy print statements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12980/files
  - new: https://git.openjdk.org/jdk/pull/12980/files/5000c261..a43f9f4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12980&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12980&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12980

From naoto at openjdk.org  Mon Mar 13 21:25:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Mar 2023 21:25:51 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties
Message-ID: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>

Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.

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

Commit messages:
 - Clean-up
 - UTR -> UTS
 - prepared javadoc
 - added a test case
 - 8303018: Unicode Emoji Properties

Changes: https://git.openjdk.org/jdk/pull/13006/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303018
  Stats: 869 lines in 19 files changed: 592 ins; 254 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13006.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13006/head:pull/13006

PR: https://git.openjdk.org/jdk/pull/13006

From serb at openjdk.org  Mon Mar 13 22:30:48 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 13 Mar 2023 22:30:48 GMT
Subject: <i18n dev> RFR: JDK-8303950: translucent windows flicker
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <W199g3jQUphucFjrVgvo58apeKE6JWhyGYUfCQzgNLg=.6aa7e8bc-c187-4d80-973a-f602a03c6539@github.com>

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

It is probably better to  integrate this "clear" operation into the peer and/or repaintmanager, and exclude it in this method.

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

PR: https://git.openjdk.org/jdk/pull/12993

From duke at openjdk.org  Tue Mar 14 00:10:27 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 14 Mar 2023 00:10:27 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint
In-Reply-To: <W199g3jQUphucFjrVgvo58apeKE6JWhyGYUfCQzgNLg=.6aa7e8bc-c187-4d80-973a-f602a03c6539@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <W199g3jQUphucFjrVgvo58apeKE6JWhyGYUfCQzgNLg=.6aa7e8bc-c187-4d80-973a-f602a03c6539@github.com>
Message-ID: <rJd-Lo7HlSHKC4iTa3rhNX77h1dY827p4zPazQQkI6k=.9f5f52a8-74d1-462c-907c-fe0f8b140a66@github.com>

On Mon, 13 Mar 2023 22:27:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It is probably better to integrate this "clear" operation into the peer and/or repaintmanager, and exclude it in this method.

Are you sure? (Or alternatively: maybe I don't understand what you mean?)

By "clear operation" I assume you're referring to the call in Window.java `gg2dfillRect`. This clear logic has existed since 2009, so I'm reluctant to remove it. (And if we remove it: we can just remove the entire `paint(Graphics)` method, because that's the only reason it's overridden, right?)

Here's a screenshot of the code in question & a little git annotation:
<img width="1316" alt="image" src="https://user-images.githubusercontent.com/7669569/224851605-e697e698-c4ee-439e-9e04-6b41659a12f4.png">

If you still want me to try to migrate this logic: can you give me an example of which classes you'd recommend trying to move it to?

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

PR: https://git.openjdk.org/jdk/pull/12993

From prr at openjdk.org  Tue Mar 14 00:48:10 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Mar 2023 00:48:10 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties
In-Reply-To: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
Message-ID: <JXi-x0UDRieD3i2Pxa1M6cz5vInn0UsjmqdVd8BZ7sk=.d2d1a9a7-2010-4172-8b38-d1dcc692407a@github.com>

On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.

Not at all familiar with all these templates but everything I do understand lgtm :-)

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13006

From serb at openjdk.org  Tue Mar 14 01:02:34 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 14 Mar 2023 01:02:34 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint
In-Reply-To: <rJd-Lo7HlSHKC4iTa3rhNX77h1dY827p4zPazQQkI6k=.9f5f52a8-74d1-462c-907c-fe0f8b140a66@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <W199g3jQUphucFjrVgvo58apeKE6JWhyGYUfCQzgNLg=.6aa7e8bc-c187-4d80-973a-f602a03c6539@github.com>
 <rJd-Lo7HlSHKC4iTa3rhNX77h1dY827p4zPazQQkI6k=.9f5f52a8-74d1-462c-907c-fe0f8b140a66@github.com>
Message-ID: <gzXgcJxomMenn6t5LDD6DPdakdacBjvWI5_zTfAHvqg=.f753c5d5-f561-40f3-862c-7d66eb42d8ca@github.com>

On Tue, 14 Mar 2023 00:07:33 GMT, Jeremy <duke at openjdk.org> wrote:

> If you still want me to try to migrate this logic: can you give me an example of which classes you'd recommend trying to move it to?

That logic exists there to clear the window if it does not opaque and have some translucent pixels, and it was added there to clear the old content of the window before the new rendering is started. So we cannot just skip that part, but probably we can move this step closer to the place we actually start to render.

I would like to clarify two question:
 - I think most of the opaque/non-transparent components fill the background by the opaque color(including windows/frames/etc), why the problem is not reproduced in that case?
 - Why the double-buffer in the RepaintManager does not handle this? If no buffers are used, then probably we should have one to render everything to it and then blit to Window?

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

PR: https://git.openjdk.org/jdk/pull/12993

From duke at openjdk.org  Tue Mar 14 07:07:16 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 14 Mar 2023 07:07:16 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <j3_jEw1jHqUop9jZEmNfmtv4lTrPSLPqLzxvdO1ib3w=.a473f0ee-5a55-48d2-83f9-18bd979a704d@github.com>

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

> I would like to clarify two question:
> 
>  1. I think most of the opaque/non-transparent components fill the background by the opaque color(including windows/frames/etc), why the problem is not reproduced in that case?

Great question. (I wasn't sure, so I had to explore this.)

The RepaintManager interprets a repaint request for any given JComponent and finds its nearest opaque ancestor to repaint.

I modified my test so the JLabel is opaque and added a debugger breakpoint in RepaintManager.paintDirtyRegions. RepaintManager enters this block of code:

                        if (dirtyComponent instanceof JComponent) {
                            ((JComponent)dirtyComponent).paintImmediately(
                                rect.x,rect.y,rect.width, rect.height);
                        }
                        else if (dirtyComponent.isShowing()) {
                            Graphics g = JComponent.safelyGetGraphics(
                                    dirtyComponent, dirtyComponent);
                            // If the Graphics goes away, it means someone disposed of
                            // the window, don't do anything.
                            if (g != null) {
                                g.setClip(rect.x, rect.y, rect.width, rect.height);
                                try {
                                    dirtyComponent.paint(g);
                                } finally {
                                    g.dispose();
                                }
                            }
                        }


So when my JLabel was opaque: we entered the first branch (where `dirtyComponent` is the JLabel). Here Swing tightly controls this process, and eventually we call `c.paintToOffscreen`, where c is the JLabel and the Graphics2D is a reference to RepaintManager's offscreen image. Once the JComponent is finished, then the PaintManager calls:

                            final Graphics2D g2d = (Graphics2D) g;
                            final Composite oldComposite = g2d.getComposite();
                            g2d.setComposite(AlphaComposite.Src);
                            g2d.drawImage(image, x, y, c);
                            g2d.setComposite(oldComposite);

This time `g` is the Window's Graphics2D that relates to the actual surface data on the monitor.

Specifically the stacktrace I'm seeing in JDK 19 when I repainted my opaque JLabel is:

paintDoubleBufferedImpl:1663, RepaintManager$PaintManager (javax.swing)
paintDoubleBuffered:1631, RepaintManager$PaintManager (javax.swing)
paint:1569, RepaintManager$PaintManager (javax.swing)
paint:1336, RepaintManager (javax.swing)
_paintImmediately:5266, JComponent (javax.swing)
paintImmediately:5076, JComponent (javax.swing)
run:878, RepaintManager$4 (javax.swing)
run:861, RepaintManager$4 (javax.swing)
executePrivileged:776, AccessController (java.security)
doPrivileged:399, AccessController (java.security)
doIntersectionPrivilege:86, ProtectionDomain$JavaSecurityAccessImpl (java.security)
paintDirtyRegions:861, RepaintManager (javax.swing)
paintDirtyRegions:834, RepaintManager (javax.swing)
prePaintDirtyRegions:784, RepaintManager (javax.swing)
run:1897, RepaintManager$ProcessingRunnable (javax.swing)
dispatch$$$capture:318, InvocationEvent (java.awt.event)
dispatch:-1, InvocationEvent (java.awt.event)


>  2. Why the double-buffer in the RepaintManager does not handle this? If no buffers are used, then probably we should have one to render everything to it and then blit to Window?

In the original unit test: the JLabel is not opaque, so the `dirtyComponent` we set out to repaint was our root JWindow. So we entered the second branch in the code above and called `dirtyComponent.paint(g)`.

Once we entered Swing rendering code: all our rendering really was double-buffered to the appropriate offscreen image. But the problem is Window.java has that one call to `fillRect` that is outside of Swing's rendering model. (So in a way this is a subtle clash of Swing vs AWT code.)

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

PR: https://git.openjdk.org/jdk/pull/12993

From duke at openjdk.org  Tue Mar 14 07:12:14 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 14 Mar 2023 07:12:14 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <zC6OzJqbLakrQ1XMBXwG4-P_AfCxsNDSVyXcKsmARRA=.6e9cd278-b031-4354-8a04-101b7c83d07d@github.com>

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

So I'm generally hearing 3 responses to this ticket (so far):

1. My interpretation: we have this one known problem (where Window.java is calling `fillRect(..)`), and if we just flip a switch and avoid that code then the flicker is gone.
2. Alan's interpretation (see [8209329](https://bugs.openjdk.org/browse/JDK-8209329) ): we can eliminate the flicker by better synchronizing when the Window's surface data is flushed. (So `Window.paint(..)` can do anything it wants to: if we control when the monitor refreshes there won't be a flicker.)
3. Sergey's interpretation: if we make sure the Graphics we pass to `dirtyComponent.paint(..)` is the offscreen buffer, then that should also resolve the flicker.

Does this sound like a fair assessment, and if so: how do we decide which response to pursue?

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

PR: https://git.openjdk.org/jdk/pull/12993

From alanb at openjdk.org  Tue Mar 14 08:16:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Mar 2023 08:16:16 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties
In-Reply-To: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
Message-ID: <Ou8EtxOyoXX62S3yT7A2S0O2yhZGL6btSQYeazOQXDE=.7bfb8f0e-5ee0-45df-b98b-e7a99a15c246@github.com>

On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.

src/java.base/share/classes/java/lang/Character.java line 10803:

> 10801:     /**
> 10802:      * Determines if the specified character (Unicode code point) has the
> 10803:      * Emoji Presentation by default.

"has the Emoji Presentation", should that be "has the Emoji Presentation property"?

src/java.base/share/classes/java/lang/Character.java line 10887:

> 10885:      * @since   21
> 10886:      */
> 10887:     public static boolean isExtendedPictographic(int codePoint) {

Is there a "cut 'n paste" error here, it looks like the description has been copied from  isEmojiComponent.

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

PR: https://git.openjdk.org/jdk/pull/13006

From duke at openjdk.org  Tue Mar 14 12:04:03 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Mar 2023 12:04:03 GMT
Subject: <i18n dev> RFR: 8302872: Speed up
 StringLatin1.regionMatchesCI_UTF16 [v2]
In-Reply-To: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
References: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
Message-ID: <VSax-t1i4WX5Nh5rNDue77xVSgHFZgwy1VgD-UEzJMk=.bdf22ad2-cf7c-4c4d-99bb-dc54a2cce522@github.com>

> This PR continues the efforts from #12632 to speed up case-insensitive string matching.
> 
> We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16`
> 
> Key insights:
> 
> - If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase`
> - There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`.
> - To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. 
>  
> For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one.  Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR.   
> 
> To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty.
> 
> Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below.

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' into regionmatches-mixed-speedup
 - Inline local variable
 - latin1CaseFold was moved to CharacterDataLatin1
 - Move latin1CaseFold to CharacterDataLatin1
 - Improve latin1CaseFold javadocs
 - Simplify comments
 - Prefer fast matching by comparing for equality before checking latin1 range
 - Improve Javadocs of latin1CaseFold
 - Be consistent in comments
 - CharacterData.latin1LowerCase was renamed to latin1CaseFold
 - ... and 14 more: https://git.openjdk.org/jdk/compare/6d30bbe6...2340f8b5

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

Changes: https://git.openjdk.org/jdk/pull/12637/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12637&range=01
  Stats: 169 lines in 5 files changed: 155 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12637.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12637/head:pull/12637

PR: https://git.openjdk.org/jdk/pull/12637

From erikj at openjdk.org  Tue Mar 14 13:19:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 14 Mar 2023 13:19:17 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties
In-Reply-To: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
Message-ID: <Ee75UzblpZC0AH7_6ZTB_QLX54PDee4UFwMt-CiQcYs=.985c9e06-334b-482d-a77f-3f4186a54dd3@github.com>

On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.

Build changes look ok.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13006

From naoto at openjdk.org  Tue Mar 14 15:49:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Mar 2023 15:49:56 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
Message-ID: <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>

> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.

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

  Fixed method descriptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13006/files
  - new: https://git.openjdk.org/jdk/pull/13006/files/4b2a2418..0b7b7296

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13006.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13006/head:pull/13006

PR: https://git.openjdk.org/jdk/pull/13006

From naoto at openjdk.org  Tue Mar 14 15:50:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Mar 2023 15:50:00 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <Ou8EtxOyoXX62S3yT7A2S0O2yhZGL6btSQYeazOQXDE=.7bfb8f0e-5ee0-45df-b98b-e7a99a15c246@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <Ou8EtxOyoXX62S3yT7A2S0O2yhZGL6btSQYeazOQXDE=.7bfb8f0e-5ee0-45df-b98b-e7a99a15c246@github.com>
Message-ID: <wEhcU37JcMnyUoKx5TtCl2n_ReKC9WMabzzivIJulkQ=.e971a841-6fc4-42cd-900c-5439672c82f4@github.com>

On Tue, 14 Mar 2023 08:13:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed method descriptions
>
> src/java.base/share/classes/java/lang/Character.java line 10803:
> 
>> 10801:     /**
>> 10802:      * Determines if the specified character (Unicode code point) has the
>> 10803:      * Emoji Presentation by default.
> 
> "has the Emoji Presentation", should that be "has the Emoji Presentation property"?

Fixed this one as well

> src/java.base/share/classes/java/lang/Character.java line 10887:
> 
>> 10885:      * @since   21
>> 10886:      */
>> 10887:     public static boolean isExtendedPictographic(int codePoint) {
> 
> Is there a "cut 'n paste" error here, it looks like the description has been copied from  isEmojiComponent.

My bad. You are right. Corrected.

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

PR: https://git.openjdk.org/jdk/pull/13006

From duke at openjdk.org  Tue Mar 14 17:12:59 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Mar 2023 17:12:59 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
Message-ID: <SHzzD8CHU7RTbN9whgro42Hg2cjHs8vlLXzQ2eYgEPM=.a9a6df4c-6855-404e-8df3-889b4f29ec7e@github.com>

On Tue, 14 Mar 2023 15:49:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed method descriptions

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 215:

> 213:         maskEmojiComponent  = 0x040000000000L,
> 214:         maskExtendedPictographic = 0x080000000000L;
> 215: 

Would be nice the have the '=' aligned in the same column as the ones above, or at least have the emoji ones align with each other.

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

PR: https://git.openjdk.org/jdk/pull/13006

From alanb at openjdk.org  Tue Mar 14 17:29:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 14 Mar 2023 17:29:06 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <wEhcU37JcMnyUoKx5TtCl2n_ReKC9WMabzzivIJulkQ=.e971a841-6fc4-42cd-900c-5439672c82f4@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <Ou8EtxOyoXX62S3yT7A2S0O2yhZGL6btSQYeazOQXDE=.7bfb8f0e-5ee0-45df-b98b-e7a99a15c246@github.com>
 <wEhcU37JcMnyUoKx5TtCl2n_ReKC9WMabzzivIJulkQ=.e971a841-6fc4-42cd-900c-5439672c82f4@github.com>
Message-ID: <cF4D4YfI6NI2bQHzRw-gCGAq8ngx4cKQtmFp3pxIy3Q=.1d0191a4-3bc4-45b0-8d5e-f5927ddd2187@github.com>

On Tue, 14 Mar 2023 15:43:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed this one as well

Spec update looks good. I suppose I have to use an emoji to react to that ?

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

PR: https://git.openjdk.org/jdk/pull/13006

From duke at openjdk.org  Tue Mar 14 17:40:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Tue, 14 Mar 2023 17:40:50 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
Message-ID: <PqNeOjjinX7Dg9g7WTTIdhlam47XJYmtJuVETrl1tqY=.dfe31652-ee8c-4314-b7be-44494344b13d@github.com>

On Tue, 14 Mar 2023 15:49:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed method descriptions

Would it make sense to add something like the following to `GenerateCharacter.propertiesComments`?


if ((val & maskEmoji) == maskEmoji) {
    result.append(", emoji ");
}
if ((val & maskEmojiPresentation) == maskEmojiPresentation) {
    result.append(", emojiPresentation ");
}
if ((val & maskEmojiModifier) == maskEmojiModifier) {
    result.append(", emojiModifier ");
}
if ((val & maskEmojiModifierBase) == maskEmojiModifierBase) {
    result.append(", emojiModifierBase ");
}
if ((val & maskEmojiComponent) == maskEmojiComponent) {
    result.append(", emojiComponent ");
}
if ((val & maskExtendedPictographic) == maskExtendedPictographic) {
    result.append(", extendedPictographic ");
}


This updates the comments of the B table to something like this sample:


0x0000,  //  34   unassigned, L
0x0440,  //  35   unassigned, L, emoji , emojiComponent
0x0000,  //  36   unassigned, L

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

PR: https://git.openjdk.org/jdk/pull/13006

From rriggs at openjdk.org  Tue Mar 14 21:46:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Mar 2023 21:46:46 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
Message-ID: <JHIYX3d0v-N_NoslQZN2qKDPFnZ8uvcUePZpgAUfHeo=.33c3b60e-b3c3-4191-8d50-427896cb076a@github.com>

On Tue, 14 Mar 2023 15:49:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed method descriptions

Looks good.  
There are opportunities to modernize the code, but maybe separately.

make/jdk/src/classes/build/tools/generatecharacter/EmojiData.java line 99:

> 97:             case "Emoji_Component" -> EMOJI_COMPONENT;
> 98:             case "Extended_Pictographic" -> EXTENDED_PICTOGRAPHIC;
> 99:             default -> throw new InternalError();

It would be useful to include the "type" as the exception argument. It give some idea as to the corruption or missing case.

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 214:

> 212:         maskEmojiModifierBase = 0x020000000000L,
> 213:         maskEmojiComponent  = 0x040000000000L,
> 214:         maskExtendedPictographic = 0x080000000000L;

It would be good to leverage a common definition (perhaps a bit number) here and in EmojiData.java
and build the constants with <<< shifts.

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 810:

> 808:         if (x.equals("maskEmojiModifierBase")) return "0x" + hex4(maskEmojiModifierBase >> 32);
> 809:         if (x.equals("maskEmojiComponent")) return "0x" + hex4(maskEmojiComponent >> 32);
> 810:         if (x.equals("maskExtendedPictographic")) return "0x" + hex4(maskExtendedPictographic >> 32);

An upgrade would be to modify hex4(), hexNN() to use `HexFormat.of().toUpperCase().toHexDigits((short)xxx)`
The HexFormat is reusable and would avoid creating extra strings.
Perhaps also create a method that combines the repetitive shift and prefixing.

This if...then... sequence could be an expression switch (x) {...}.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13006

From jlu at openjdk.org  Tue Mar 14 22:25:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 14 Mar 2023 22:25:22 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR
Message-ID: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>

This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.

For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.

To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.

After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

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

Commit messages:
 - method positioning
 - Bug fix to GregCal with accompanying test

Changes: https://git.openjdk.org/jdk/pull/13031/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8225641
  Stats: 167 lines in 2 files changed: 165 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From duke at openjdk.org  Wed Mar 15 11:47:15 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 11:47:15 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding bit
 shifting in the latin1 fast-path test
Message-ID: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>

By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.

The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for ASCII chars):

This methods is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.

Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):

Baseline:


Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op

PR:


Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op

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

Commit messages:
 - Update copyright year
 - Avoid bit shifting in the CharacterDataLatin1 fast-path

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

PR: https://git.openjdk.org/jdk/pull/13040

From stsypanov at openjdk.org  Wed Mar 15 11:52:20 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 15 Mar 2023 11:52:20 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
Message-ID: <kjdGcHa6SVH2PBz2YWQJzEWNVBrZvjosKfJ5LJnEFCk=.51db0385-821b-4c01-908e-e28a935a2b25@github.com>

On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
> 
> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
> 
> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
> 
> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
> 
> Baseline:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
> 
> PR:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op

Marked as reviewed by stsypanov (Author).

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

PR: https://git.openjdk.org/jdk/pull/13040

From redestad at openjdk.org  Wed Mar 15 12:03:20 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 Mar 2023 12:03:20 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
Message-ID: <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>

On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
> 
> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
> 
> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
> 
> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
> 
> Baseline:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
> 
> PR:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op

Nice one!

src/java.base/share/classes/java/lang/CharacterData.java line 72:

> 70: 
> 71:     static final CharacterData of(int ch) {
> 72:         if (ch >= 0 && ch <= 0xFF) {     // fast-path

Maybereducing to a single branch with a mask op helps further? Or maybe the JIT already effectively does that:

`if (ch && 0xFFFFFF00 == 0) {`

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13040

From stsypanov at openjdk.org  Wed Mar 15 12:10:23 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 15 Mar 2023 12:10:23 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
Message-ID: <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>

On Wed, 15 Mar 2023 11:58:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>> 
>> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
>> 
>> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
>> 
>> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
>> 
>> Baseline:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
>> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
>> 
>> PR:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
>> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op
>
> src/java.base/share/classes/java/lang/CharacterData.java line 72:
> 
>> 70: 
>> 71:     static final CharacterData of(int ch) {
>> 72:         if (ch >= 0 && ch <= 0xFF) {     // fast-path
> 
> Maybereducing to a single branch with a mask op helps further? Or maybe the JIT already effectively does that:
> 
> `if (ch && 0xFFFFFF00 == 0) {`

Btw, I think we can do the same for `StringLatin1.canEncode()`

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

PR: https://git.openjdk.org/jdk/pull/13040

From redestad at openjdk.org  Wed Mar 15 12:15:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 15 Mar 2023 12:15:22 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
Message-ID: <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>

On Wed, 15 Mar 2023 12:07:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharacterData.java line 72:
>> 
>>> 70: 
>>> 71:     static final CharacterData of(int ch) {
>>> 72:         if (ch >= 0 && ch <= 0xFF) {     // fast-path
>> 
>> Maybereducing to a single branch with a mask op helps further? Or maybe the JIT already effectively does that:
>> 
>> `if (ch && 0xFFFFFF00 == 0) {`
>
> Btw, I think we can do the same for `StringLatin1.canEncode()`

It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly)

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 12:19:21 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 12:19:21 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
Message-ID: <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>

On Wed, 15 Mar 2023 12:13:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Btw, I think we can do the same for `StringLatin1.canEncode()`
>
> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly)

> `if (ch && 0xFFFFFF00 == 0) {`

This seems to perform similar to baseline:


Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigit           48  avgt   15  0.890 ? 0.025  ns/op
Characters.isDigit         1632  avgt   15  2.174 ? 0.011  ns/op


Would be interesting to check the performance on non-Intel architectures. If you want to give it a spin on your M1, here's the benchmark command I used:

`make test TEST='micro:java.lang.Characters.isDigit' MICRO="OPTIONS=-p codePoint=48,1632"`

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 12:31:21 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 12:31:21 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
Message-ID: <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>

On Wed, 15 Mar 2023 12:15:39 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly)
>
>> `if (ch && 0xFFFFFF00 == 0) {`
> 
> This seems to perform similar to baseline:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.890 ? 0.025  ns/op
> Characters.isDigit         1632  avgt   15  2.174 ? 0.011  ns/op
> 
> 
> Would be interesting to check the performance on non-Intel architectures. If you want to give it a spin on your M1, here's the benchmark command I used:
> 
> `make test TEST='micro:java.lang.Characters.isDigit' MICRO="OPTIONS=-p codePoint=48,1632"`

> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly)

If I update `StringLatin1.canEncode` and call into that from `CharacterData.of`, I observe no regression for the Latin1 case, but a significant regression for the non-Latin1 case. I have no idea how to explain that:


Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigit           48  avgt   15  0.675 ? 0.029  ns/op
Characters.isDigit         1632  avgt   15  2.435 ? 0.032  ns/op

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 12:40:19 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 15 Mar 2023 12:40:19 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
Message-ID: <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>

On Wed, 15 Mar 2023 12:28:05 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>>> `if (ch && 0xFFFFFF00 == 0) {`
>> 
>> This seems to perform similar to baseline:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.890 ? 0.025  ns/op
>> Characters.isDigit         1632  avgt   15  2.174 ? 0.011  ns/op
>> 
>> 
>> Would be interesting to check the performance on non-Intel architectures. If you want to give it a spin on your M1, here's the benchmark command I used:
>> 
>> `make test TEST='micro:java.lang.Characters.isDigit' MICRO="OPTIONS=-p codePoint=48,1632"`
>
>> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly)
> 
> If I update `StringLatin1.canEncode` and call into that from `CharacterData.of`, I observe no regression for the Latin1 case, but a significant regression for the non-Latin1 case. I have no idea how to explain that:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.675 ? 0.029  ns/op
> Characters.isDigit         1632  avgt   15  2.435 ? 0.032  ns/op

Can you check what happen adding much more inputs to the dataset that includes non-latin chars as well and use `-prof perfnorm` to check what `perf` report re branches/branch-misses?

You can use SplittableRandom to pre-populate an array of inputs which sequence is "random" but still allow deterministic benchmarking and feed the benchmark method cycling the pre-computed inputs

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 13:45:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 13:45:31 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
 <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
Message-ID: <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>

On Wed, 15 Mar 2023 12:37:24 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>>> It seems reasonable to keep these two in sync, yes. (`CharacterData.of` could even call into `StringLatin1.canEncode`, unless that's cause for some performance anomaly)
>> 
>> If I update `StringLatin1.canEncode` and call into that from `CharacterData.of`, I observe no regression for the Latin1 case, but a significant regression for the non-Latin1 case. I have no idea how to explain that:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.675 ? 0.029  ns/op
>> Characters.isDigit         1632  avgt   15  2.435 ? 0.032  ns/op
>
> Can you check what happen adding much more inputs to the dataset including non-latin chars as well and use `-prof perfnorm` to check what `perf` report re branches/branch-misses?
> 
> You can use `SplittableRandom` to pre-populate an array of inputs which sequence is "random" but still allow deterministic benchmarking and feed the benchmark method by cycling the pre-computed inputs.
> In the real world I expect `isDigit` to happen on different input types and both having C2 with both branches places based on prev inputs distribution and a confused branch-predictor to allow comparing vs something that looks a bit nearest to the real world (TBD, I know).
> I expect in that case that a single cmp + mask to work better depending on latin input distribution/occurrence

I created a randomized version of `Characters.isDigit` which tests with code points picked at random such that any category (Latin1, negative, different planes, unassiged) are equally probable.

Baseline:


Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitRandom         1632  avgt   15  5.503 ? 0.371  ns/op


Current PR:


Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitRandom         1632  avgt   15  5.393 ? 0.336  ns/op


Using StringLatin1.canEncode:


Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitRandom         1632  avgt   15  5.377 ? 0.322  ns/op


Seems the PR still has a small improvement for this scenario. The StringLatin1.canEncode regression disappears.

In the real world ASCII/Latin1 seems to dominate most data, so this scenario is perhaps not very realistic.

I'm running this on a Mac, so cannot try `-prof perfnorm`.

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 13:54:19 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 15 Mar 2023 13:54:19 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test
In-Reply-To: <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
 <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
 <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>
Message-ID: <F4ZN8YJrZJhFq5rawO3kPNx-CuJpJJ5YivF_PqdBivs=.414d338d-1df2-4848-92f8-e8199d11abab@github.com>

On Wed, 15 Mar 2023 13:42:22 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Can you check what happen adding much more inputs to the dataset including non-latin chars as well and use `-prof perfnorm` to check what `perf` report re branches/branch-misses?
>> 
>> You can use `SplittableRandom` to pre-populate an array of inputs which sequence is "random" but still allow deterministic benchmarking and feed the benchmark method by cycling the pre-computed inputs.
>> In the real world I expect `isDigit` to happen on different input types and both having C2 with both branches places based on prev inputs distribution and a confused branch-predictor to allow comparing vs something that looks a bit nearest to the real world (TBD, I know).
>> I expect in that case that a single cmp + mask to work better depending on latin input distribution/occurrence
>
> I created a randomized version of `Characters.isDigit` which tests with code points picked at random such that any category (Latin1, negative, different planes, unassiged) are equally probable.
> 
> Baseline:
> 
> 
> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitRandom         1632  avgt   15  5.503 ? 0.371  ns/op
> 
> 
> Current PR:
> 
> 
> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitRandom         1632  avgt   15  5.393 ? 0.336  ns/op
> 
> 
> Using StringLatin1.canEncode:
> 
> 
> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitRandom         1632  avgt   15  5.377 ? 0.322  ns/op
> 
> 
> Seems the PR still has a small improvement for this scenario. The StringLatin1.canEncode regression disappears.
> 
> In the real world ASCII/Latin1 seems to dominate most data, so this scenario is perhaps not very realistic.
> 
> I'm running this on a Mac, so cannot try `-prof perfnorm`.

Many thanks to have tried, yep, I was curious indeed re the "StringLatin1.canEncode regression" case.
I would still modify the benchmark to use inputs (I know that will make it memory bound sadly, due to reading inputs - but the size of such inputs can be a benchmark parameter, together with the bias eg "latin","mix", "non-latin") "semi-randomly" generated based on the mentioned strategies/biases. 
It will benefit future tests on this, although could be provided as a separate PR.

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 14:31:03 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 14:31:03 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
Message-ID: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>

> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
> 
> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
> 
> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
> 
> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
> 
> Baseline:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
> 
> PR:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Update StringLatin1.canEncode to sync with same test in CharacterData.of

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13040/files
  - new: https://git.openjdk.org/jdk/pull/13040/files/0174440e..0baf690e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13040&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13040&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 14:31:06 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 14:31:06 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
Message-ID: <bD1z95IfMC8w2Jcca7fbAMz5BTnqZMLAYgVhxFCmck4=.7b144ab8-058d-497b-81a7-26159782c29c@github.com>

On Wed, 15 Mar 2023 12:00:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update StringLatin1.canEncode to sync with same test in CharacterData.of
>
> Nice one!

@cl4es Do you agree that the StringLatin1.canEncode change should be included in this PR? If so, can you approve the latest update?

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 14:31:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 14:31:09 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <F4ZN8YJrZJhFq5rawO3kPNx-CuJpJJ5YivF_PqdBivs=.414d338d-1df2-4848-92f8-e8199d11abab@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
 <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
 <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>
 <F4ZN8YJrZJhFq5rawO3kPNx-CuJpJJ5YivF_PqdBivs=.414d338d-1df2-4848-92f8-e8199d11abab@github.com>
Message-ID: <YV2aMSmaXODS7XDRN0K_oeWdcAx4KSIik363yfTL8t8=.f70fe081-54de-4bb4-ba4b-add4653f7a7a@github.com>

On Wed, 15 Mar 2023 13:50:44 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> I created a randomized version of `Characters.isDigit` which tests with code points picked at random such that any category (Latin1, negative, different planes, unassiged) are equally probable.
>> 
>> Baseline:
>> 
>> 
>> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigitRandom         1632  avgt   15  5.503 ? 0.371  ns/op
>> 
>> 
>> Current PR:
>> 
>> 
>> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigitRandom         1632  avgt   15  5.393 ? 0.336  ns/op
>> 
>> 
>> Using StringLatin1.canEncode:
>> 
>> 
>> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigitRandom         1632  avgt   15  5.377 ? 0.322  ns/op
>> 
>> 
>> Seems the PR still has a small improvement for this scenario. The StringLatin1.canEncode regression disappears.
>> 
>> In the real world ASCII/Latin1 seems to dominate most data, so this scenario is perhaps not very realistic.
>> 
>> I'm running this on a Mac, so cannot try `-prof perfnorm`.
>
> Many thanks to have tried, yep, I was curious indeed re the "StringLatin1.canEncode regression" case.
> I would still modify the benchmark to use inputs (I know that will make it memory bound sadly, due to reading inputs - but the size of such inputs can be a benchmark parameter, together with the bias eg "latin","mix", "non-latin") "semi-randomly" generated based on the mentioned strategies/biases. 
> It will benefit future tests on this, although could be provided as a separate PR.

> The StringLatin1.canEncode regression disappears.

I mixed things up so StringLatin1.canEncode was benchmarked without the updated code.

Here are updated benchmark results:


Baseline:


Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitRandom         1632  avgt   15  5.437 ? 0.235  ns/op


PR:


Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitRandom         1632  avgt   15  5.319 ? 0.341  ns/op


StringLatin1.canEncode:


Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitRandom         1632  avgt   15  5.447 ? 0.304  ns/op
``` 

So it seems using StringLatin1.canEncode still might have a regression also in the randomized input case.

For this PR, I suggest we update StringLatin1.canEncode to be in sync with CharacterData.of, without one calling the other. If anyone wants to investigate the regression further, than can be done outside this PR.

I have independently verified that StringLatin1.canEncode sees performance improvements using the StringIndexOf benchmark.

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

PR: https://git.openjdk.org/jdk/pull/13040

From stsypanov at openjdk.org  Wed Mar 15 14:40:23 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 15 Mar 2023 14:40:23 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
Message-ID: <oV7Jjf8BBM0iHjRTPhTgRgyPpumvCDUAqDp_gP1RdJg=.a1a928f0-b44d-4574-a3c8-dcde129c45a7@github.com>

On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>> 
>> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
>> 
>> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
>> 
>> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
>> 
>> Baseline:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
>> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
>> 
>> PR:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
>> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update StringLatin1.canEncode to sync with same test in CharacterData.of

Marked as reviewed by stsypanov (Author).

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

PR: https://git.openjdk.org/jdk/pull/13040

From qamai at openjdk.org  Wed Mar 15 15:00:28 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 15 Mar 2023 15:00:28 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <YV2aMSmaXODS7XDRN0K_oeWdcAx4KSIik363yfTL8t8=.f70fe081-54de-4bb4-ba4b-add4653f7a7a@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
 <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
 <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>
 <F4ZN8YJrZJhFq5rawO3kPNx-CuJpJJ5YivF_PqdBivs=.414d338d-1df2-4848-92f8-e8199d11abab@github.com>
 <YV2aMSmaXODS7XDRN0K_oeWdcAx4KSIik363yfTL8t8=.f70fe081-54de-4bb4-ba4b-add4653f7a7a@github.com>
Message-ID: <UCceloyvmZ1dvby1icLQrnz_sbgi0N0EpezMwxHJsF8=.c8f38602-fb02-46ce-a67f-03e6a458e2c9@github.com>

On Wed, 15 Mar 2023 14:23:35 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Many thanks to have tried, yep, I was curious indeed re the "StringLatin1.canEncode regression" case.
>> I would still modify the benchmark to use inputs (I know that will make it memory bound sadly, due to reading inputs - but the size of such inputs can be a benchmark parameter, together with the bias eg "latin","mix", "non-latin") "semi-randomly" generated based on the mentioned strategies/biases. 
>> It will benefit future tests on this, although could be provided as a separate PR.
>
>> The StringLatin1.canEncode regression disappears.
> 
> I mixed things up so StringLatin1.canEncode was benchmarked without the updated code.
> 
> Here are updated benchmark results:
> 
> 
> Baseline:
> 
> 
> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitRandom         1632  avgt   15  5.437 ? 0.235  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitRandom         1632  avgt   15  5.319 ? 0.341  ns/op
> 
> 
> StringLatin1.canEncode:
> 
> 
> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitRandom         1632  avgt   15  5.447 ? 0.304  ns/op
> ``` 
> 
> So it seems using StringLatin1.canEncode still might have a regression also in the randomized input case.
> 
> For this PR, I suggest we update StringLatin1.canEncode to be in sync with CharacterData.of, without one calling the other. If anyone wants to investigate the regression further, than can be done outside this PR.
> 
> I have independently verified that StringLatin1.canEncode sees performance improvements using the StringIndexOf benchmark.

We can do `Integer.compareUnsigned(ch, 0xFF) <= 0`

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 15:00:25 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 15:00:25 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
Message-ID: <UpbXyyChO19ba1PQZP9qV7Y7cSUO0wbs9lXgmaBsKLE=.cd8a1973-39b2-4ee4-8915-814f9c43746b@github.com>

On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>> 
>> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
>> 
>> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
>> 
>> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
>> 
>> Baseline:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
>> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
>> 
>> PR:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
>> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update StringLatin1.canEncode to sync with same test in CharacterData.of

Just for fun, I tried with a benchmark where the code point is Latin1 in every other call:


@Benchmark
public void isDigitVarying(Blackhole blackhole) {
    blackhole.consume(Character.isDigit(48));
    blackhole.consume(Character.isDigit(1632));
}


With this benchmark, there is no difference between the baseline, the PR and using StringLatin1.canEncode:

Baseline:


Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitVarying         1632  avgt   15  1.198 ? 0.056  ns/op


PR:


Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitVarying         1632  avgt   15  1.195 ? 0.058  ns/op


StringLatin1.canEncode:


Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
Characters.isDigitVarying         1632  avgt   15  1.193 ? 0.055  ns/op
``` 

At this point, I'm starting to wonder a bit if the performance benefits suggested by this PR might be dubious and will only surface in very narrow benchmarks. On the other hand, it does not seem harmful either. What do people think?

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 15:10:29 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 15 Mar 2023 15:10:29 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <UpbXyyChO19ba1PQZP9qV7Y7cSUO0wbs9lXgmaBsKLE=.cd8a1973-39b2-4ee4-8915-814f9c43746b@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
 <UpbXyyChO19ba1PQZP9qV7Y7cSUO0wbs9lXgmaBsKLE=.cd8a1973-39b2-4ee4-8915-814f9c43746b@github.com>
Message-ID: <pSYkywnbuOxUZ-ZuMjeOyBAnxFQxUGEYEosNDoBzDeU=.c651c133-a370-4a40-b3b1-cc7dbb580556@github.com>

On Wed, 15 Mar 2023 14:56:28 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update StringLatin1.canEncode to sync with same test in CharacterData.of
>
> Just for fun, I tried with a benchmark where the code point is Latin1 in every other call:
> 
> 
> @Benchmark
> public void isDigitVarying(Blackhole blackhole) {
>     blackhole.consume(Character.isDigit(48));
>     blackhole.consume(Character.isDigit(1632));
> }
> 
> 
> With this benchmark, there is no difference between the baseline, the PR and using StringLatin1.canEncode:
> 
> Baseline:
> 
> 
> Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitVarying         1632  avgt   15  1.198 ? 0.056  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitVarying         1632  avgt   15  1.195 ? 0.058  ns/op
> 
> 
> StringLatin1.canEncode:
> 
> 
> Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitVarying         1632  avgt   15  1.193 ? 0.055  ns/op
> ``` 
> 
> At this point, I'm starting to wonder a bit if the performance benefits suggested by this PR might be dubious and will only surface in very narrow benchmarks. On the other hand, it does not seem harmful either. What do people think?

@eirbjo I suggest to add `-prof perfasm` and see what's going on; I suspect it's better that inputs are loaded from `@State` field...and don't use `BlackHole` but combine the results of the 2 operations (although I remember that compiler assisted black holes are not as noisy as I'm used to observe with JDK 11 ones)

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 15:13:24 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 15:13:24 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <UCceloyvmZ1dvby1icLQrnz_sbgi0N0EpezMwxHJsF8=.c8f38602-fb02-46ce-a67f-03e6a458e2c9@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
 <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
 <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>
 <F4ZN8YJrZJhFq5rawO3kPNx-CuJpJJ5YivF_PqdBivs=.414d338d-1df2-4848-92f8-e8199d11abab@github.com>
 <YV2aMSmaXODS7XDRN0K_oeWdcAx4KSIik363yfTL8t8=.f70fe081-54de-4bb4-ba4b-add4653f7a7a@github.com>
 <UCceloyvmZ1dvby1icLQrnz_sbgi0N0Epez
 MwxHJsF8=.c8f38602-fb02-46ce-a67f-03e6a458e2c9@github.com>
Message-ID: <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com>

On Wed, 15 Mar 2023 14:57:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> The StringLatin1.canEncode regression disappears.
>> 
>> I mixed things up so StringLatin1.canEncode was benchmarked without the updated code.
>> 
>> Here are updated benchmark results:
>> 
>> 
>> Baseline:
>> 
>> 
>> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigitRandom         1632  avgt   15  5.437 ? 0.235  ns/op
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigitRandom         1632  avgt   15  5.319 ? 0.341  ns/op
>> 
>> 
>> StringLatin1.canEncode:
>> 
>> 
>> Benchmark                 (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigitRandom         1632  avgt   15  5.447 ? 0.304  ns/op
>> ``` 
>> 
>> So it seems using StringLatin1.canEncode still might have a regression also in the randomized input case.
>> 
>> For this PR, I suggest we update StringLatin1.canEncode to be in sync with CharacterData.of, without one calling the other. If anyone wants to investigate the regression further, than can be done outside this PR.
>> 
>> I have independently verified that StringLatin1.canEncode sees performance improvements using the StringIndexOf benchmark.
>
> We can do `Integer.compareUnsigned(ch, 0xFF) <= 0`

We could, but benchmarks show no performance improvements over the current PR. I think the current code is perhaps slightly more readable.

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Wed Mar 15 15:53:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 15:53:49 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <UpbXyyChO19ba1PQZP9qV7Y7cSUO0wbs9lXgmaBsKLE=.cd8a1973-39b2-4ee4-8915-814f9c43746b@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
 <UpbXyyChO19ba1PQZP9qV7Y7cSUO0wbs9lXgmaBsKLE=.cd8a1973-39b2-4ee4-8915-814f9c43746b@github.com>
Message-ID: <kGXVGIsgAIHOZ_DXXbsz1llioBimNflQJ53bN2c3q1k=.665cda98-01b1-4257-959b-383222b78bb3@github.com>

On Wed, 15 Mar 2023 14:56:28 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update StringLatin1.canEncode to sync with same test in CharacterData.of
>
> Just for fun, I tried with a benchmark where the code point is Latin1 in every other call:
> 
> 
> @Benchmark
> public void isDigitVarying(Blackhole blackhole) {
>     blackhole.consume(Character.isDigit(48));
>     blackhole.consume(Character.isDigit(1632));
> }
> 
> 
> With this benchmark, there is no difference between the baseline, the PR and using StringLatin1.canEncode:
> 
> Baseline:
> 
> 
> Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitVarying         1632  avgt   15  1.198 ? 0.056  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitVarying         1632  avgt   15  1.195 ? 0.058  ns/op
> 
> 
> StringLatin1.canEncode:
> 
> 
> Benchmark                  (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigitVarying         1632  avgt   15  1.193 ? 0.055  ns/op
> ``` 
> 
> At this point, I'm starting to wonder a bit if the performance benefits suggested by this PR might be dubious and will only surface in very narrow benchmarks. On the other hand, it does not seem harmful either. What do people think?

> @eirbjo I suggest to add `-prof perfasm` and see what's going on; I suspect it's better that inputs are loaded from `@State` field...and don't use `BlackHole` but combine the results of the 2 operations (although I remember that compiler assisted black holes are not as noisy as I'm used to observe with JDK 11 ones)

I think I'm done with benchmarking for this PR. Any StringLatin1.canEncode method call regression can be solved outside this PR.

The PR as it stands seems to have some benefit for Latin1-only apps/use cases, which I think is not uncommon. Any benefit for mixed?cases are more dubious, but don't seem to hurt.

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

PR: https://git.openjdk.org/jdk/pull/13040

From jjg at openjdk.org  Wed Mar 15 16:08:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 15 Mar 2023 16:08:06 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

make/langtools/tools/compileproperties/CompileProperties.java line 252:

> 250:             try {
> 251:                 writer = new BufferedWriter(
> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));

Using ISO_8859_1 seems strange.
Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.

Or else just stay with ascii; no one should be looking at these files!

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

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Wed Mar 15 16:08:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:03 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native
Message-ID: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>

This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.

In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

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

Commit messages:
 - Write to ASCII
 - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1
 - Compile class with ascii (Not ready to make system wide change)
 - Toggle UTF-8 for javac option in JavaCompilation.gmk
 - CompileProperties converts in UTF-8
 - Convert .properties from ISO-8859-1 to UTF-8

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301991
  Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Wed Mar 15 16:08:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:07 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native
In-Reply-To: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
Message-ID: <_dP9N3UNWa82tfLVEapoSFJjbvMmlyP21ZbuL0NjTDU=.3685af0b-31a0-42aa-86b0-5098bda72766@github.com>

On Tue, 7 Mar 2023 23:15:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> make/langtools/tools/compileproperties/CompileProperties.java line 252:
> 
>> 250:             try {
>> 251:                 writer = new BufferedWriter(
>> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));
> 
> Using ISO_8859_1 seems strange.
> Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.
> 
> Or else just stay with ascii; no one should be looking at these files!

Will stick with your latter solution, as since the .properties files were converted via native2ascii, it makes sense to write out via ascii.

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

PR: https://git.openjdk.org/jdk/pull/12726

From duke at openjdk.org  Wed Mar 15 16:21:33 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 15 Mar 2023 16:21:33 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:

> 1: #

This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

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

PR: https://git.openjdk.org/jdk/pull/12726

From naoto at openjdk.org  Wed Mar 15 18:21:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 18:21:11 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v3]
In-Reply-To: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
Message-ID: <IVkDk8RBYSlfAXG5tdCThMoO7Qb6awdUhkIZdrLT5S0=.89ee1e25-8dc5-4151-968a-8ddec9cb2002@github.com>

> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - InternalError message/mask constants cleanup
 - Indentation/print comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13006/files
  - new: https://git.openjdk.org/jdk/pull/13006/files/0b7b7296..6b4eef94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13006&range=01-02

  Stats: 66 lines in 2 files changed: 36 ins; 9 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/13006.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13006/head:pull/13006

PR: https://git.openjdk.org/jdk/pull/13006

From naoto at openjdk.org  Wed Mar 15 18:23:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 18:23:24 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <JHIYX3d0v-N_NoslQZN2qKDPFnZ8uvcUePZpgAUfHeo=.33c3b60e-b3c3-4191-8d50-427896cb076a@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
 <JHIYX3d0v-N_NoslQZN2qKDPFnZ8uvcUePZpgAUfHeo=.33c3b60e-b3c3-4191-8d50-427896cb076a@github.com>
Message-ID: <5NaAAMFK5xFh97si1SRoq7H4Yu_34y6eieQvfIP_1eg=.c0bc4aab-8178-4eec-993b-078bcf198940@github.com>

On Tue, 14 Mar 2023 20:47:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed method descriptions
>
> make/jdk/src/classes/build/tools/generatecharacter/EmojiData.java line 99:
> 
>> 97:             case "Emoji_Component" -> EMOJI_COMPONENT;
>> 98:             case "Extended_Pictographic" -> EXTENDED_PICTOGRAPHIC;
>> 99:             default -> throw new InternalError();
> 
> It would be useful to include the "type" as the exception argument. It give some idea as to the corruption or missing case.

Added `type` to the error message

> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 214:
> 
>> 212:         maskEmojiModifierBase = 0x020000000000L,
>> 213:         maskEmojiComponent  = 0x040000000000L,
>> 214:         maskExtendedPictographic = 0x080000000000L;
> 
> It would be good to leverage a common definition (perhaps a bit number) here and in EmojiData.java
> and build the constants with <<< shifts.

Good point. I managed to get rid of the constants in `EmojiData` altogether, by using the constants in `GenerateCharacter`. Used the bit numbers to construct constants.

> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 810:
> 
>> 808:         if (x.equals("maskEmojiModifierBase")) return "0x" + hex4(maskEmojiModifierBase >> 32);
>> 809:         if (x.equals("maskEmojiComponent")) return "0x" + hex4(maskEmojiComponent >> 32);
>> 810:         if (x.equals("maskExtendedPictographic")) return "0x" + hex4(maskExtendedPictographic >> 32);
> 
> An upgrade would be to modify hex4(), hexNN() to use `HexFormat.of().toUpperCase().toHexDigits((short)xxx)`
> The HexFormat is reusable and would avoid creating extra strings.
> Perhaps also create a method that combines the repetitive shift and prefixing.
> 
> This if...then... sequence could be an expression switch (x) {...}.

It would be good, but it would be for another day IMO.

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

PR: https://git.openjdk.org/jdk/pull/13006

From naoto at openjdk.org  Wed Mar 15 18:23:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 18:23:26 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v2]
In-Reply-To: <SHzzD8CHU7RTbN9whgro42Hg2cjHs8vlLXzQ2eYgEPM=.a9a6df4c-6855-404e-8df3-889b4f29ec7e@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <NpHpOmh_8uAQLGrQI1iDZHtjU5Si5qW5eLOLXIG2WQs=.8f079024-d8b3-4aef-a266-bfb32dde1ced@github.com>
 <SHzzD8CHU7RTbN9whgro42Hg2cjHs8vlLXzQ2eYgEPM=.a9a6df4c-6855-404e-8df3-889b4f29ec7e@github.com>
Message-ID: <oIxeQlJ_GusZk5wSwN20el7nCm-utjEEYHg30Xljlzk=.22654ff4-9a1c-4bf2-b88b-4f4e574dc3a3@github.com>

On Tue, 14 Mar 2023 17:09:54 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed method descriptions
>
> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 215:
> 
>> 213:         maskEmojiComponent  = 0x040000000000L,
>> 214:         maskExtendedPictographic = 0x080000000000L;
>> 215: 
> 
> Would be nice the have the '=' aligned in the same column as the ones above, or at least have the emoji ones align with each other.

Thanks. Indentation aligned, and although in production `-string` is used so comments are not emitted, added information for `B` table in `GenerateCharacter.propertiesComments` for consistency.

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

PR: https://git.openjdk.org/jdk/pull/13006

From rriggs at openjdk.org  Wed Mar 15 19:07:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Mar 2023 19:07:30 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v3]
In-Reply-To: <IVkDk8RBYSlfAXG5tdCThMoO7Qb6awdUhkIZdrLT5S0=.89ee1e25-8dc5-4151-968a-8ddec9cb2002@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <IVkDk8RBYSlfAXG5tdCThMoO7Qb6awdUhkIZdrLT5S0=.89ee1e25-8dc5-4151-968a-8ddec9cb2002@github.com>
Message-ID: <JB2P3OMhoMDXoVwSZFmk1LqyTCRyVnnJdcWRf9f_V_I=.3886dba4-c1d0-4332-8898-38d78c9f6492@github.com>

On Wed, 15 Mar 2023 18:21:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - InternalError message/mask constants cleanup
>  - Indentation/print comment fix

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/13006

From naoto at openjdk.org  Wed Mar 15 20:02:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 20:02:29 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>

On Tue, 14 Mar 2023 22:16:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Hi Justin,
Thanks for the fix. Still reviewing the changes, but here are some comments I have noticed:

src/java.base/share/classes/java/util/GregorianCalendar.java line 1314:

> 1312:                     // current DAY_OF_WEEK
> 1313:                     if (newWeekOfYear == 1 && isInvalidWeek1()) {
> 1314:                         newWeekOfYear+=1;

is `+1` always correct? Does it work when the amount is negative?

src/java.base/share/classes/java/util/GregorianCalendar.java line 3030:

> 3028:         }
> 3029:     }
> 3030: 

Are these `GregorianCalendar` specific? What about other calendars?

test/jdk/java/util/Calendar/RollToMinWeek.java line 30:

> 28:  * is rolled into a minimal week 1
> 29:  * @run junit RollToMinWeek
> 30:  */

Have you considered adding test cases into `test/jdk/java/util/Calendar/CalendarTestScripts`, instead of creating a single-purpose test case?

test/jdk/java/util/Calendar/RollToMinWeek.java line 79:

> 77:         return Stream.of(
> 78:                 // Test a variety of rolls that previously produced incorrect results
> 79:                 Arguments.of(buildCalendar(27, 11, 2020, Locale.ENGLISH),

The first day of week depends on the region, not the language. In fact, I would prefer explicitly specifying it via a locale like `en-US-u-fw-mon`, and testing all the weekdays.

test/jdk/java/util/Calendar/RollToMinWeek.java line 95:

> 93: 
> 94:     private static Calendar buildCalendar(int day, int month, int year, Locale locale) {
> 95:         Calendar calendar = Calendar.getInstance(locale);

If the fix is `GregorianCalendar` specific, should it check the type?

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

PR: https://git.openjdk.org/jdk/pull/13031

From naoto at openjdk.org  Wed Mar 15 20:23:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 20:23:23 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:

> 154: zh=\u00A4
> 155: zh_CN=\uFFE5
> 156: zh_HK=HK$

Why are they not encoded into UTF-8 native?

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

PR: https://git.openjdk.org/jdk/pull/12726

From duke at openjdk.org  Wed Mar 15 20:46:21 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 15 Mar 2023 20:46:21 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v3]
In-Reply-To: <IVkDk8RBYSlfAXG5tdCThMoO7Qb6awdUhkIZdrLT5S0=.89ee1e25-8dc5-4151-968a-8ddec9cb2002@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <IVkDk8RBYSlfAXG5tdCThMoO7Qb6awdUhkIZdrLT5S0=.89ee1e25-8dc5-4151-968a-8ddec9cb2002@github.com>
Message-ID: <m1x_AfUFYbmNFIiD17pA3nvdHWhT7dZFrNstaL_PV4o=.ba8c3886-7e50-490b-963b-7cd30187da88@github.com>

On Wed, 15 Mar 2023 18:21:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - InternalError message/mask constants cleanup
>  - Indentation/print comment fix

Unrelated side note: Reviewing this PR inspired me to see if one could generate more efficient switch expressions for the CharacterDataLatin1 methods as replacement for the property lookup / masking done today. This seemed to give a small improvements on benchmarks and also collapsed a few methods to simply "return false". Could be something to explore at a later point.

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

PR: https://git.openjdk.org/jdk/pull/13006

From naoto at openjdk.org  Wed Mar 15 21:34:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 21:34:23 GMT
Subject: <i18n dev> RFR: 8303018: Unicode Emoji Properties [v3]
In-Reply-To: <m1x_AfUFYbmNFIiD17pA3nvdHWhT7dZFrNstaL_PV4o=.ba8c3886-7e50-490b-963b-7cd30187da88@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
 <IVkDk8RBYSlfAXG5tdCThMoO7Qb6awdUhkIZdrLT5S0=.89ee1e25-8dc5-4151-968a-8ddec9cb2002@github.com>
 <m1x_AfUFYbmNFIiD17pA3nvdHWhT7dZFrNstaL_PV4o=.ba8c3886-7e50-490b-963b-7cd30187da88@github.com>
Message-ID: <IgMnqiKMD2jxubMba-ayiLE3WVdIijXls0A0uvoU3m4=.2869e706-c11a-4140-846f-8aaa5fa271c5@github.com>

On Wed, 15 Mar 2023 20:43:22 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Unrelated side note: Reviewing this PR inspired me to see if one could generate more efficient switch expressions for the CharacterDataLatin1 methods as replacement for the property lookup / masking done today. This seemed to give a small improvements on benchmarks and also collapsed a few methods to simply "return false". Could be something to explore at a later point.

Yeah, agree. `Latin1` can be (should be?) fast-path'ed as always.

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

PR: https://git.openjdk.org/jdk/pull/13006

From serb at openjdk.org  Wed Mar 15 21:48:20 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 15 Mar 2023 21:48:20 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <QawnrKyexkcL7jnBTj_d8ObEy80D_waacyWzfQwad-U=.59f093dd-8f4b-4048-aa73-6d9fcbe53925@github.com>

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

improving synchronization will make the same effect as using the double-buffer for this translucent windows, but probably adding the  double-buffer is simpler to implement. You can also check how the "swing.bufferPerWindow" property is implemented, we can try to improve it for this issue and set by default.

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

PR: https://git.openjdk.org/jdk/pull/12993

From jlaskey at openjdk.org  Thu Mar 16 12:07:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 16 Mar 2023 12:07:57 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v45]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <sh500oB5itOA9tw-xJ8Nc8TwUJevtYbTjkieBnPeaLs=.744931f5-a5a6-4dfb-ba37-77f613ac1d24@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - Merge branch 'master' into 8285932
 - Correction
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Javadoc corrections and bug fix for StringTemplate::combine
 - Tighten up reporting of string template errors (fewer messages)
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - ... and 52 more: https://git.openjdk.org/jdk/compare/7277bb19...d6947fd4

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=44
  Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From serb at openjdk.org  Thu Mar 16 17:30:31 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Mar 2023 17:30:31 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <Wg4HVPOAc3ZjBhMqq9RuaWARtb525Bh5CZzMdSrmaes=.4cff97b6-3698-46f5-aa22-fd83a0e83e9f@github.com>

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

For the possible "synchronization" change, note that on macOS the rendering to the Window is always done via backbuffer which then blits to the CALayer. We can try to delay the blit until the window is fully rendered.

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

PR: https://git.openjdk.org/jdk/pull/12993

From jlu at openjdk.org  Thu Mar 16 18:19:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:19:29 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v2]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with four additional commits since the last revision:

 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/1e798f24..6d6bffe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00-01

  Stats: 92 lines in 4 files changed: 0 ins; 0 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:21:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:40 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v2]
In-Reply-To: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
Message-ID: <CRTgRmg-NKyRb1XyeIcUdbz-JgoZE9nUJ6hBHsRIvLk=.c4614e2d-ec44-40fa-a88d-41c2b94b12bb@github.com>

On Thu, 16 Mar 2023 18:19:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

Conversion did not work as expected, addressing right now.

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

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:21:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:43 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v2]
In-Reply-To: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
Message-ID: <Pns4G-crmY2QuscU_BkwBA2hXFMN3VQMdzc-UWVKPDU=.d20ab56a-ca0f-45aa-9a2d-361b532281ed@github.com>

On Wed, 15 Mar 2023 20:19:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:
> 
>> 154: zh=\u00A4
>> 155: zh_CN=\uFFE5
>> 156: zh_HK=HK$
> 
> Why are they not encoded into UTF-8 native?

Not sure, thank you for catching it. Working on it right now.

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

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:21:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:46 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v2]
In-Reply-To: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
Message-ID: <_6WBGo5CQBseDEjMv16qCWmodFlYOO4gsT9WbON7ddA=.f94339a4-8893-47e4-8bb1-f28a8807ad9d@github.com>

On Wed, 15 Mar 2023 16:18:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:
> 
>> 1: #
> 
> This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

Thank you, removed the changes for this file

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

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:35:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:51 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v3]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/6d6bffe8..7119830b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01-02

  Stats: 87 lines in 1 file changed: 0 ins; 0 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:35:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:54 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v3]
In-Reply-To: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
Message-ID: <XFZBHgkji9zthsA9wOP-bDqbf7PTVoKJzNXHDR1pThQ=.a99810cd-d764-40ee-9699-b234d6583007@github.com>

On Thu, 16 Mar 2023 18:31:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

CurrencySymbols.properties is fully converted to UTF-8 now

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

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:44:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:44:29 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR
In-Reply-To: <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
Message-ID: <YYOUlxBCv3qf1JOsy4YhJpaDXCcYzEtMF0GTHi-dzQo=.50b80634-b58d-4ae5-b161-1d6f75be0a27@github.com>

On Wed, 15 Mar 2023 19:53:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> test/jdk/java/util/Calendar/RollToMinWeek.java line 30:
> 
>> 28:  * is rolled into a minimal week 1
>> 29:  * @run junit RollToMinWeek
>> 30:  */
> 
> Have you considered adding test cases into `test/jdk/java/util/Calendar/CalendarTestScripts`, instead of creating a single-purpose test case?

Will take a look at the existing .cts files and see if it would be advantageous to add test cases there

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

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Thu Mar 16 18:48:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:48:23 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR
In-Reply-To: <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
Message-ID: <8YW1fWa2eJf9MrcWzgQWke7pvgREQSkoFD8r1ojRPk4=.95bdb334-114c-432c-950f-ba46241c4950@github.com>

On Wed, 15 Mar 2023 19:50:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 3030:
> 
>> 3028:         }
>> 3029:     }
>> 3030: 
> 
> Are these `GregorianCalendar` specific? What about other calendars?

Good point, these are _probably_ applicable to the other calendars, will take another look there.

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

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Fri Mar 17 19:19:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 19:19:30 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <b_8MpwmVPifrKzQaA67T_HTBXbQCGpos2opCtTibPZY=.d2604f26-8f94-4fa3-bdaa-3a2f026d390c@github.com>

On Tue, 14 Mar 2023 22:16:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Although this issue applies to Gregorian Calendar, it appears it may also occur with a Japanese Calendar under the right circumstances.

`{$$$ Failed: Rolled: "Sunday, 29 December 1" by 1 week, expecting: "Sunday, 5 May 1", but got: "Saturday, 5 January 31"}`

The Reiwa era begins on May 1st, 2019. Rolling the last Sunday of 2019 by 1 week, one would expect the resultant date to be the first Sunday of the Reiwai period (the 5th of May, 2019). However, a completely wrong date is returned, and the calendar actually rolls back an era into Heisei. 

Looking into it further, as well as the other calendars

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

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Fri Mar 17 20:28:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 20:28:13 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v4]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust CF test to read in with UTF-8 to fix failing test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/7119830b..007c78a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12726

From angorya at openjdk.org  Fri Mar 17 20:34:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 17 Mar 2023 20:34:00 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:

> 224:         Properties p = new Properties();
> 225:         try {
> 226:             FileInputStream input = new FileInputStream(propertiesPath);

Should this stream be closed in a finally { } block?

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

PR: https://git.openjdk.org/jdk/pull/12726

From naoto at openjdk.org  Fri Mar 17 21:05:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Mar 2023 21:05:18 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v4]
In-Reply-To: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
Message-ID: <qJO-EntPnPd5u6rdRknlaAFlfED0JHmr5CXahe0N4oY=.fae98578-e8b4-4387-bd72-acf3cf871a40@github.com>

On Fri, 17 Mar 2023 20:31:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:
> 
>> 224:         Properties p = new Properties();
>> 225:         try {
>> 226:             FileInputStream input = new FileInputStream(propertiesPath);
> 
> Should this stream be closed in a finally { } block?

or better be `try-with-resources`?

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

PR: https://git.openjdk.org/jdk/pull/12726

From weijun at openjdk.org  Fri Mar 17 21:52:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:52:23 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:

> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
> 326:                         outBuffer.append(toHex(aChar & 0xF));

Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

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

PR: https://git.openjdk.org/jdk/pull/12726

From weijun at openjdk.org  Fri Mar 17 21:56:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:56:23 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v4]
In-Reply-To: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
Message-ID: <whhHbwzCZGIvBavtXFqc5Ari9SWIQg-BwdyP3t89Rcg=.d8dc3f56-857d-4265-a54d-9fdb5a59c96a@github.com>

On Fri, 17 Mar 2023 21:49:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:
> 
>> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
>> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
>> 326:                         outBuffer.append(toHex(aChar & 0xF));
> 
> Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

I probably understand it now, source code still needs escaping. When can we put in UTF-8 there as well?

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

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Fri Mar 17 22:27:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 22:27:48 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v5]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Close streams when finished loading into props

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/007c78a7..19b91e6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03-04

  Stats: 15 lines in 3 files changed: 6 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From duke at openjdk.org  Sat Mar 18 17:09:23 2023
From: duke at openjdk.org (jmehrens)
Date: Sat, 18 Mar 2023 17:09:23 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
 <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
 <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>
 <F4ZN8YJrZJhFq5rawO3kPNx-CuJpJJ5YivF_PqdBivs=.414d338d-1df2-4848-92f8-e8199d11abab@github.com>
 <YV2aMSmaXODS7XDRN0K_oeWdcAx4KSIik363yfTL8t8=.f70fe081-54de-4bb4-ba4b-add4653f7a7a@github.com>
 <UCceloyvmZ1dvby1icLQrnz_sbgi0N0Epez
 MwxHJsF8=.c8f38602-fb02-46ce-a67f-03e6a458e2c9@github.com>
 <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com>
Message-ID: <OVowCP2FZaELBakSarf0pTYxqpp3FfOUdW3t6FJfpKo=.ed9cf126-28cc-41ce-bd01-9c99e7442e8e@github.com>

On Wed, 15 Mar 2023 15:10:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> We can do `Integer.compareUnsigned(ch, 0xFF) <= 0`
>
> We could, but benchmarks show no performance improvements over the current PR. I think the current code is perhaps slightly more readable.

Does non-short-circuit logical AND operator perform similar to baseline?  In this very specific case there is no risk of side effects due to method calls, no risk of null pointer exception because of primitives, and there is not an excessive amount of conditions.  Therefore, I would think either `&` or `&&` are viable options.

`if (ch >= 0 & ch <= 0xFF) {`

I ask just for the sake of my own learning on this topic as it relates to performance as opposed to code readability preferences.

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

PR: https://git.openjdk.org/jdk/pull/13040

From duke at openjdk.org  Sat Mar 18 17:48:20 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 18 Mar 2023 17:48:20 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <OVowCP2FZaELBakSarf0pTYxqpp3FfOUdW3t6FJfpKo=.ed9cf126-28cc-41ce-bd01-9c99e7442e8e@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <48pbcrbZmBQO6J80QbsguXOnjkWpcvYAHoJeuRJkJxM=.8c5a9e01-2793-4161-9dab-dee7a1b95d52@github.com>
 <ancjyjuePD0EGOUrQ_3HtnvR_uB4nYqYYKJ5nKBEEKc=.bd47c84e-ceca-4c56-8837-dd5aef4507fa@github.com>
 <MXl73seJ21P3l2YcqKFLZ9euqhY6LOW3hC8QAesGkKc=.fc246710-6c05-40ba-ad07-a698c23cfff5@github.com>
 <xnRicG2dkURtg2D92ILJ696CsVZxbnsA32Qan4WTrgg=.d24001f6-76d6-45a9-86fa-f9aed1e9852c@github.com>
 <-G0bjp7QOP42BCRs1n2G6mxJSExj76GroacBjkQoWuo=.05e993a5-f012-4c6b-8c49-4c74d8e35b39@github.com>
 <B3HKDxbj7SWbGFrjAopQSXmAWYYL1WU3ymslT4uA3_o=.f87bae55-d718-4e42-96f6-7afe446a4402@github.com>
 <1jnPSPh1W0Lme04llPDlejKeFmNOH2eL5fNmyUgN_Ns=.b4021466-157a-49ab-bd08-71c0ec9312dd@github.com>
 <F4ZN8YJrZJhFq5rawO3kPNx-CuJpJJ5YivF_PqdBivs=.414d338d-1df2-4848-92f8-e8199d11abab@github.com>
 <YV2aMSmaXODS7XDRN0K_oeWdcAx4KSIik363yfTL8t8=.f70fe081-54de-4bb4-ba4b-add4653f7a7a@github.com>
 <UCceloyvmZ1dvby1icLQrnz_sbgi0N0Epez
 MwxHJsF8=.c8f38602-fb02-46ce-a67f-03e6a458e2c9@github.com>
 <4m6unzqJyeoeWDRGNSMXOZq9ysa1JfUldlHhrXz5xTY=.58f68d2c-4ab2-4357-aa83-3c88e7a8ba0f@github.com>
 <OVowCP2FZaELBakSarf0pTYxqpp3FfOUdW3t6FJfpKo=.ed9cf126-28cc-41ce-bd01-9c99e7442e8e@github.com>
Message-ID: <aIvFD53PL8vFsGb4kuot0F1rvmCY7waESfefHR5GJFE=.2514bafa-08c1-4e54-8e01-5442dd04e263@github.com>

On Sat, 18 Mar 2023 17:06:52 GMT, jmehrens <duke at openjdk.org> wrote:

>> We could, but benchmarks show no performance improvements over the current PR. I think the current code is perhaps slightly more readable.
>
> Does non-short-circuit logical AND operator perform similar to baseline?  In this very specific case there is no risk of side effects due to method calls, no risk of null pointer exception because of primitives, and there is not an excessive amount of conditions.  Therefore, I would think either `&` or `&&` are viable options.
> 
> `if (ch >= 0 & ch <= 0xFF) {`
> 
> I ask just for the sake of my own learning on this topic as it relates to performance as opposed to code readability preferences.

Both choices of operators en up with identical generated code on my Intel Mac.

For reference, I did a comparison between the generated code for the current code, and the one in this PR:

Current generated code start like this:


movl		%eax, -0x14000(%rsp)
pushq		%rbp
subq		$0x20, %rsp
cmpl		$1, 0x20(%r15)
jne		0x119cae072
movl		%esi, %r11d
shrl		$8, %r11d
testl		%r11d, %r11d
jne		0x119cae043
movabsq		$0x70fe03c90, %rax  ;   {oop(a 'java/lang/CharacterDataLatin1'{0x000000070fe03c90})}
``` 

While the PR generated code starts like this:


movl		%eax, -0x14000(%rsp)
pushq		%rbp
subq		$0x20, %rsp
cmpl		$1, 0x20(%r15)
jne		0x1171d41f2
nopw		(%rax, %rax)
cmpl		$0x100, %esi
jae		0x1171d41c5
movabsq		$0x70fe03c90, %rax  ;   {oop(a 'java/lang/CharacterDataLatin1'{0x000000070fe03c90})}


The rest of the code seems identical.

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

PR: https://git.openjdk.org/jdk/pull/13040

From pminborg at openjdk.org  Mon Mar 20 18:02:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Mar 2023 18:02:00 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <XDzMG-6ZuW8YFqBg193Boy8O5HlyA29hRiQUJ9BdG1g=.f5d08f76-f611-40cf-ad9f-e28c03a12b27@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/12346#issuecomment-1476693257

From liach at openjdk.org  Mon Mar 20 18:21:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 Mar 2023 18:21:10 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

src/java.base/share/classes/java/time/ZoneOffset.java line 430:

> 428:     public static ZoneOffset ofTotalSeconds(int totalSeconds) {
> 429:         final class Holder {
> 430:             private static final IntFunction<ZoneOffset> ZONE_OFFSET_MAPPER = new ZoneOffsetMapper();

Can't the ZoneOffsetMapper itself serve as a holder class? so we move this singleton into ZoneOffsetMapper itself.

test/jdk/jdk/internal/util/LazyReferenceArray/BasicLazyReferenceArrayTest.java line 107:

> 105: 
> 106:     private static IntFunction<Integer> intIdentity() {
> 107:         return i -> i;

Can't this be `Integer::valueOf`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142516460
PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142520869

From naoto at openjdk.org  Mon Mar 20 20:23:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 20 Mar 2023 20:23:54 GMT
Subject: <i18n dev> Integrated: 8303018: Unicode Emoji Properties
In-Reply-To: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
References: <pdvBhMZbItLCDhLI-bhO-Is7vzR46l2yPhhDLV9RAyE=.799977a8-6475-4e76-ae1f-af7fc90e4d0a@github.com>
Message-ID: <1QVsE5ZlGTvk2JJt5nw7pj_hb2gAJXbSZu1y4kUyMOQ=.888c5fee-b445-4b93-8027-c135818a1377@github.com>

On Mon, 13 Mar 2023 21:16:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing accessor methods to Emoji properties defined in [Unicode Technical Standard #51](https://unicode.org/reports/tr51/) in `java.lang.Character` class. This is per a request from the client group, as well as refining the currently existing ad-hoc emoji implementation in regex. A CSR has also been drafted, and I would appreciate reviews for it too.

This pull request has now been integrated.

Changeset: f593a6b5
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f593a6b52ee7161f7d63bfaf04062551c1281e61
Stats:     897 lines in 19 files changed: 619 ins; 254 del; 24 mod

8303018: Unicode Emoji Properties

Reviewed-by: prr, erikj, rriggs

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

PR: https://git.openjdk.org/jdk/pull/13006

From jlaskey at openjdk.org  Mon Mar 20 20:31:46 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 20 Mar 2023 20:31:46 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Tidy javadoc
 - Rename StringTemplate classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/d6947fd4..9ba6400d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=44-45

  Stats: 2086 lines in 54 files changed: 874 ins; 1075 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Tue Mar 21 05:10:24 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 05:10:24 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v2]
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <uoYx4ezFPO7blLX4iIQHSINsj8ieWLTmhpiOuzGl5PM=.4bf705c0-b411-4d44-ae69-9a7e93d1c686@github.com>

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

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

  8303950: approaching using double-buffer approach instead
  
  The PaintManager explicitly states that its for Swing components. This pulls some logic out of PaintManager that can be applied to generic awt.Components and introduces the AWTPaintManager super class.
  
  The broad goal here is to take advantage of double-buffering AND avoid copying and pasting the hard work that the PaintManager already took care (regarding tiling, scaling, and looping attempts to use VolatileImages).
  
  This is response to ongoing PR discussions; see https://github.com/openjdk/jdk/pull/12993#issuecomment-1470887449

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/6594b548..6a3a9b42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=00-01

  Stats: 206 lines in 3 files changed: 81 ins; 98 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/12993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12993/head:pull/12993

PR: https://git.openjdk.org/jdk/pull/12993

From pminborg at openjdk.org  Tue Mar 21 07:32:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 07:32:48 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
 <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>
Message-ID: <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>

On Mon, 20 Mar 2023 18:12:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unused setup method
>>  - Rename method in test
>>  - Add copyright header
>
> src/java.base/share/classes/java/time/ZoneOffset.java line 430:
> 
>> 428:     public static ZoneOffset ofTotalSeconds(int totalSeconds) {
>> 429:         final class Holder {
>> 430:             private static final IntFunction<ZoneOffset> ZONE_OFFSET_MAPPER = new ZoneOffsetMapper();
> 
> Can't the ZoneOffsetMapper itself serve as a holder class? so we move this singleton into ZoneOffsetMapper itself.

It is possible but this keeps the mapper more local and only accessible where it is supposed to be used. For testing purposed, it might be better to have the class as you propose.

> test/jdk/jdk/internal/util/LazyReferenceArray/BasicLazyReferenceArrayTest.java line 107:
> 
>> 105: 
>> 106:     private static IntFunction<Integer> intIdentity() {
>> 107:         return i -> i;
> 
> Can't this be `Integer::valueOf`?

It can. I think either works fine. Maybe a bit nicer with a method reference as you propose.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142972042
PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142973744

From pminborg at openjdk.org  Tue Mar 21 07:32:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 21 Mar 2023 07:32:49 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
 <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>
 <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>
Message-ID: <Ux_TooVmT3Ob25TYUHZAvpgNLmI6-kZecfSPakCyiZM=.ee503fbb-c892-432a-aa86-01847add462a@github.com>

On Tue, 21 Mar 2023 07:27:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> test/jdk/jdk/internal/util/LazyReferenceArray/BasicLazyReferenceArrayTest.java line 107:
>> 
>>> 105: 
>>> 106:     private static IntFunction<Integer> intIdentity() {
>>> 107:         return i -> i;
>> 
>> Can't this be `Integer::valueOf`?
>
> It can. I think either works fine. Maybe a bit nicer with a method reference as you propose.

Perhaps you mean the method could be *replaced* with `Integer::valueOf"? Good suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1142974996

From liach at openjdk.org  Tue Mar 21 13:57:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 13:57:24 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
 <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>
 <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>
Message-ID: <bCgmNILETnu3TOKZKH9QsSMYuyFI2r-LWE_SNp8Fj2Y=.4d32285a-cf0b-43b7-b6a7-2c002a2792ee@github.com>

On Tue, 21 Mar 2023 07:25:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/ZoneOffset.java line 430:
>> 
>>> 428:     public static ZoneOffset ofTotalSeconds(int totalSeconds) {
>>> 429:         final class Holder {
>>> 430:             private static final IntFunction<ZoneOffset> ZONE_OFFSET_MAPPER = new ZoneOffsetMapper();
>> 
>> Can't the ZoneOffsetMapper itself serve as a holder class? so we move this singleton into ZoneOffsetMapper itself.
>
> It is possible but this keeps the mapper more local and only accessible where it is supposed to be used. For testing purposed, it might be better to have the class as you propose.

If we want it local, I suppose we can convert the whole `ZoneOffsetMapper` local with this singleton in `ofTotalSeconds` static method as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1143415419

From liach at openjdk.org  Tue Mar 21 13:57:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Mar 2023 13:57:26 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <Ux_TooVmT3Ob25TYUHZAvpgNLmI6-kZecfSPakCyiZM=.ee503fbb-c892-432a-aa86-01847add462a@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
 <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>
 <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>
 <Ux_TooVmT3Ob25TYUHZAvpgNLmI6-kZecfSPakCyiZM=.ee503fbb-c892-432a-aa86-01847add462a@github.com>
Message-ID: <KqUxWOQXOCrfzRDAnqTZ_7B0bLtsifIzR_LMhH2z4T4=.f95fa862-bcd9-46b1-9f5e-67095b2b4e07@github.com>

On Tue, 21 Mar 2023 07:29:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> It can. I think either works fine. Maybe a bit nicer with a method reference as you propose.
>
> Perhaps you mean the method could be *replaced* with `Integer::valueOf"? Good suggestion.

Yes, `Integer::valueOf` is a better replacement of individual `intIdentity` calls. Thought you may want this method so only one lambda callsite would be generated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1143417225

From duke at openjdk.org  Tue Mar 21 14:22:41 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 14:22:41 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v3]
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <A6aNwRTP9dYQNFRTY-PvMNvyTjcFsC70o8Yodis0ulk=.dc50dee9-3fbf-4e26-97c4-fda0ad8a1a36@github.com>

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

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

  8303950: addressing artifacts observed in RepaintManagerFPUIScaleTest
  
  When I resized the window in the RepaintManagerFPUIScaleTest: I saw lots of random patches of misplaced pixels.
  
  I assume this is because the RepaintManager could now call AWTPaintManager#paint(..) recursively, which means each invocation could grab the cached VolatileImage returned by getVolatileOffscreenBuffer. As a test: I tried making getVolatileOffscreenBuffer always return a new image, and that resolved the artifacts.
  
  This change avoids the recursion with a new helper method. This logic is similar to checking JComponent#getFlag(ANCESTOR_USING_BUFFER) , except that can't help identify recursion when the outermost call is coming from a Component like a Window.
  
  To my knowledge this recursion can only ever happen when the outermost call is a non-Swing component and the innermost call is a Swing component. (And there should only ever be one layer of recursion.)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/6a3a9b42..960fd176

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=01-02

  Stats: 70 lines in 2 files changed: 35 ins; 10 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/12993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12993/head:pull/12993

PR: https://git.openjdk.org/jdk/pull/12993

From mcimadamore at openjdk.org  Tue Mar 21 14:55:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:32 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

I like the new naming scheme!

src/java.base/share/classes/java/lang/StringTemplate.java line 28:

> 26: package java.lang;
> 27: 
> 28: import java.lang.Object;

You might want to do another pass to check for unused imports

src/java.base/share/classes/java/lang/StringTemplate.java line 44:

> 42:  * {@link StringTemplate} is the run-time representation of a string template or
> 43:  * text block template in a template expression.
> 44:  *

Extra newline?

src/java.base/share/classes/java/lang/StringTemplate.java line 56:

> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
> 56:  * first produces an instance of {@link StringTemplate}, representing the template

The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

src/java.base/share/classes/java/lang/StringTemplate.java line 69:

> 67:  * List<Object> values = st.values();
> 68:  * }
> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},

This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

src/java.base/share/classes/java/lang/StringTemplate.java line 324:

> 322:      * assert Objects.equals(sc, "abcxyz");
> 323:      * }
> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first

I was playing with this example in jshell:

jshell> var st1 = RAW."{1}"
st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }

jshell> var st2 = RAW."{2}"
st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }

jshell> StringTemplate.combine(st1, st2);
$7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }


The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:

Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next

I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

src/java.base/share/classes/java/lang/StringTemplate.java line 431:

> 429:      * Java compilation unit.<p>The result of interpolation is not interned.
> 430:      */
> 431:     static final StringProcessor STR = StringTemplate::interpolate;

`static final` is redundant here (we are in an interface)

src/java.base/share/classes/java/lang/StringTemplate.java line 454:

> 452:      * This interface describes the methods provided by a generalized string template processor. The
> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.

nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 47:

> 45:  */
> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 47: interface ReferenceKey<T> {

This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:

> 224:                         List.nil(), expressions);
> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,

nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:

> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
> 251:             }
> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,

What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:

> 279:             make.at(tree.pos);
> 280: 
> 281:             if (processor == null || isNamedProcessor(names.RAW)) {

is `processor == null` still a thing?

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1350457321
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143370713
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143371242
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143373826
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143379210
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143441733
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143444292
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143448931
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143484050
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143501675
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143507003
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143487363

From mcimadamore at openjdk.org  Tue Mar 21 14:55:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:33 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
Message-ID: <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>

On Tue, 21 Mar 2023 13:31:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
> 
>> 67:  * List<Object> values = st.values();
>> 68:  * }
>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
> 
> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143387999

From duke at openjdk.org  Tue Mar 21 21:07:42 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 21:07:42 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v4]
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

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

  8303950: adding unit test for legacy window behavior
  
  This test passes in the current JDK. The test criteria don't really reflect a rational expected behavior; they just reflect the current status quo.
  
  This currently fails in this JDK-8303950 branch (using the new proposed AWTPaintManager), which indicates we've changed behavior.
  
  In this case it's "window 4" that's failing. We used to get a mostly blue background, and now we're getting a background that's mostly red with a little blue. This isn't necessarily a bad thing; this failure is just documenting a change.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/960fd176..bd81761a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12993&range=02-03

  Stats: 131 lines in 1 file changed: 131 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12993.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12993/head:pull/12993

PR: https://git.openjdk.org/jdk/pull/12993

From duke at openjdk.org  Tue Mar 21 21:23:44 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 21 Mar 2023 21:23:44 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint
In-Reply-To: <Wg4HVPOAc3ZjBhMqq9RuaWARtb525Bh5CZzMdSrmaes=.4cff97b6-3698-46f5-aa22-fd83a0e83e9f@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <Wg4HVPOAc3ZjBhMqq9RuaWARtb525Bh5CZzMdSrmaes=.4cff97b6-3698-46f5-aa22-fd83a0e83e9f@github.com>
Message-ID: <yPTiEKMzBAmQTIs4WKj_9PNyvqajL__eWdZYTwu1rdw=.dc7e42dc-72ec-48f0-9ceb-baee2ff61926@github.com>

On Thu, 16 Mar 2023 17:27:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
>> 
>> In short:
>> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
>> 
>> I left more detailed notes here about the proposed resolution:
>> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
>> 
>> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?
>
> For the possible "synchronization" change, note that on macOS the rendering to the Window is always done via backbuffer which then blits to the CALayer. We can try to delay the blit until the window is fully rendered.

@mrserb I pushed some updates that I think approach this as you recommended.

However:
How about instead I replace this branch with this approach: https://github.com/openjdk/jdk/compare/master...mickleness:jdk:JDK-8303950-alt-3?expand=1

In both branches I also added a new test case `bug8303950_legacyWindowPaintBehavior`. This test documents a combination of 4 peculiar cases regarding window/rootpane backgrounds. This is packaged as a unit test just so we can identify when a behavior changes. So if it "fails" that really just means "something changed." It doesn't always mean "that change is bad."

In this branch `bug8303950_legacyWindowPaintBehavior` fails, because now the JRootPane's background paints on top of the Window's background.

In the `JDK-8303950-alt-3` branch (see above link) the `bug8303950_legacyWindowPaintBehavior` test passes, which means the behavior doesn't change.

At your convenience please let me know your thoughts. (And obviously I'd love to hear from Alan and anyone else who wants to chime in too.)

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

PR Comment: https://git.openjdk.org/jdk/pull/12993#issuecomment-1478595645

From jlaskey at openjdk.org  Wed Mar 22 14:43:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
 <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>
Message-ID: <xPCBJE3YSx1AVxj2eP5Z0-mbJxz40uiXK2kfbn-VOQU=.2ed3ed2e-3bbb-44c0-8a80-897c50729a66@github.com>

On Tue, 21 Mar 2023 13:37:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
>> 
>>> 67:  * List<Object> values = st.values();
>>> 68:  * }
>>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
>> 
>> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.
>
> The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

* {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
 * which includes the empty first and last fragments. {@code values} will be the
 * equivalent of {@code List.of(10, 20, 30)}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144904923

From jlaskey at openjdk.org  Wed Mar 22 14:43:43 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:43 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
Message-ID: <juvO66YNEB-H7csE6Nz1LSPCTeCs9MfH2t6ICg9FDJs=.7b639e70-729e-4ce2-8d1b-54e2e1d98aa3@github.com>

On Tue, 21 Mar 2023 13:25:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 28:
> 
>> 26: package java.lang;
>> 27: 
>> 28: import java.lang.Object;
> 
> You might want to do another pass to check for unused imports

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 44:
> 
>> 42:  * {@link StringTemplate} is the run-time representation of a string template or
>> 43:  * text block template in a template expression.
>> 44:  *
> 
> Extra newline?

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 56:
> 
>> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
>> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
>> 56:  * first produces an instance of {@link StringTemplate}, representing the template
> 
> The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

"representing the right hand side of the template expression"

> src/java.base/share/classes/java/lang/StringTemplate.java line 324:
> 
>> 322:      * assert Objects.equals(sc, "abcxyz");
>> 323:      * }
>> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first
> 
> I was playing with this example in jshell:
> 
> jshell> var st1 = RAW."{1}"
> st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }
> 
> jshell> var st2 = RAW."{2}"
> st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }
> 
> jshell> StringTemplate.combine(st1, st2);
> $7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }
> 
> 
> The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:
> 
> Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next
> 
> I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

okay

> src/java.base/share/classes/java/lang/StringTemplate.java line 431:
> 
>> 429:      * Java compilation unit.<p>The result of interpolation is not interned.
>> 430:      */
>> 431:     static final StringProcessor STR = StringTemplate::interpolate;
> 
> `static final` is redundant here (we are in an interface)

Did not know that.

> src/java.base/share/classes/java/lang/StringTemplate.java line 454:
> 
>> 452:      * This interface describes the methods provided by a generalized string template processor. The
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 
> nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

works for me

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 47:
> 
>> 45:  */
>> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 47: interface ReferenceKey<T> {
> 
> This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

Informative incase some one wants to use elsewhere in the JDK. My plan is to move this class to java.util at some point.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:
> 
>> 224:                         List.nil(), expressions);
>> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
>> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,
> 
> nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

Tracks well in javah

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:
> 
>> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
>> 251:             }
>> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,
> 
> What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

Criteria in isLinkageProcessor() prevents this from being called.


        boolean isLinkageProcessor() {
            return processor != null &&
                   !useValuesList &&  <=====
                   types.isSubtype(processor.type, syms.linkageType) &&
                   processor.type.isFinal() &&
                   TreeInfo.symbol(processor) instanceof VarSymbol varSymbol &&
                   varSymbol.isStatic() &&
                   varSymbol.isFinal();
        }

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:
> 
>> 279:             make.at(tree.pos);
>> 280: 
>> 281:             if (processor == null || isNamedProcessor(names.RAW)) {
> 
> is `processor == null` still a thing?

I deliberately left this to track free standing templates. Will be phased out in next preview/final.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144898843
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144899315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144902350
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144907969
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144911867
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144916768
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144915315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144920121
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144924240
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144918724

From liach at openjdk.org  Thu Mar 23 01:52:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:31 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

src/java.base/share/classes/java/lang/StringTemplate.java line 449:

> 447:      * statically imported explicitly.
> 448:      */
> 449:     static final SimpleProcessor<StringTemplate> RAW = st -> st;

Should we omit the modifiers `static final`, which are implicit for all interface fields?

src/java.base/share/classes/java/lang/StringTemplate.java line 455:

> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 455:      *

Paragraph break intended here?

src/java.base/share/classes/java/lang/StringTemplate.java line 550:

> 548:      * SimpleProcessor<JSONObject> jsonProcessor = st -> new JSONObject(st.interpolate());
> 549:      * }
> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}

Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

src/java.base/share/classes/java/lang/StringTemplate.java line 592:

> 590:          */
> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 592:         public sealed interface Linkage permits FormatProcessor {

I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

src/java.base/share/classes/java/lang/StringTemplate.java line 679:

> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 678:     @FunctionalInterface
> 679:     public interface StringProcessor extends SimpleProcessor<String> {

Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:

static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}

which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:

> 1049:      * @param ptypes    list of expression types
> 1050:      *
> 1051:      * @return {@link MethodHandle}

Suggestion:

     * @return the {@link MethodHandle} for concatenation

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:

> 1167:      * have an extra {@link String} slot for the result from the previous
> 1168:      * {@link MethodHandle}.
> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}

Suggestion:

     * {@link #makeConcatWithTemplate}

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1246:

> 1244:      * This method creates a {@link MethodHandle} expecting one input, the
> 1245:      * receiver of the supplied getters. This method uses
> 1246:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplateCluster}

Suggestion:

     * {@link #makeConcatWithTemplateCluster}

src/java.base/share/classes/java/lang/runtime/Carriers.java line 370:

> 368:          */
> 369:         private static Map<MethodType, CarrierElements>
> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());

Suggestion:

                methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

src/java.base/share/classes/java/lang/runtime/Carriers.java line 421:

> 419:          */
> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
> 421:             this.primitives = createPrimitivesArray(primitiveCount );

Suggestion:

            this.primitives = createPrimitivesArray(primitiveCount);

src/java.base/share/classes/java/lang/runtime/Carriers.java line 776:

> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
> 775:          */
> 776:         static CarrierElements of(Class < ? >...ptypes) {

Suggestion:

        static CarrierElements of(Class<?>... ptypes) {

src/java.base/share/classes/java/lang/runtime/Carriers.java line 824:

> 822:         private CarrierElements() {
> 823:             throw new AssertionError("private constructor");
> 824:         }

Suggestion:

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 49:

> 47: interface ReferenceKey<T> {
> 48:     /**
> 49:      * {@return the value of the unwrapped key.}

Suggestion:

     * {@return the value of the unwrapped key}

Inline return tag generates a period already.

src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:

> 125:     @SuppressWarnings("unchecked")
> 126:     static <K, V> ReferencedKeyMap<K, V>
> 127:     create(boolean isSoft, Supplier<Map<?, ?>> supplier) {

What prevents this to take `Supplier<Map<ReferencedKey<K>, V>>`? Same for below.

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 40:

> 38:  * <p>
> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
> 40:  * and sharing of value shapes without creating a new class for each shape.

Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 65:

> 63:      * {@link java.lang.invoke.CallSite CallSite}.
> 64:      */
> 65:     private final MethodHandle valuesMH;

I don't think `java.lang.runtime` is a package where final fields are [trusted](https://github.com/openjdk/jdk/blob/91f407d6fe285c44bcc25c1acdf5dc0c43be0172/src/hotspot/share/ci/ciField.cpp#L226), so these method handles might have a performance overhead. However, records appear to be optimized and eligible for inlining.

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 88:

> 86:      *
> 87:      * @param fragments  string template fragments
> 88:      * @param type       method type

Suggestion:

     * @param type method type accepting values' types and returning a StringTemplate

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 169:

> 167:      * @return StringTemplate composed from fragments and values
> 168:      */
> 169:     static StringTemplate newStringTemplate(List<String> fragments, Object[] values) {

I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:

> 202:             Object[] values
> 203:     ) throws Throwable {
> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));

Suggestion:

        List<Object> asList = List.of(values);

For defensive copy.
Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 233:

> 231:      */
> 232:     private static StringTemplate fromArrays(String[] fragments, Object[] values) {
> 233:         return StringTemplateImplFactory.newStringTemplate(fragments, values);

Should perform defensive copying for the input arrays, specifically `values` (fragments is passed to `List.of`, which is already safe)

In addition, I recommend renaming methods that don't perform defensive copies to like `ofTrusted`, so we can better avoid such problems.

src/java.base/share/classes/java/util/Digits.java line 68:

> 66:      */
> 67:     final class DecimalDigits implements Digits {
> 68:         private static final short[] DIGITS;

Can add `@Stable` to speed up array element access. Same for below.

src/java.base/share/classes/java/util/FormatProcessor.java line 157:

> 155:         Objects.requireNonNull(stringTemplate);
> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);

Suggestion:

        Object[] values = stringTemplate.values().toArray();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500281
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500568
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145503416
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145582334
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145509343
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145511968
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145520158
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145521984
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145532679
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145528633
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531061
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531547
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145533037
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145534263
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145566980
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145555878
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145567708
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145576079
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145577290
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145570455
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145578159
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145579950

From liach at openjdk.org  Thu Mar 23 01:52:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:32 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>

On Fri, 28 Oct 2022 20:05:22 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Disagree.
>
> As i said above, i consider this thread as resolved

Suggestion:

     * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145511120

From jlaskey at openjdk.org  Thu Mar 23 11:49:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:49:18 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <p_X2VwL8FULtj_Uc8EpMJdBF5min1UtyXow7dgSfm08=.4d5b5224-daef-4c01-9139-38382382426b@github.com>

On Wed, 22 Mar 2023 23:12:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 449:
> 
>> 447:      * statically imported explicitly.
>> 448:      */
>> 449:     static final SimpleProcessor<StringTemplate> RAW = st -> st;
> 
> Should we omit the modifiers `static final`, which are implicit for all interface fields?

Already changed.

> src/java.base/share/classes/java/lang/StringTemplate.java line 455:
> 
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
>> 455:      *
> 
> Paragraph break intended here?

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146060615
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146060887

From jlaskey at openjdk.org  Thu Mar 23 11:52:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:52:45 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <QU206yI0AfLSRZu-8MGtN95EdFTAmGIHbDIkw5Igv9w=.effa8829-ed13-42c3-b881-9bdfff403779@github.com>

On Wed, 22 Mar 2023 23:16:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 550:
> 
>> 548:      * SimpleProcessor<JSONObject> jsonProcessor = st -> new JSONObject(st.interpolate());
>> 549:      * }
>> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}
> 
> Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

This is in the changes JLS defined in https://bugs.openjdk.org/browse/JDK-8296302 . I'll be updating the @jls links when finalized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146066143

From jlaskey at openjdk.org  Thu Mar 23 12:16:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:16:39 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>

On Wed, 22 Mar 2023 23:23:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
> 
>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 678:     @FunctionalInterface
>> 679:     public interface StringProcessor extends SimpleProcessor<String> {
> 
> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
> 
> static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
> static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}
> 
> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

Worth considering. Thank you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146091987

From jlaskey at openjdk.org  Thu Mar 23 12:20:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:20:04 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>

On Thu, 23 Mar 2023 01:33:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
> 
>> 202:             Object[] values
>> 203:     ) throws Throwable {
>> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
> 
> Suggestion:
> 
>         List<Object> asList = List.of(values);
> 
> For defensive copy.
> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146098407

From jlaskey at openjdk.org  Thu Mar 23 12:24:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:24:12 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <fnsA_D74g7fDjymHpEjRggSEoo_59PBHF1NK8PwLhjo=.dd834f1d-5566-47a9-a59f-38ad822100fb@github.com>

On Thu, 23 Mar 2023 01:36:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/util/Digits.java line 68:
> 
>> 66:      */
>> 67:     final class DecimalDigits implements Digits {
>> 68:         private static final short[] DIGITS;
> 
> Can add `@Stable` to speed up array element access. Same for below.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 157:
> 
>> 155:         Objects.requireNonNull(stringTemplate);
>> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
>> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);
> 
> Suggestion:
> 
>         Object[] values = stringTemplate.values().toArray();

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146101352
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146103101

From jlaskey at openjdk.org  Thu Mar 23 12:28:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:28:54 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <RsngCPLETmmciRbbJmWhucmKxdY6wywBZYkxO3OlGmw=.8f251d95-7d25-467a-9e6f-68e0f68ffb3f@github.com>

On Thu, 23 Mar 2023 01:45:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 592:
> 
>> 590:          */
>> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 592:         public sealed interface Linkage permits FormatProcessor {
> 
> I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

Linkage is unfinished business for the first preview. What we are working on is a managed construction of the BSM, a ProcessorFactory per se. The hope is that this will be flushed out for the next round.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146110189

From jlaskey at openjdk.org  Thu Mar 23 12:44:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:44:34 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <_OQ7lbvgmuySOqu5i6NIihfPAee6VjBxoyhwv_lV7cw=.b7735595-141b-4f96-b9f4-605ecfce62aa@github.com>

On Thu, 23 Mar 2023 01:31:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 169:
> 
>> 167:      * @return StringTemplate composed from fragments and values
>> 168:      */
>> 169:     static StringTemplate newStringTemplate(List<String> fragments, Object[] values) {
> 
> I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

I don't disagree, I will consider.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146131084

From jlaskey at openjdk.org  Thu Mar 23 13:07:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 13:07:05 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v47]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <F7PO-Fpe6hQGkA70LwmKQ_EfnjmN_p9Ui_fjRO_U3BM=.4df1b97b-72eb-43c8-ac3b-200742e3e5f5@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Review recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/9ba6400d..6f95d953

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=45-46

  Stats: 36 lines in 6 files changed: 6 ins; 15 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Thu Mar 23 14:42:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 14:42:27 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
Message-ID: <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>

On Thu, 23 Mar 2023 12:12:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
>> 
>>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 678:     @FunctionalInterface
>>> 679:     public interface StringProcessor extends SimpleProcessor<String> {
>> 
>> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
>> 
>> static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
>> static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}
>> 
>> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.
>
> Worth considering. Thank you.

You can, of course, reduce this to;


interface Processor {
 
    ...
    
    static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
        return function::apply;
    }
    
    ...

}


since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146303119

From jlaskey at openjdk.org  Thu Mar 23 15:05:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:05:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
Message-ID: <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>

On Thu, 23 Mar 2023 14:39:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Worth considering. Thank you.
>
> You can, of course, reduce this to;
> 
> 
> interface Processor {
>  
>     ...
>     
>     static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
>         return function::apply;
>     }
>     
>     ...
> 
> }
> 
> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
> var string = Processor.of(StringTemplate::interpolate);
> 
> 
> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

On the flip side, for those that don't use `var`;


Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);


vs.


SimpleProcessor<JSONObject> simple = Processor.of(st-> new JSONObject(st.interpolate()));
StringProcessor string = Processor.of(StringTemplate::interpolate);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146336461

From jlaskey at openjdk.org  Thu Mar 23 15:53:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:53:26 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
Message-ID: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>

On Thu, 23 Mar 2023 15:01:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> You can, of course, reduce this to;
>> 
>> 
>> interface Processor {
>>  
>>     ...
>>     
>>     static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
>>         return function::apply;
>>     }
>>     
>>     ...
>> 
>> }
>> 
>> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> var string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.
>
> On the flip side, for those that don't use `var`;
> 
> 
> Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
> Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);
> 
> 
> vs.
> 
> 
> SimpleProcessor<JSONObject> simple = st-> new JSONObject(st.interpolate());
> StringProcessor string = StringTemplate::interpolate;

It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146406021

From forax at openjdk.org  Thu Mar 23 16:38:43 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:38:43 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
Message-ID: <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>

On Thu, 23 Mar 2023 15:49:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> On the flip side, for those that don't use `var`;
>> 
>> 
>> Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> vs.
>> 
>> 
>> SimpleProcessor<JSONObject> simple = st-> new JSONObject(st.interpolate());
>> StringProcessor string = StringTemplate::interpolate;
>
> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.

It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146450918

From liach at openjdk.org  Thu Mar 23 16:39:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 16:39:16 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 182:

> 180:      */
> 181:     static StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));

Suggestion:

        return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());

per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146462702

From forax at openjdk.org  Thu Mar 23 16:39:44 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:39:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
Message-ID: <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>

On Thu, 23 Mar 2023 12:17:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
>> 
>>> 202:             Object[] values
>>> 203:     ) throws Throwable {
>>> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
>> 
>> Suggestion:
>> 
>>         List<Object> asList = List.of(values);
>> 
>> For defensive copy.
>> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.
>
> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
so

  List<Object> asList = Arrays.stream(values).toList();

is what you are looking for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146455491

From jlaskey at openjdk.org  Thu Mar 23 17:09:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:14 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>
Message-ID: <mmAY9J3CZffkVQAoOMfuuQAn6e1W-CV9WTQmzXl-wcE=.1e74658f-a7cd-4ed7-8d81-91c5aec5122b@github.com>

On Thu, 23 Mar 2023 16:30:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 182:
> 
>> 180:      */
>> 181:     static StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
>> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));
> 
> Suggestion:
> 
>         return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());
> 
> per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146507522

From jlaskey at openjdk.org  Thu Mar 23 17:09:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:16 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
 <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>
Message-ID: <tRwCH5_g2UXF4dKHNXUHBnI7WSwtoIa25a-GGVUv848=.c98cd493-c687-498a-98e3-337d1ff529a4@github.com>

On Thu, 23 Mar 2023 16:25:22 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.
>
> There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
> so
> 
>   List<Object> asList = Arrays.stream(values).toList();
> 
> is what you are looking for.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146507389

From jlaskey at openjdk.org  Thu Mar 23 17:12:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:12:37 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v48]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <bx0_rNhNOOZtZFTD1o1Kyh0epp_vd3cXYvvgXdw654Y=.75542bb1-2326-4eaa-b8a9-1590237604b3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Clean up list construction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6f95d953..96752c64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=46-47

  Stats: 12 lines in 2 files changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Thu Mar 23 17:24:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:24:54 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
 <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>
Message-ID: <Xs8mcQOFKLdtbKIiMuYaZVAhn0F_LEA38YjAQTljriQ=.6130e9f7-58e6-4dae-abf1-ccef25a56510@github.com>

On Thu, 23 Mar 2023 16:21:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.
>
> Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.
> 
> It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

"Not a lot of people will write a processor" I am not as confident as you. Once the cat is out of the bag that you can do magic (pending Guide to String Templates), processors will become a common idiom for designating string literals, especially text blocks.

But, I do agree that a majority will do old school classes with `process` methods along with several supporting methods. On the other  hand, the API itself uses function interfaces to define STR and RAW. I guess I'll have to do a pro/con chart.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146528863

From jlu at openjdk.org  Thu Mar 23 19:16:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 19:16:30 GMT
Subject: <i18n dev> RFR: 8304761: Update IANA Language Subtag Registry to
 Version 2023-03-22
Message-ID: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>

Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

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

Commit messages:
 - Update ACCEPT_LANGUAGE and EXPECTED_RANGE_LIST
 - Test headers
 - Lsr changes

Changes: https://git.openjdk.org/jdk/pull/13165/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13165&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304761
  Stats: 171 lines in 2 files changed: 155 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13165/head:pull/13165

PR: https://git.openjdk.org/jdk/pull/13165

From naoto at openjdk.org  Thu Mar 23 20:25:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Mar 2023 20:25:13 GMT
Subject: <i18n dev> RFR: 8304761: Update IANA Language Subtag Registry
 to Version 2023-03-22
In-Reply-To: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
References: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
Message-ID: <P8Ef_kZD_fD1aboTF3VTldSmzSffTUgTyzhhQ-TBlj4=.26de435e-1e66-4d2f-be1f-3cce3c47f01e@github.com>

On Thu, 23 Mar 2023 19:07:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 193:

> 191:             new LanguageRange("ysm", 1.0),
> 192:             new LanguageRange("sgn-ysm", 1.0),
> 193:             new LanguageRange("wkr", 1.0),

What is the reason the weight has changed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13165#discussion_r1146786932

From jlu at openjdk.org  Thu Mar 23 21:19:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 21:19:35 GMT
Subject: <i18n dev> Integrated: 8303917: Update ISO 639 language codes table
In-Reply-To: <MOENoJ2KcvUifb9Gl6LLSWwQ90P-JyouAgSWFS1BB3A=.34e7d11d-bde8-4749-854f-f91e55261082@github.com>
References: <MOENoJ2KcvUifb9Gl6LLSWwQ90P-JyouAgSWFS1BB3A=.34e7d11d-bde8-4749-854f-f91e55261082@github.com>
Message-ID: <ACjUoD6McZt0NwT34874P9jQ2_t_HeHroCGJ7HN3Lek=.188e77c3-067b-4f72-84e7-63c7db09b22f@github.com>

On Fri, 10 Mar 2023 17:27:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR modifies `java.util.LocaleISOData.isoLanguageTable` to include (name only) changes from up-to-date [ISO 639 data](http://www.loc.gov/standards/iso639-2/php/code_list.php.).
> 
> In addition, this PR updates the ISO 639 data (generated in 1999) in `Bug4175998Test.java`. This includes modifying the `generate_Tables() `function, since the source data is now stored in a different format. The outdated raw data stored in the bottom of the file was removed.

This pull request has now been integrated.

Changeset: dd23ee9e
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd23ee9e8732223475a2e8c635322503dffbb6bf
Stats:     840 lines in 2 files changed: 62 ins; 626 del; 152 mod

8303917: Update ISO 639 language codes table

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/12980

From jlu at openjdk.org  Thu Mar 23 21:30:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 21:30:37 GMT
Subject: <i18n dev> RFR: 8304761: Update IANA Language Subtag Registry
 to Version 2023-03-22 [v2]
In-Reply-To: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
References: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
Message-ID: <YmaztjfK-WnWUbkMpShfctXSeqLeqnvFwFHmacwexAo=.50c2ac65-6450-41b0-9e23-50aa0dacb786@github.com>

> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Revert incorrect weighting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13165/files
  - new: https://git.openjdk.org/jdk/pull/13165/files/f9df542c..ff7901f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13165&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13165&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/13165

From jlu at openjdk.org  Thu Mar 23 21:38:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Mar 2023 21:38:00 GMT
Subject: <i18n dev> RFR: 8304761: Update IANA Language Subtag Registry
 to Version 2023-03-22 [v2]
In-Reply-To: <P8Ef_kZD_fD1aboTF3VTldSmzSffTUgTyzhhQ-TBlj4=.26de435e-1e66-4d2f-be1f-3cce3c47f01e@github.com>
References: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
 <P8Ef_kZD_fD1aboTF3VTldSmzSffTUgTyzhhQ-TBlj4=.26de435e-1e66-4d2f-be1f-3cce3c47f01e@github.com>
Message-ID: <s1UcX4TUsZrqb3Pp0NMV3GpqkKzmEtUjPRIKy7OWMsQ=.4f284379-8abf-4a82-a973-7445df0a879e@github.com>

On Thu, 23 Mar 2023 20:21:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert incorrect weighting
>
> test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java line 193:
> 
>> 191:             new LanguageRange("ysm", 1.0),
>> 192:             new LanguageRange("sgn-ysm", 1.0),
>> 193:             new LanguageRange("wkr", 1.0),
> 
> What is the reason the weight has changed?

`wkr` added into `ACCEPT_LANGUAGES` incorrectly by me, fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13165#discussion_r1146892276

From jlaskey at openjdk.org  Fri Mar 24 15:43:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:45 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <RxrEhssrnI3LiefQdgqBY4GomOVQsL4ekmpvSeNujeU=.e2baec72-a21f-4b99-9847-c324d0914cc3@github.com>

On Wed, 22 Mar 2023 23:27:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:
> 
>> 1049:      * @param ptypes    list of expression types
>> 1050:      *
>> 1051:      * @return {@link MethodHandle}
> 
> Suggestion:
> 
>      * @return the {@link MethodHandle} for concatenation

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:
> 
>> 1167:      * have an extra {@link String} slot for the result from the previous
>> 1168:      * {@link MethodHandle}.
>> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}
> 
> Suggestion:
> 
>      * {@link #makeConcatWithTemplate}

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 370:
> 
>> 368:          */
>> 369:         private static Map<MethodType, CarrierElements>
>> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());
> 
> Suggestion:
> 
>                 methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 421:
> 
>> 419:          */
>> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
>> 421:             this.primitives = createPrimitivesArray(primitiveCount );
> 
> Suggestion:
> 
>             this.primitives = createPrimitivesArray(primitiveCount);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 776:
> 
>> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
>> 775:          */
>> 776:         static CarrierElements of(Class < ? >...ptypes) {
> 
> Suggestion:
> 
>         static CarrierElements of(Class<?>... ptypes) {

Changing

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 49:
> 
>> 47: interface ReferenceKey<T> {
>> 48:     /**
>> 49:      * {@return the value of the unwrapped key.}
> 
> Suggestion:
> 
>      * {@return the value of the unwrapped key}
> 
> Inline return tag generates a period already.

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147750445
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752071
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757381
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752347
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147755043
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757878

From jlaskey at openjdk.org  Fri Mar 24 15:43:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:37 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v3]
In-Reply-To: <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
 <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>
Message-ID: <rYN35QVpwQyTCYLdyjrhAReLGXJaJJ2Q8J3foqyXJBk=.79a0e847-4dba-4c6e-b38b-522bea0e8950@github.com>

On Wed, 22 Mar 2023 23:26:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As i said above, i consider this thread as resolved
>
> Suggestion:
> 
>      * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147748029

From jlaskey at openjdk.org  Fri Mar 24 15:51:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:51:17 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <WAU8fcqQiwVjG9k-aZS7r0XP4KN_R3qho0XhzjAZewA=.5256da3e-3d3f-4d42-9fc6-aae4a222f985@github.com>

On Wed, 22 Mar 2023 23:56:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:
> 
>> 125:     @SuppressWarnings("unchecked")
>> 126:     static <K, V> ReferencedKeyMap<K, V>
>> 127:     create(boolean isSoft, Supplier<Map<?, ?>> supplier) {
> 
> What prevents this to take `Supplier<Map<ReferencedKey<K>, V>>`? Same for below.

Remnants of when I was have issues with param types. Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147768901

From jlaskey at openjdk.org  Fri Mar 24 15:58:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:58:13 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <pugiPyGFAbHHDjJAkRR85ZzhOuXVeRcvMaUg164VzGc=.ebc126d8-3cbf-457b-a30f-444552472355@github.com>

On Thu, 23 Mar 2023 01:12:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 40:
> 
>> 38:  * <p>
>> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
>> 40:  * and sharing of value shapes without creating a new class for each shape.
> 
> Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

About a 15-20% performance gain by not having two levels of indirection.

> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 88:
> 
>> 86:      *
>> 87:      * @param fragments  string template fragments
>> 88:      * @param type       method type
> 
> Suggestion:
> 
>      * @param type method type accepting values' types and returning a StringTemplate

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147771982
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147775001

From naoto at openjdk.org  Fri Mar 24 16:20:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Mar 2023 16:20:48 GMT
Subject: <i18n dev> RFR: 8304761: Update IANA Language Subtag Registry
 to Version 2023-03-22 [v2]
In-Reply-To: <YmaztjfK-WnWUbkMpShfctXSeqLeqnvFwFHmacwexAo=.50c2ac65-6450-41b0-9e23-50aa0dacb786@github.com>
References: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
 <YmaztjfK-WnWUbkMpShfctXSeqLeqnvFwFHmacwexAo=.50c2ac65-6450-41b0-9e23-50aa0dacb786@github.com>
Message-ID: <LHCFMam8Tkxc1yD_zSUjif4y-fo9fV9RJ8rUNOs2TlA=.5300421e-f02a-4dd8-9a51-23bca6a4a17b@github.com>

On Thu, 23 Mar 2023 21:30:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert incorrect weighting

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13165#pullrequestreview-1357036078

From jlu at openjdk.org  Fri Mar 24 18:17:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:17:32 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v2]
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <3LYhtu7WPIFHrmKz1OnDiGGEaJR76JP33cQ3Rz3caCM=.cfcd0c61-d22e-4078-9320-4324a9a8186c@github.com>

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Test all possible min week and first day of week combos for bugged date
 - Add safety check that amount is positive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/22387486..fe2f92f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=00-01

  Stats: 106 lines in 2 files changed: 48 ins; 19 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Fri Mar 24 18:23:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:23:13 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v2]
In-Reply-To: <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
Message-ID: <CtTLx9Flt_oJAZ8HPDhWlIx52yK9Zt_eUTHX32rHmcs=.0eca666d-d710-4183-ad1a-c9bc34fcefa8@github.com>

On Wed, 15 Mar 2023 19:47:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test all possible min week and first day of week combos for bugged date
>>  - Add safety check that amount is positive
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 1314:
> 
>> 1312:                     // current DAY_OF_WEEK
>> 1313:                     if (newWeekOfYear == 1 && isInvalidWeek1()) {
>> 1314:                         newWeekOfYear+=1;
> 
> is `+1` always correct? Does it work when the amount is negative?

When a week is rolled down to 1 (and it does not have a valid day_of_week), the existing code would appropriately adjust min, so that the new week set would be 52. However, yes, it should only be incremented if amount is positive, but there does not need to be a case for when amount is negative.

> test/jdk/java/util/Calendar/RollToMinWeek.java line 95:
> 
>> 93: 
>> 94:     private static Calendar buildCalendar(int day, int month, int year, Locale locale) {
>> 95:         Calendar calendar = Calendar.getInstance(locale);
> 
> If the fix is `GregorianCalendar` specific, should it check the type?

Yes, I have changed it so that it is intentionally set as Gregorian, and also tested for being Gregorian.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1147922575
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1147924484

From jlu at openjdk.org  Fri Mar 24 18:43:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:43:35 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v3]
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <dfiPoPxJBHB1Gdto32HQl7RukpeE_8yjm6JJkVt1a6Q=.a6a7c12c-5a40-4e24-aabe-3149328bf647@github.com>

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Expand testing to all end of year days that roll into week 1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/fe2f92f0..a844bb9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=01-02

  Stats: 20 lines in 1 file changed: 12 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Fri Mar 24 18:43:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:43:36 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v2]
In-Reply-To: <3LYhtu7WPIFHrmKz1OnDiGGEaJR76JP33cQ3Rz3caCM=.cfcd0c61-d22e-4078-9320-4324a9a8186c@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <3LYhtu7WPIFHrmKz1OnDiGGEaJR76JP33cQ3Rz3caCM=.cfcd0c61-d22e-4078-9320-4324a9a8186c@github.com>
Message-ID: <qySfDaf9Il9HR2uMMBdg-lkfsy6Onz9-lRXp9Inl688=.15398650-75b9-45be-ae53-4773e72c936e@github.com>

On Fri, 24 Mar 2023 18:17:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Test all possible min week and first day of week combos for bugged date
>  - Add safety check that amount is positive

The test currently tests 343 combinations for rolling from the end of the year into week 1

Before patch:
[ JUnit Tests: found 343, started 343, succeeded 308, failed 35, aborted 0, skipped 0]

After patch:
[ JUnit Tests: found 343, started 343, succeeded 343, failed 0, aborted 0, skipped 0]

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

PR Comment: https://git.openjdk.org/jdk/pull/13031#issuecomment-1483252698

From jlu at openjdk.org  Fri Mar 24 18:43:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:43:39 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v3]
In-Reply-To: <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <J-TtpUu-iN8XlloH372qaYKW6O41I3e3dOLSJgkHb9s=.4f3280d4-ce1e-4673-86fd-fb44457f6381@github.com>
Message-ID: <L1-e8Tz4HNga5pLuln6yn07ZWdwyxlV8bb99CA-RcWU=.86e6ee24-1588-4dfc-a8c1-6df21e5167ec@github.com>

On Wed, 15 Mar 2023 19:57:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Expand testing to all end of year days that roll into week 1
>
> test/jdk/java/util/Calendar/RollToMinWeek.java line 79:
> 
>> 77:         return Stream.of(
>> 78:                 // Test a variety of rolls that previously produced incorrect results
>> 79:                 Arguments.of(buildCalendar(27, 11, 2020, Locale.ENGLISH),
> 
> The first day of week depends on the region, not the language. In fact, I would prefer explicitly specifying it via a locale like `en-US-u-fw-mon`, and testing all the weekdays.

Updated the testing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1147939908

From jlu at openjdk.org  Fri Mar 24 18:48:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 18:48:41 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v4]
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <JgJeNt8456PTG-CJrpshR8E_7c1sH7-qEvYWW5fJyOQ=.fc4d4844-4267-4400-a8af-a35234d84803@github.com>

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove max week methods accidentally comitted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/a844bb9d..f837268c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=02-03

  Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From rriggs at openjdk.org  Fri Mar 24 19:34:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Mar 2023 19:34:32 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
Message-ID: <EnY_awqZn5wCuzEeNF5-Ano7LX--rxUVH4Ycc8Mbzgw=.b26ff0a2-4c4c-48df-af4d-bdcf3f01a4f0@github.com>

On Sun, 22 Jan 2023 09:50:21 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into dtfb
>  - Improve padding of DateTimeFormatter

fyi, you might want to wait for https://github.com/openjdk/jdk/pull/12728

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

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1466817993

From stsypanov at openjdk.org  Fri Mar 24 19:34:33 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:34:33 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <EnY_awqZn5wCuzEeNF5-Ano7LX--rxUVH4Ycc8Mbzgw=.b26ff0a2-4c4c-48df-af4d-bdcf3f01a4f0@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <EnY_awqZn5wCuzEeNF5-Ano7LX--rxUVH4Ycc8Mbzgw=.b26ff0a2-4c4c-48df-af4d-bdcf3f01a4f0@github.com>
Message-ID: <tiN3vCdLaEOanURe5SFVqo0QyJi1gdTftFygD4bTpHA=.9ed3ff27-6675-45b0-b16e-5bde4de488fb@github.com>

On Mon, 13 Mar 2023 19:24:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> fyi, you might want to wait for https://github.com/openjdk/jdk/pull/12728

@RogerRiggs thanks for pointing this out. Could we also have an overloaded method for inserting apart from appending?

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

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1467740231

From stsypanov at openjdk.org  Fri Mar 24 19:34:33 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:34:33 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
Message-ID: <86nDjsiZW-sBTnrBdVN95GWDGayZSZrCI0iI3eCbhFM=.8311443e-b3f6-48c4-91a6-119a0327c192@github.com>

On Sun, 22 Jan 2023 09:50:21 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into dtfb
>  - Improve padding of DateTimeFormatter

Benchmarking:

make test TEST="micro:time.format.DateTimeFormatterBench" MICRO="OPTIONS=-prof gc"

master

Benchmark                                                          Mode  Cnt     Score      Error   Units
DateTimeFormatterBench.formatWithPadding                          thrpt   15  1621.744 ?  216.203  ops/ms
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate           thrpt   15   295.938 ?   39.238  MB/sec
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15   192.000 ?    0.001    B/op
DateTimeFormatterBench.formatWithPadding:?gc.count                thrpt   15    23.000             counts
DateTimeFormatterBench.formatWithPadding:?gc.time                 thrpt   15   353.000                 ms
DateTimeFormatterBench.formatWithZeroPadding                      thrpt   15  2787.775 ? 1383.428  ops/ms
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   401.775 ?  201.097  MB/sec
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15   152.000 ?    0.001    B/op
DateTimeFormatterBench.formatWithZeroPadding:?gc.count            thrpt   15    22.000             counts
DateTimeFormatterBench.formatWithZeroPadding:?gc.time             thrpt   15   396.000                 ms


dtfb

Benchmark                                                          Mode  Cnt      Score     Error   Units
DateTimeFormatterBench.formatWithPadding                          thrpt   15   5489.480 ? 200.120  ops/ms
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate           thrpt   15   1171.637 ?  42.648  MB/sec
DateTimeFormatterBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15    224.000 ?   0.001    B/op
DateTimeFormatterBench.formatWithPadding:?gc.count                thrpt   15     62.000            counts
DateTimeFormatterBench.formatWithPadding:?gc.time                 thrpt   15    342.000                ms
DateTimeFormatterBench.formatWithZeroPadding                      thrpt   15  14355.239 ? 640.377  ops/ms
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   2078.802 ?  93.278  MB/sec
DateTimeFormatterBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15    152.000 ?   0.001    B/op
DateTimeFormatterBench.formatWithZeroPadding:?gc.count            thrpt   15     77.000            counts
DateTimeFormatterBench.formatWithZeroPadding:?gc.time             thrpt   15    555.000                ms

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

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1483302436

From stsypanov at openjdk.org  Fri Mar 24 19:34:34 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 24 Mar 2023 19:34:34 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
Message-ID: <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>

On Mon, 23 Jan 2023 11:34:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The modified code is called only when a user explicitly calls `padNext(int, char)`, i.e. if I modified the example snippet as
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>> //.padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>> 
>> there's no regression.
>> 
>> Right now I cannot build ad-hoc JDK with my changes and check it with JMH, so I'd convert this to draft until I can verify it
>
> Meant that you should verify that something like this, which just add a little padding, doesn't regress with your changes: 
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>     .appendLiteral("Year:")
>     .padNext(5)
>     .appendValue(ChronoField.YEAR)
>     .toFormatter();
> ... 
> dtf.format(LocalDateTime.now());
> 
> And similar for effectively no padding (`.padNext(4)` in the above example). As this API might often be used to ensure short 2-4 char fields are correctly padded I think it's important that we're not adding overhead to such use cases.

Added benchmark for this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1147980908

From jlu at openjdk.org  Fri Mar 24 20:45:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Mar 2023 20:45:21 GMT
Subject: <i18n dev> RFR: 8177352: Calendar.getDisplayName(s) in non-lenient
 mode inconsistent, does not match spec
Message-ID: <ZPEsG2BrkiJRCvX5KxW0IYohR_mD13V-sUI1XJuifrk=.099b860a-1232-4682-b8bf-a89d64476703@github.com>

This PR updates the javadoc of `java.util.Calendar.getDisplayName()` and `java.util.Calendar.getDisplayNames()` to better reflect the actual behavior when the calendar is non-lenient.

This involves adding the **implSpec** tag to both methods to clarify behavior, as well as removing false behavior from the **throws** tag in `java.util.Calendar.getDisplayNames()`.

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

Commit messages:
 - Adjust wording of spec for getDisplayName()
 - Copyright year
 - Change to normal spec changes (as opposed to implSpec)
 - JDK-8177352

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

PR: https://git.openjdk.org/jdk/pull/13083

From naoto at openjdk.org  Fri Mar 24 22:09:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Mar 2023 22:09:32 GMT
Subject: <i18n dev> RFR: 8177352: Calendar.getDisplayName(s) in
 non-lenient mode inconsistent, does not match spec
In-Reply-To: <ZPEsG2BrkiJRCvX5KxW0IYohR_mD13V-sUI1XJuifrk=.099b860a-1232-4682-b8bf-a89d64476703@github.com>
References: <ZPEsG2BrkiJRCvX5KxW0IYohR_mD13V-sUI1XJuifrk=.099b860a-1232-4682-b8bf-a89d64476703@github.com>
Message-ID: <LLKu9W43ZLHT4nYyMZalMg7jL2LwomFaRiHMcbYgPIA=.c4b44898-9714-4a30-8dcc-952f977d5038@github.com>

On Fri, 17 Mar 2023 18:22:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the javadoc of `java.util.Calendar.getDisplayName()` and `java.util.Calendar.getDisplayNames()` to better reflect the actual behavior when the calendar is non-lenient.
> 
> This involves updating the spec of both methods to clarify behavior, as well as removing false behavior from the **throws** tag in `java.util.Calendar.getDisplayNames()`.

Looks good. Please add `noreg-doc` label to the issue.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13083#pullrequestreview-1357494038

From jlaskey at openjdk.org  Mon Mar 27 16:17:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 16:17:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v49]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <m87R9KqgHRFWTaSkiHHK9nbPl0Q9dnSrR0phYMEJpFg=.19cf87ba-2f6a-476c-83e3-e89ff7ba77c3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested review changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/96752c64..58eeb319

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=47-48

  Stats: 179 lines in 12 files changed: 31 ins; 116 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From stsypanov at openjdk.org  Mon Mar 27 16:27:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 27 Mar 2023 16:27:18 GMT
Subject: <i18n dev> RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
Message-ID: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>

1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)

2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.


@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class DateTimeFormatterBenchmark {

    private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
    private static final String TEXT = "2015:03:10:12:13:ECT";

    @Setup
    public void setUp() {
        ZonedDateTime.parse(TEXT, df);
    }

    @Benchmark
    public ZonedDateTime parse() {
        return ZonedDateTime.parse(TEXT, df);
    }
}

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

Commit messages:
 - Revert irrelevant
 - Revert irrelevant
 - Measure average time
 - Delete duplicated
 - Merge branch 'master' into date-time-formatter-build
 - Add benchmark
 - Add JavaDoc and imports
 - Optimize DateTimeFormatterBuilder

Changes: https://git.openjdk.org/jdk/pull/12612/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304976
  Stats: 62 lines in 2 files changed: 57 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12612.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12612/head:pull/12612

PR: https://git.openjdk.org/jdk/pull/12612

From stsypanov at openjdk.org  Mon Mar 27 16:27:19 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 27 Mar 2023 16:27:19 GMT
Subject: <i18n dev> RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
In-Reply-To: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
References: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
Message-ID: <2UjizIpykQCtRLPmFK4Xh8AsL2N38BuR5AVvuIrc0hk=.532bbab1-4c8c-4ed1-8356-17abb715b8a3@github.com>

On Fri, 17 Feb 2023 09:50:16 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

Benchmarking

make test TEST="micro:time.format.ZonedDateTimeFormatterBenchmark" MICRO="OPTIONS=-prof gc"

master

Benchmark                                                              Mode  Cnt      Score     Error   Units
ZonedDateTimeFormatterBenchmark.parse                                  avgt   20  13545.737 ? 451.164   ns/op
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate                   avgt   20   1713.579 ?  56.517  MB/sec
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate.norm              avgt   20  24320.006 ?   0.001    B/op
ZonedDateTimeFormatterBenchmark.parse:?gc.count                        avgt   20    110.000            counts
ZonedDateTimeFormatterBenchmark.parse:?gc.time                         avgt   20    514.000                ms


patch

Benchmark                                                              Mode  Cnt     Score    Error   Units
ZonedDateTimeFormatterBenchmark.parse                                  avgt   20  1276.063 ? 52.543   ns/op
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate                   avgt   20   622.223 ? 26.456  MB/sec
ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate.norm              avgt   20   832.001 ?  0.001    B/op
ZonedDateTimeFormatterBenchmark.parse:?gc.count                        avgt   20    58.000           counts
ZonedDateTimeFormatterBenchmark.parse:?gc.time                         avgt   20   475.000               ms

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

PR Comment: https://git.openjdk.org/jdk/pull/12612#issuecomment-1483893997

From jlu at openjdk.org  Mon Mar 27 21:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Mar 2023 21:39:42 GMT
Subject: <i18n dev> Integrated: 8177352: Calendar.getDisplayName(s) in
 non-lenient mode inconsistent, does not match spec
In-Reply-To: <ZPEsG2BrkiJRCvX5KxW0IYohR_mD13V-sUI1XJuifrk=.099b860a-1232-4682-b8bf-a89d64476703@github.com>
References: <ZPEsG2BrkiJRCvX5KxW0IYohR_mD13V-sUI1XJuifrk=.099b860a-1232-4682-b8bf-a89d64476703@github.com>
Message-ID: <gVgGv21QroNB5kH8a9eEi60Ffepb1zLvdNFoEE4fKaA=.a386c0dc-048f-4723-a583-446d08823f5b@github.com>

On Fri, 17 Mar 2023 18:22:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the javadoc of `java.util.Calendar.getDisplayName()` and `java.util.Calendar.getDisplayNames()` to better reflect the actual behavior when the calendar is non-lenient.
> 
> This involves updating the spec of both methods to clarify behavior, as well as removing false behavior from the **throws** tag in `java.util.Calendar.getDisplayNames()`.

This pull request has now been integrated.

Changeset: f8e8fc7e
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8e8fc7e29f9b27bc6031804f916c34b8ef5a83e
Stats:     16 lines in 1 file changed: 12 ins; 2 del; 2 mod

8177352: Calendar.getDisplayName(s) in non-lenient mode inconsistent, does not match spec

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/13083

From jlu at openjdk.org  Mon Mar 27 21:40:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Mar 2023 21:40:48 GMT
Subject: <i18n dev> Integrated: 8304761: Update IANA Language Subtag
 Registry to Version 2023-03-22
In-Reply-To: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
References: <qQ-ZD77BMnRNvUwBa8jUm-DAQ0ZGIhp9IT1zP-9GEN4=.665ad8bb-8c58-41f5-906a-6ae5f07c5544@github.com>
Message-ID: <aXDlKwpJ5uj7TiOg774ucSJIepNcporHe_4zMTF6MPs=.e2e822de-f191-4dbb-b7dd-03b113fe86aa@github.com>

On Thu, 23 Mar 2023 19:07:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Update IANA LSR to 2023-03-22 [update](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-March/000085.html). Add all new preferred languages to `ACCEPT_LANGUAGES` except `gu`.

This pull request has now been integrated.

Changeset: 3b88b2a9
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b88b2a9f88f47b850bd975a76c4a7050ccd8fd0
Stats:     170 lines in 2 files changed: 155 ins; 1 del; 14 mod

8304761: Update IANA Language Subtag Registry to Version 2023-03-22

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/13165

From naoto at openjdk.org  Mon Mar 27 22:41:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Mar 2023 22:41:40 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v4]
In-Reply-To: <JgJeNt8456PTG-CJrpshR8E_7c1sH7-qEvYWW5fJyOQ=.fc4d4844-4267-4400-a8af-a35234d84803@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <JgJeNt8456PTG-CJrpshR8E_7c1sH7-qEvYWW5fJyOQ=.fc4d4844-4267-4400-a8af-a35234d84803@github.com>
Message-ID: <Apobd5TKt7BOPIoUlMXyXf5ltNNop2W4N9G0SFmi3Wk=.1e35b66d-b9de-4ab6-9f50-260d3aeef258@github.com>

On Fri, 24 Mar 2023 18:48:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove max week methods accidentally comitted

Looks good. Mostly cosmetic comments follow

src/java.base/share/classes/java/util/GregorianCalendar.java line 1315:

> 1313:                     // rolling up into week 1, as the existing checks
> 1314:                     // sufficiently handle rolling down into week 1.
> 1315:                     if (newWeekOfYear == 1 && (isInvalidWeek1())) {

Extra parens around `isInvalidWeek1()`

src/java.base/share/classes/java/util/GregorianCalendar.java line 1316:

> 1314:                     // sufficiently handle rolling down into week 1.
> 1315:                     if (newWeekOfYear == 1 && (isInvalidWeek1())) {
> 1316:                         if (amount > 0) {

Can be folded into the above `if`

src/java.base/share/classes/java/util/GregorianCalendar.java line 3015:

> 3013:     private boolean isMinWeek (int days) {
> 3014:         return days >= getMinimalDaysInFirstWeek();
> 3015:     }

Since this method is only used above once, maybe make the check inline?

src/java.base/share/classes/java/util/GregorianCalendar.java line 3032:

> 3030:             // not between 6 7 1 2 3
> 3031:             return !(day >= startDay || day <= endDay);
> 3032:         }

Could be more readable if the method does not have `Not`, i.e, `daysInMinWeek`? This would remove the negation in the return statements.

test/jdk/java/util/Calendar/RollToMinWeek.java line 28:

> 26:  * @bug 8225641
> 27:  * @summary Test the behavior of Calendar.roll(WEEK_OF_YEAR) when the last week
> 28:  * is rolled up into a minimal week 1 of the same year

`minimal week 1` may be unclear.

test/jdk/java/util/Calendar/RollToMinWeek.java line 43:

> 41: /**
> 42:  * Test to validate the behavior of Calendar.roll(WEEK_OF_YEAR, +1)
> 43:  * when rolling into a minimal week 1 from the max week. WEEK_OF_YEAR can

IIUC, `minimal` and `max` mean `first` and `last` respectively? I'd rather change those as it would confuse with `minimal days in the first week`.

test/jdk/java/util/Calendar/RollToMinWeek.java line 52:

> 50:     public void rollUpTest(Calendar calendar, String[] validDates){
> 51:         if (calendar instanceof GregorianCalendar) {
> 52:             testRoll(calendar, validDates, +1);

If the amount is fixed to `+1`, no need to pass it as an argument

test/jdk/java/util/Calendar/RollToMinWeek.java line 98:

> 96:                 for (int firstDay = 1; firstDay <= 7; firstDay++) {
> 97:                     calList.add(Arguments.of(buildCalendar("gregory", firstDay, weekLength,
> 98:                                     dayOfMonth, 11, 2019), validDates[date]));

`11` may better be replaced with `Calendar.DECEMBER`.

test/jdk/java/util/Calendar/RollToMinWeek.java line 114:

> 112:         calBuilder.setDate(year, month, dayOfMonth);
> 113:         return calBuilder.build();
> 114:     }

`Builder` instance can be reused. Also since Builder can method chain, you could write

static Calendar.Builder CAL_BUILDER = new Builder().setCalendarType(type);

return CAL_BUILDER
    .setWeekDefinition(...)
    .setDate(...)
    .build();

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

PR Review: https://git.openjdk.org/jdk/pull/13031#pullrequestreview-1359843143
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149772051
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149771259
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149777645
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149779427
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149838007
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149838132
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149843461
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149847360
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1149851739

From jlaskey at openjdk.org  Tue Mar 28 15:14:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 15:14:44 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v50]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <WrElbf-3B1iF4yBMQt2_QmSQ5IBKu1lp9-E2nSZba0s=.69bd2cf1-435b-4bef-ba76-19cac9b5ac5b@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update StringTemplate.combine javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/58eeb319..c9696c2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=48-49

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

PR: https://git.openjdk.org/jdk/pull/10889

From naoto at openjdk.org  Tue Mar 28 16:44:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Mar 2023 16:44:26 GMT
Subject: <i18n dev> RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
In-Reply-To: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
References: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
Message-ID: <Bq9AMIpYESiJtMMeOSY13zPUn7dEhd_agu3c15Dl04M=.f3064157-6f3f-486c-9293-66fdff8657f4@github.com>

On Fri, 17 Feb 2023 09:50:16 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

Looks like a nice fix to me.

test/micro/org/openjdk/bench/java/time/format/ZonedDateTimeFormatterBenchmark.java line 23:

> 21:  * questions.
> 22:  */
> 23: package time.format;

package should be `org.openjdk.bench.java.time.format`?

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12612#pullrequestreview-1361520443
PR Review Comment: https://git.openjdk.org/jdk/pull/12612#discussion_r1150894573

From jlu at openjdk.org  Tue Mar 28 21:06:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Mar 2023 21:06:34 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v5]
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <j1H0cARPBlHP3tJxdkJh3B3OCX0l4t2wK8UW7St_0dM=.3cef931f-7aa8-472a-865f-9fcd49da775c@github.com>

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with five additional commits since the last revision:

 - Impl cleanup, add Saturday end day conditional
 - Rename test, clarify test documentation
 - Add type to static declaration of Cal.Builder, since only concerned with Gregorian for this test
 - Pass in amount as 1 directly
 - Reuse Calendar.Builder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/f837268c..60d0621b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=03-04

  Stats: 278 lines in 3 files changed: 132 ins; 133 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Tue Mar 28 21:10:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Mar 2023 21:10:30 GMT
Subject: <i18n dev> RFR: 8304993: bad sentence break in DateFormat
Message-ID: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>

This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API

Before:
<img width="1024" alt="Screen Shot 2023-03-27" src="https://user-images.githubusercontent.com/67398801/228359165-f8c66ca2-745b-47ea-bca9-9c4afc7af914.png">

After:
<img src="https://user-images.githubusercontent.com/67398801/228358935-9d978a7a-bfa5-42df-85a7-587e39d6c82c.png" width="800" height="40">

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

Commit messages:
 - Wrap e.g. with @literal to fix first sentence detection

Changes: https://git.openjdk.org/jdk/pull/13216/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13216&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304993
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13216.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13216/head:pull/13216

PR: https://git.openjdk.org/jdk/pull/13216

From rriggs at openjdk.org  Tue Mar 28 21:58:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Mar 2023 21:58:30 GMT
Subject: <i18n dev> RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
References: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
Message-ID: <JCFTAzCbSqE_kjg35eu_oS6Iatd2VdNHOzy73A_fquo=.92ec0655-9dbc-4f93-ae17-78bb9becac6f@github.com>

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> <img width="1024" alt="Screen Shot 2023-03-27" src="https://user-images.githubusercontent.com/67398801/228359165-f8c66ca2-745b-47ea-bca9-9c4afc7af914.png">
> 
> After:
> <img src="https://user-images.githubusercontent.com/67398801/228358935-9d978a7a-bfa5-42df-85a7-587e39d6c82c.png" width="800" height="40">

An unusual case... LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1361961557

From naoto at openjdk.org  Tue Mar 28 22:02:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Mar 2023 22:02:29 GMT
Subject: <i18n dev> RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
References: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
Message-ID: <G2jB7UX0x7XSX6h2vFL_oUrBoiPJVutW6PNIOVjfWl0=.8e42c7c7-949b-40bb-a3c0-105e2b99c47a@github.com>

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> <img width="1024" alt="Screen Shot 2023-03-27" src="https://user-images.githubusercontent.com/67398801/228359165-f8c66ca2-745b-47ea-bca9-9c4afc7af914.png">
> 
> After:
> <img src="https://user-images.githubusercontent.com/67398801/228358935-9d978a7a-bfa5-42df-85a7-587e39d6c82c.png" width="800" height="40">

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1361965055

From lancea at openjdk.org  Tue Mar 28 22:06:29 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Mar 2023 22:06:29 GMT
Subject: <i18n dev> RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
References: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
Message-ID: <qvhJ2bs5DcP3RDc-JiDfJ814Zz-spVpTe6q0fSdhjTY=.1677e2d9-7d58-48af-b971-405a4359a389@github.com>

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> <img width="1024" alt="Screen Shot 2023-03-27" src="https://user-images.githubusercontent.com/67398801/228359165-f8c66ca2-745b-47ea-bca9-9c4afc7af914.png">
> 
> After:
> <img src="https://user-images.githubusercontent.com/67398801/228358935-9d978a7a-bfa5-42df-85a7-587e39d6c82c.png" width="800" height="40">

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1361969887

From iris at openjdk.org  Tue Mar 28 23:30:30 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 28 Mar 2023 23:30:30 GMT
Subject: <i18n dev> RFR: 8304993: bad sentence break in DateFormat
In-Reply-To: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
References: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
Message-ID: <PdAX-a8av9tmB5_2wfIm1e6zu9u1mbVEu6PS8OJT494=.60793a8a-a8c5-42dd-a70f-fba4feae0ab1@github.com>

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> <img width="1024" alt="Screen Shot 2023-03-27" src="https://user-images.githubusercontent.com/67398801/228359165-f8c66ca2-745b-47ea-bca9-9c4afc7af914.png">
> 
> After:
> <img src="https://user-images.githubusercontent.com/67398801/228358935-9d978a7a-bfa5-42df-85a7-587e39d6c82c.png" width="800" height="40">

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13216#pullrequestreview-1362044318

From stsypanov at openjdk.org  Wed Mar 29 08:16:32 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 08:16:32 GMT
Subject: <i18n dev> RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]
In-Reply-To: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
References: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
Message-ID: <I6FI_1J7EaJ9J9b2__A7hs_ZysBCXJVv0EphC-kXimI=.bdd3a9e1-dad0-479c-b07f-ed3b9a1f7905@github.com>

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8304745: Fix package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12612/files
  - new: https://git.openjdk.org/jdk/pull/12612/files/b542ae06..623a7730

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12612&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12612&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12612

From stsypanov at openjdk.org  Wed Mar 29 08:16:36 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 08:16:36 GMT
Subject: <i18n dev> RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]
In-Reply-To: <Bq9AMIpYESiJtMMeOSY13zPUn7dEhd_agu3c15Dl04M=.f3064157-6f3f-486c-9293-66fdff8657f4@github.com>
References: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
 <Bq9AMIpYESiJtMMeOSY13zPUn7dEhd_agu3c15Dl04M=.f3064157-6f3f-486c-9293-66fdff8657f4@github.com>
Message-ID: <6K_R-M2fNeC8LQNtX2hZBTmHFfsw-XO0NCtEx3nzuBg=.9de30de6-00a1-4206-9dcc-34a5e68a0421@github.com>

On Tue, 28 Mar 2023 16:40:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304745: Fix package
>
> test/micro/org/openjdk/bench/java/time/format/ZonedDateTimeFormatterBenchmark.java line 23:
> 
>> 21:  * questions.
>> 22:  */
>> 23: package time.format;
> 
> package should be `org.openjdk.bench.java.time.format`?

Renamed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12612#discussion_r1151551588

From jlaskey at openjdk.org  Wed Mar 29 14:57:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 14:57:06 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v51]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <LVcp5vWdUuUSkMzbbbOdDjYLooIKU_5IpS1jTnwauLA=.59afa583-063e-4194-98f6-d2e06e2004c3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:

 - Merge branch 'master' into 8285932
 - Update StringTemplate.combine javadoc
 - Requested review changes.
 - Clean up list construction
 - Review recommended changes
 - Tidy javadoc
 - Rename StringTemplate classes
 - Merge branch 'master' into 8285932
 - Correction
 - Merge branch 'master' into 8285932
 - ... and 59 more: https://git.openjdk.org/jdk/compare/50a995f0...3e1cc74a

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=50
  Stats: 9255 lines in 75 files changed: 9156 ins; 24 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Wed Mar 29 15:46:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 15:46:34 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v52]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <TC3w3VrcgeJyYDiYGehji419QgXo0wmkd6sqPZ0k-L0=.29b2c5e8-48d3-432d-980a-1e6062a11ed2@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update combine example

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/3e1cc74a..67ffbccc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=50-51

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

PR: https://git.openjdk.org/jdk/pull/10889

From stsypanov at openjdk.org  Wed Mar 29 16:09:34 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 16:09:34 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <qOSCNwfvprWc51TFRbXtC0p4ODsMd8YBXIYXfZqm68c=.2ea3e9eb-083f-4f95-ad67-f0b1fbf2c7da@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Let's wait

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1488898753

From naoto at openjdk.org  Wed Mar 29 16:24:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 16:24:33 GMT
Subject: <i18n dev> RFR: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]
In-Reply-To: <I6FI_1J7EaJ9J9b2__A7hs_ZysBCXJVv0EphC-kXimI=.bdd3a9e1-dad0-479c-b07f-ed3b9a1f7905@github.com>
References: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
 <I6FI_1J7EaJ9J9b2__A7hs_ZysBCXJVv0EphC-kXimI=.bdd3a9e1-dad0-479c-b07f-ed3b9a1f7905@github.com>
Message-ID: <Br1_ABVCtWu4-SlS6znbY-wqqiqLk8Dxh4SLnz6e-Ek=.3defce79-bbaa-409d-9262-c75fdb5567fa@github.com>

On Wed, 29 Mar 2023 08:16:32 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
>> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
>> 
>> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
>> 
>> 
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class DateTimeFormatterBenchmark {
>> 
>>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>>     private static final String TEXT = "2015:03:10:12:13:ECT";
>> 
>>     @Setup
>>     public void setUp() {
>>         ZonedDateTime.parse(TEXT, df);
>>     }
>> 
>>     @Benchmark
>>     public ZonedDateTime parse() {
>>         return ZonedDateTime.parse(TEXT, df);
>>     }
>> }
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304745: Fix package

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12612#pullrequestreview-1363506079

From stsypanov at openjdk.org  Wed Mar 29 18:35:36 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 29 Mar 2023 18:35:36 GMT
Subject: <i18n dev> Integrated: 8304976: Optimize
 DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()
In-Reply-To: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
References: <AsfX5GtuuafI9T4FODDEyEDj8rZLtoexbh2z7WiDR6E=.d45e435d-eb6f-41fd-8954-9fabc31643ee@github.com>
Message-ID: <ZDiUI4CAFOVD-ByWKVbj0rKXJvylZcyqg55jZgV08zs=.277d17ff-3763-4ac2-b7f9-c080ed284045@github.com>

On Fri, 17 Feb 2023 09:50:16 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> 1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTimeFormatter` to parse a string into `ZoneDateTime`
> ![image](https://user-images.githubusercontent.com/10835776/219609028-af48eae4-d326-4719-8366-c215baa85835.png)
> 
> 2) `DateTimeFormatter` is mostly used with one locale, so `cachedTree` and `cachedTreeCI` can have predefined size.
> 
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class DateTimeFormatterBenchmark {
> 
>     private static final DateTimeFormatter df = new DateTimeFormatterBuilder().appendPattern("yyyy:MM:dd:HH:mm:v").toFormatter();
>     private static final String TEXT = "2015:03:10:12:13:ECT";
> 
>     @Setup
>     public void setUp() {
>         ZonedDateTime.parse(TEXT, df);
>     }
> 
>     @Benchmark
>     public ZonedDateTime parse() {
>         return ZonedDateTime.parse(TEXT, df);
>     }
> }

This pull request has now been integrated.

Changeset: 438c969b
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/438c969b7b07eeef0158b089e5a168849e04bf56
Stats:     62 lines in 2 files changed: 57 ins; 1 del; 4 mod

8304976: Optimize DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/12612

From jlu at openjdk.org  Wed Mar 29 22:58:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 29 Mar 2023 22:58:51 GMT
Subject: <i18n dev> RFR: 8305111: Locale.lookupTag has typo in parameter
Message-ID: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>

Small typo fix in Locale.lookupTag

_tangs_ should be _tags_

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

Commit messages:
 - Fix typo

Changes: https://git.openjdk.org/jdk/pull/13235/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305111
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13235/head:pull/13235

PR: https://git.openjdk.org/jdk/pull/13235

From lancea at openjdk.org  Wed Mar 29 23:15:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Mar 2023 23:15:39 GMT
Subject: <i18n dev> RFR: 8305111: Locale.lookupTag has typo in parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: <0GMrdSomYb9w3PxvFQlPgf6_q2CrkbgTHQMbr4068q8=.b261b996-dd96-4c71-bbf2-466c88374a5a@github.com>

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13235#pullrequestreview-1364100110

From naoto at openjdk.org  Wed Mar 29 23:21:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Mar 2023 23:21:45 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v5]
In-Reply-To: <j1H0cARPBlHP3tJxdkJh3B3OCX0l4t2wK8UW7St_0dM=.3cef931f-7aa8-472a-865f-9fcd49da775c@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <j1H0cARPBlHP3tJxdkJh3B3OCX0l4t2wK8UW7St_0dM=.3cef931f-7aa8-472a-865f-9fcd49da775c@github.com>
Message-ID: <PZMORjMnStFs40VfNcd2f_RMki2ONhuebNFwaBiQM0o=.2f8d5960-6061-4ce0-a008-d933dedb4f49@github.com>

On Tue, 28 Mar 2023 21:06:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Impl cleanup, add Saturday end day conditional
>  - Rename test, clarify test documentation
>  - Add type to static declaration of Cal.Builder, since only concerned with Gregorian for this test
>  - Pass in amount as 1 directly
>  - Reuse Calendar.Builder

src/java.base/share/classes/java/util/GregorianCalendar.java line 3014:

> 3012:      */
> 3013:     private boolean dayInMinWeek (int day, int startDay, int endDay) {
> 3014:         endDay = endDay == 0

Why `endDay` can be `0`? If the arguments are `Calendar.XXXDAY`, should they be between 1 to 7? In other words, why is the above calling site doing `getFirstDayOfWeek() - 1`?
I'd add some range checks for the input values.

test/jdk/java/util/Calendar/RollFromLastToFirstWeek.java line 52:

> 50:  */
> 51: public class RollFromLastToFirstWeek {
> 52:     static Calendar.Builder GREGORIAN_BUILDER = new Builder()

Nit: `Calendar.` can be omitted (and can be `private static final`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1152579044
PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1152579338

From iris at openjdk.org  Wed Mar 29 23:25:01 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 29 Mar 2023 23:25:01 GMT
Subject: <i18n dev> RFR: 8305111: Locale.lookupTag has typo in parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: <ewlAaGTkp_K8FuEd_jW20iHEk1dwUvPOsTxOx9P_a9A=.0c965943-d971-4171-890b-1b819351fd4d@github.com>

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13235#pullrequestreview-1364106018

From naoto at openjdk.org  Thu Mar 30 00:44:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 00:44:22 GMT
Subject: <i18n dev> RFR: 8305111: Locale.lookupTag has typo in parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: <z1RsMinq7CYBHjgUmhUbjdR2YMt2PyL0CYVVPcvq_Eg=.7bb5169d-1f7d-488c-922c-ad4833f1a422@github.com>

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13235#pullrequestreview-1364170271

From jjg at openjdk.org  Thu Mar 30 17:31:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 17:31:12 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1)
Message-ID: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>

Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.

This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.

While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.

It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]

[here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
[disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

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

Commit messages:
 - JDK-8305206: Add @spec tags in java.base/java.* (part 1)

Changes: https://git.openjdk.org/jdk/pull/13248/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305206
  Stats: 281 lines in 60 files changed: 267 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248

From alanb at openjdk.org  Thu Mar 30 19:51:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Mar 2023 19:51:22 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

I skimmed through the changes and it looks quite good, much more workable than PR 11073.

Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @spec is before @author, and @see after @author. I know it doesn't really matter.

src/java.base/share/classes/java/lang/Thread.java line 1960:

> 1958:      *             thread.
> 1959:      *
> 1960:      * @spec jni/index.html Java Native Interface Specification

The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

src/java.base/share/classes/java/nio/file/Files.java line 1724:

> 1722:      *
> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies

Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1365814487
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153715180
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153716361

From jjg at openjdk.org  Thu Mar 30 20:33:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:33:17 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1)
In-Reply-To: <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
Message-ID: <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>

On Thu, 30 Mar 2023 19:42:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> src/java.base/share/classes/java/lang/Thread.java line 1960:
> 
>> 1958:      *             thread.
>> 1959:      *
>> 1960:      * @spec jni/index.html Java Native Interface Specification
> 
> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.

Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with `<a href-....>`. 

When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

> src/java.base/share/classes/java/nio/file/Files.java line 1724:
> 
>> 1722:      *
>> 1723:      * @spec https://www.rfc-editor.org/info/rfc2045
>> 1724:      *      RFC 2045: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
> 
> Maybe this one can be put on two lines to avoid the wrapping when looking at is side-by-side.

Fixed. There was also a stutter-bug with a double "RFC 2045: RFC 2045:" which I have also fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153755656
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1153756945

From jjg at openjdk.org  Thu Mar 30 20:45:08 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:08 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/3e1102a9..096a4188

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/13248

From jjg at openjdk.org  Thu Mar 30 20:45:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 30 Mar 2023 20:45:10 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

> I skimmed through the changes and it looks quite good, much more workable than PR 11073.
> 
> Do you have a proposed ordering with other tags? I expected it would go with @see but I see several where @SPEC is before @author, and @see after @author. I know it doesn't really matter.

The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally.  In the description, I suggested an ordering based on the
order in `Docs.gmk` which defines the order in which tags appear in the generated output.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1490920050

From jlu at openjdk.org  Thu Mar 30 21:33:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 21:33:16 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v6]
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <DudowbbTWR70SJaSMTUKbDKE57RaJSlBvGl-61AZaiw=.3b141092-9815-4cb5-a422-7cc432632e56@github.com>

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - dayInMinWeek should range check input and throw exception
 - Tweak static cal builder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/60d0621b..7c9291a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=04-05

  Stats: 17 lines in 2 files changed: 11 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Thu Mar 30 21:33:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 21:33:19 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v5]
In-Reply-To: <PZMORjMnStFs40VfNcd2f_RMki2ONhuebNFwaBiQM0o=.2f8d5960-6061-4ce0-a008-d933dedb4f49@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <j1H0cARPBlHP3tJxdkJh3B3OCX0l4t2wK8UW7St_0dM=.3cef931f-7aa8-472a-865f-9fcd49da775c@github.com>
 <PZMORjMnStFs40VfNcd2f_RMki2ONhuebNFwaBiQM0o=.2f8d5960-6061-4ce0-a008-d933dedb4f49@github.com>
Message-ID: <MAY7nk7euFXjm0rdlrsS5bj3KQF54K8jkd5hTbC44Yk=.ffa86049-0b2b-41c4-97d3-97b5aa174cbf@github.com>

On Wed, 29 Mar 2023 23:14:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Impl cleanup, add Saturday end day conditional
>>  - Rename test, clarify test documentation
>>  - Add type to static declaration of Cal.Builder, since only concerned with Gregorian for this test
>>  - Pass in amount as 1 directly
>>  - Reuse Calendar.Builder
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 3014:
> 
>> 3012:      */
>> 3013:     private boolean dayInMinWeek (int day, int startDay, int endDay) {
>> 3014:         endDay = endDay == 0
> 
> Why `endDay` can be `0`? If the arguments are `Calendar.XXXDAY`, should they be between 1 to 7? In other words, why is the above calling site doing `getFirstDayOfWeek() - 1`?
> I'd add some range checks for the input values.

Right. I have changed it so the method throws an exception if the start and end days are not valid `DAY_OF_WEEK `values.

And I have moved the ternary of switching 0 to 7 outside the method accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1153805524

From jlu at openjdk.org  Thu Mar 30 22:37:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 22:37:29 GMT
Subject: <i18n dev> Integrated: 8305111: Locale.lookupTag has typo in
 parameter
In-Reply-To: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
References: <0RAdK8ZfiSUn1UZKzX44LAvjE0i8l_0LKEoC-63bY24=.12f961ee-ac5b-41cf-9697-62e3f6b8812f@github.com>
Message-ID: <8jw6hyaw1bBqP7rPOzxKnAiOGcwYhrmcXJ9xxgc_1ww=.0205b2d9-1bb8-4af8-96c5-1232c91a0fbc@github.com>

On Wed, 29 Mar 2023 22:51:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small typo fix in Locale.lookupTag
> 
> _tangs_ should be _tags_

This pull request has now been integrated.

Changeset: 5f7b4b8e
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f7b4b8e75fdf4a22c108a0ad528147e924a3ee4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305111: Locale.lookupTag has typo in parameter

Reviewed-by: lancea, iris, naoto

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

PR: https://git.openjdk.org/jdk/pull/13235

From jlu at openjdk.org  Thu Mar 30 22:37:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Mar 2023 22:37:29 GMT
Subject: <i18n dev> Integrated: 8304993: bad sentence break in DateFormat
In-Reply-To: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
References: <cfTRS9cMjdJKX1Qfj27oQs7kkt7g_1T-o8uCVXmx0Yc=.1d30bedd-5981-449c-a80f-af12748cf360@github.com>
Message-ID: <hjMSt8XTlNmAUBElQDRG4q7pQ0waJcZ-KZc62_tn1AA=.54bf1fc9-7d08-4640-ae16-f2b7bf56697f@github.com>

On Tue, 28 Mar 2023 21:01:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a bad sentence break in DateFormat.FIELD AM_PM that caused incomplete API
> 
> Before:
> <img width="1024" alt="Screen Shot 2023-03-27" src="https://user-images.githubusercontent.com/67398801/228359165-f8c66ca2-745b-47ea-bca9-9c4afc7af914.png">
> 
> After:
> <img src="https://user-images.githubusercontent.com/67398801/228358935-9d978a7a-bfa5-42df-85a7-587e39d6c82c.png" width="800" height="40">

This pull request has now been integrated.

Changeset: d8158897
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8158897c3d0dbea46e4f55ad8b501252d88b7e1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8304993: bad sentence break in DateFormat

Reviewed-by: rriggs, naoto, lancea, iris

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

PR: https://git.openjdk.org/jdk/pull/13216

From naoto at openjdk.org  Thu Mar 30 22:44:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 22:44:16 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <6a2ZYG8twjvIWSMNXjFdLra2lXGXoC3R9wyVFL8BAiY=.11396706-6da0-44fb-8e68-3965fd418edd@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Changes in i18n-related classes look good to me.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366032864

From naoto at openjdk.org  Thu Mar 30 23:27:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Mar 2023 23:27:21 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v6]
In-Reply-To: <DudowbbTWR70SJaSMTUKbDKE57RaJSlBvGl-61AZaiw=.3b141092-9815-4cb5-a422-7cc432632e56@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <DudowbbTWR70SJaSMTUKbDKE57RaJSlBvGl-61AZaiw=.3b141092-9815-4cb5-a422-7cc432632e56@github.com>
Message-ID: <OLRpteKoVN1JbpzrwyY6bavyxQWzqn92bdkRH9AnSTk=.704a27f7-105b-4047-8250-1e5fb07866d4@github.com>

On Thu, 30 Mar 2023 21:33:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - dayInMinWeek should range check input and throw exception
>  - Tweak static cal builder

src/java.base/share/classes/java/util/GregorianCalendar.java line 3025:

> 3023:         if (endDay > 7 || endDay < 1 || startDay > 7 || startDay < 1) {
> 3024:             throw new IllegalArgumentException("Start day or end day is not " +
> 3025:                     "a valid day of the week");

Sorry, I take my previous comment back. I think we can simply rely on the return value from `getFirstDayOfWeek()` as it is well-checked, so no need to check the input here. Otherwise the thrown IAE woudl have to end up in `add()/roll()` public methods, which cannot be spec'ed with these internal arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1153877382

From ysatowse at openjdk.org  Fri Mar 31 00:11:22 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 31 Mar 2023 00:11:22 GMT
Subject: <i18n dev> RFR: 8304763: (tz) Update Timezone Data to 2023a
Message-ID: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>

Pleases review this PR. 
The PR includes the following changes.
- tzdata 2023c
- Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

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

Commit messages:
 - 1st commit for tz2023c

Changes: https://git.openjdk.org/jdk/pull/13255/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13255&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304763
  Stats: 333 lines in 18 files changed: 189 ins; 24 del; 120 mod
  Patch: https://git.openjdk.org/jdk/pull/13255.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13255/head:pull/13255

PR: https://git.openjdk.org/jdk/pull/13255

From ysatowse at openjdk.org  Fri Mar 31 00:11:22 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 31 Mar 2023 00:11:22 GMT
Subject: <i18n dev> RFR: 8304763: (tz) Update Timezone Data to 2023a
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <Q6gjI_u18wfKh5zJyaqziZqmXSmatsnB8eloZf4TnjU=.62af5dec-a77f-4ea0-960f-1e80d9006cce@github.com>

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

Please review this PR. @naotoj

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

PR Comment: https://git.openjdk.org/jdk/pull/13255#issuecomment-1491114089

From naoto at openjdk.org  Fri Mar 31 01:11:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 01:11:15 GMT
Subject: <i18n dev> RFR: 8304763: (tz) Update Timezone Data to 2023a
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <zDNNEYKSuCJ5MIpKoCJj-1pumkh3W2CXn2kYTJKDjo8=.f1b9d185-4d2e-4170-9768-cbf3c24e0ee8@github.com>

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

IIUC, this PR is for `2023a` so this should be withdrawn. Instead, you may want to open a PR for https://bugs.openjdk.org/browse/JDK-8305113 which is for `2023c`?

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

PR Comment: https://git.openjdk.org/jdk/pull/13255#issuecomment-1491153257

From ysatowse at openjdk.org  Fri Mar 31 01:51:15 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Fri, 31 Mar 2023 01:51:15 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <Q6gjI_u18wfKh5zJyaqziZqmXSmatsnB8eloZf4TnjU=.62af5dec-a77f-4ea0-960f-1e80d9006cce@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <Q6gjI_u18wfKh5zJyaqziZqmXSmatsnB8eloZf4TnjU=.62af5dec-a77f-4ea0-960f-1e80d9006cce@github.com>
Message-ID: <gJlzl2pbPnArvZ49ZCfwIVTODyBx5vwCtDkH603dH2U=.093f6778-9bb3-4ae6-8257-324a349e9a5b@github.com>

On Fri, 31 Mar 2023 00:02:59 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Please review this PR. @naotoj

> @satoyoshiki The issue `8304763` was not found in the list of additional solved issues. The list currently contains these issues: `8305113`

@naotoj Thanks for the catch.  I mistakenly put the wrong JBS id into `/issue` command.  `8304763` is now removed then the bot has got the review link removed from `JDK-8304763`.  Is this ok for you?

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

PR Comment: https://git.openjdk.org/jdk/pull/13255#issuecomment-1491175416

From darcy at openjdk.org  Fri Mar 31 04:35:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 31 Mar 2023 04:35:15 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <KrmUUZooBBZCX4WnmF1L1WpbI_lU2eXFldn_EMhoqYk=.717ec9fb-f542-48d5-b296-bab253be56bc@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Good to see these changes.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366237224

From alanb at openjdk.org  Fri Mar 31 10:26:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:17 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <nJ6I7j1VirPsWWSI1WgCK6FOVYxFpT163gKO8xzfbHE=.aa845440-9715-45ce-8587-e0112ae249ff@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366677936

From alanb at openjdk.org  Fri Mar 31 10:26:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:26:19 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <dFIqZoerg5agMZaPHvihEiRMSUNPErBqsnj_ShbHVTo=.c4a289a2-db32-401f-83eb-5a3ae05c0afd@github.com>
 <ZXpGUrrQbi53QnGyYTMxbbQfepA4H-RzMTRDkmBAYAg=.41881291-c325-4291-808b-1369730c9869@github.com>
Message-ID: <EWW2GBqSWEKK01g2OWHM3TllOeAbIzNKQbQ_hdTWm0Q=.038c5f4a-b8ca-473d-8f31-3c4c67158432@github.com>

On Thu, 30 Mar 2023 20:28:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1960:
>> 
>>> 1958:      *             thread.
>>> 1959:      *
>>> 1960:      * @spec jni/index.html Java Native Interface Specification
>> 
>> The link to the JNI spec in this method is from implNote so I'm wondering if the spec link is needed here.
>
> Right now, the tag is added for any declaration whose comment contains a reference to an external spec (i.e. with `<a href-....>`. 
> 
> When we enable the "External Specifications" page, it will contain a link back to this page as part of the cross-reference info, which seems useful. That being said, if you feel strongly the tag should not be added here, I can remove it.

Leave it in for now and we can look at it again when the external spec page is in place. My comment is mostly that it will look a bit strange to link to this method because it's text in an implNote rather than spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154302925

From alanb at openjdk.org  Fri Mar 31 10:29:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Mar 2023 10:29:18 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1)
In-Reply-To: <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <AFuAduz4qqk1zQOOajsUEmtpy1XZ18P_95Av_6ZkKgs=.69b361cb-f738-4e62-a764-a21bec7df0f2@github.com>
Message-ID: <ZGHuaYhpb5JLEXLMFrqw2WDNMATOUxwIjrpsurPb23Y=.d06e5ede-f7d4-4565-9e46-4ba049d79db2@github.com>

On Thu, 30 Mar 2023 20:38:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The initial assumption was "after the @param/@return/@throws group". Overall, as I said in the description for this PR, the block tags are not very consistent about ordering. I was thinking we might want to recommend an overall ordering, but I'm worried it would be too intrusive a change to apply generally. In the description, I suggested an ordering based on the order in `Docs.gmk` which defines the order in which tags appear in the generated output.

Okay, I think it's just a few of the usages that I sampled had author tags left over from early JDK releases and they end up between the spec and see tags. We can fix these things up at another time.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491696054

From lancea at openjdk.org  Fri Mar 31 10:36:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:36:17 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Hi Jon,

This looks fine.  I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366691673

From dfuchs at openjdk.org  Fri Mar 31 10:44:17 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 31 Mar 2023 10:44:17 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <xhqVzVaj-GfS0YTdnG0h8FxEyfTmgaC045v38qGZc0o=.cf6e00c7-fb70-468e-a094-7a0cda52aaab@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I had a look at the java.net part and it looks reasonable.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1366700592

From lancea at openjdk.org  Fri Mar 31 10:48:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 31 Mar 2023 10:48:13 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
Message-ID: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>

On Fri, 31 Mar 2023 10:33:50 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi Jon,
> 
> This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?

Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1491723581

From mullan at openjdk.org  Fri Mar 31 16:31:20 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 31 Mar 2023 16:31:20 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

I didn't see any changes to security APIs - are they coming in a follow-on issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492236091

From jlu at openjdk.org  Fri Mar 31 16:39:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 16:39:17 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v7]
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <iDqZMIKh3MOYMmwEyLTE52ctTDkVTIZRzeo1_AQSmGQ=.365c93a8-cf91-423d-8289-2e87f7a8a2df@github.com>

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  getFirstDayInWeek() is well checked, so need for exception in dayInMinWeek

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13031/files
  - new: https://git.openjdk.org/jdk/pull/13031/files/7c9291a3..06b90389

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13031&range=05-06

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13031/head:pull/13031

PR: https://git.openjdk.org/jdk/pull/13031

From jlu at openjdk.org  Fri Mar 31 16:39:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 16:39:19 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v6]
In-Reply-To: <OLRpteKoVN1JbpzrwyY6bavyxQWzqn92bdkRH9AnSTk=.704a27f7-105b-4047-8250-1e5fb07866d4@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <DudowbbTWR70SJaSMTUKbDKE57RaJSlBvGl-61AZaiw=.3b141092-9815-4cb5-a422-7cc432632e56@github.com>
 <OLRpteKoVN1JbpzrwyY6bavyxQWzqn92bdkRH9AnSTk=.704a27f7-105b-4047-8250-1e5fb07866d4@github.com>
Message-ID: <NvCaiEf-sDWrC2D3nQVb3b4nEcW8nYwIgmPBjeE2Khc=.b0e3ca3b-138f-4651-974b-ca62a9a711d8@github.com>

On Thu, 30 Mar 2023 23:20:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - dayInMinWeek should range check input and throw exception
>>  - Tweak static cal builder
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 3025:
> 
>> 3023:         if (endDay > 7 || endDay < 1 || startDay > 7 || startDay < 1) {
>> 3024:             throw new IllegalArgumentException("Start day or end day is not " +
>> 3025:                     "a valid day of the week");
> 
> Sorry, I take my previous comment back. I think we can simply rely on the return value from `getFirstDayOfWeek()` as it is well-checked, so no need to check the input here. Otherwise the thrown IAE woudl have to end up in `add()/roll()` public methods, which cannot be spec'ed with these internal arguments.

No worries, that makes sense. Removed the exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13031#discussion_r1154683765

From naoto at openjdk.org  Fri Mar 31 16:48:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 16:48:21 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <1VwO7D4lktZKW64DaX6vLHnmPcA9NjjS38Keru9HuC8=.6d236924-f398-4067-9e85-2c739fdd766c@github.com>

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

Looks good overall. Please fix a couple of editorial errors.

Changes requested by naoto (Reviewer).

src/java.base/share/data/tzdata/antarctica line 1:

> 1:  #

Extra space

src/java.base/share/data/tzdata/northamerica line 1:

> 1: src/java.base/share/data/tzdata/northamerica #

??? copy/paste error?

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1367269723
PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1367273595
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154692139
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154689466

From iris at openjdk.org  Fri Mar 31 17:22:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 31 Mar 2023 17:22:18 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

Marked as reviewed by iris (Reviewer).

src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:

> 163:  * @see java.io.Serializable
> 164:  * @see java.io.Externalizable
> 165:  * @since       1.1

Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367309978
PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154716150

From mchung at openjdk.org  Fri Mar 31 17:25:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 31 Mar 2023 17:25:16 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
Message-ID: <jmr06nDi3ImVdDXkR2CdZ2RiRqn0Nfk7lDiwR4VNXao=.87f529ea-5d89-4178-916b-f7d9e4bfa445@github.com>

On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

LGTM

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367320601

From naoto at openjdk.org  Fri Mar 31 17:26:19 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 17:26:19 GMT
Subject: <i18n dev> RFR: 8225641: Calendar.roll(int field) does not work
 correctly for WEEK_OF_YEAR [v7]
In-Reply-To: <iDqZMIKh3MOYMmwEyLTE52ctTDkVTIZRzeo1_AQSmGQ=.365c93a8-cf91-423d-8289-2e87f7a8a2df@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
 <iDqZMIKh3MOYMmwEyLTE52ctTDkVTIZRzeo1_AQSmGQ=.365c93a8-cf91-423d-8289-2e87f7a8a2df@github.com>
Message-ID: <oSEEUpxVsKv8eojoP27sEgeA9vECA29C6PC-XIxTmSQ=.f582c67c-f51a-432f-8a5e-02ed553bfa1f@github.com>

On Fri, 31 Mar 2023 16:39:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
>> 
>> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
>> 
>> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   getFirstDayInWeek() is well checked, so need for exception in dayInMinWeek

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13031#pullrequestreview-1367321853

From jjg at openjdk.org  Fri Mar 31 18:29:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:17 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <ex-6LGPg_DEa25AE_zBrm5Ptx24roObUi4IdyDvgNLM=.846ad482-109c-4332-996b-7e9009653c9e@github.com>
 <3S5M70O-gBAryoEdeYdsJPREC-ZAikAMhmhlqdMtrhE=.2b23e947-2137-43d8-b493-ff3837b1025a@github.com>
Message-ID: <E6VI-_KYfAb3rvONO2NokBVCgNRU9Nkb5MRRpBiSXTI=.6228fc9b-37e5-495b-9971-adaacb8a502a@github.com>

On Fri, 31 Mar 2023 10:45:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > Hi Jon,
> > This looks fine. I was wondering if we should do the same for java.util.zip and the PKWare Zip Spec or where java.sql references the JDBC Spec?
> 
> Well, I must need coffee this morning as obviously JDBC is in the java.sql module, not java.base.... So scratch that comment ;-)

The other modules will be done in due course.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492417414

From jjg at openjdk.org  Fri Mar 31 18:29:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 18:29:20 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <MsIJ9F_LHrratAyjmUoPw1pEkxGYRo4L-tAmdkyWt8A=.8cb545c4-1daf-43c7-a4ef-5bc2feaf879d@github.com>
Message-ID: <8CaBH8YGWfkV6NnZtXfTyDI90ZwzCWFF631EnE6sU0A=.7a4acefb-6b85-4f41-a642-e266ab24363f@github.com>

On Fri, 31 Mar 2023 17:14:01 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review feedback
>
> src/java.base/share/classes/java/io/ObjectOutputStream.java line 165:
> 
>> 163:  * @see java.io.Serializable
>> 164:  * @see java.io.Externalizable
>> 165:  * @since       1.1
> 
> Just confirming... The changes to the java.io classes for the Serialization Spec now all point to the index rather than particular chapters/sections. I'm assuming that's intentional so that when the top-level Spec page appears, there is a single entry for that specification.

The `@spec` tag should point to the root, but we should not remove more specific references to within the spec. I will review places where `@see` has been removed/replaced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13248#discussion_r1154774688

From jlu at openjdk.org  Fri Mar 31 21:41:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:41:17 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <UC_eXLH1ZYj0NDyQ-MSY5oRvejr6HAHIznL3Lh7rwOY=.4cb34fe7-3979-454d-8d49-b07b248a5cf7@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Something thing to consider is that Intellj defaults .properties files to ISO 8859-1. 

https://www.jetbrains.com/help/idea/properties-files.html#encoding

So users of Intellj / (other IDEs that default to ISO 8859-1 for .properties files) will need to change the default encoding to utf-8 for such files. Or ideally, the respective IDEs can change their default encoding for .properties files if this change is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492640306

From jlu at openjdk.org  Fri Mar 31 21:45:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:45:21 GMT
Subject: <i18n dev> RFR: 8305400: ISO 4217 Amendment 175 Update
Message-ID: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>

Please review the ISO 4217 amendment 175 update.

There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

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

Commit messages:
 - Update to 175

Changes: https://git.openjdk.org/jdk/pull/13275/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13275&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305400
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13275/head:pull/13275

PR: https://git.openjdk.org/jdk/pull/13275

From duke at openjdk.org  Fri Mar 31 21:50:14 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Fri, 31 Mar 2023 21:50:14 GMT
Subject: <i18n dev> RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
References: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
Message-ID: <Z5u1Da6GNeRN1oWo9D84H7wFprUS2ccsCUPkVDe1gD8=.d4e5ec70-dc87-4c6b-a0f5-310b97786024@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

Do you track the legal tender date? Because that did change, for CLDR https://github.com/unicode-org/cldr/pull/2825

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

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1367657807

From jjg at openjdk.org  Fri Mar 31 22:07:26 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:07:26 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v3]
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  revert removing @see tags where the URL was not the same as the @spec URL

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13248/files
  - new: https://git.openjdk.org/jdk/pull/13248/files/096a4188..7f64cc32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13248&range=01-02

  Stats: 12 lines in 4 files changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13248.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13248/head:pull/13248

PR: https://git.openjdk.org/jdk/pull/13248

From serb at openjdk.org  Fri Mar 31 22:09:16 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 31 Mar 2023 22:09:16 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 742:

> 740: 
> 741:         return new ZoneInfo(zoneId, rawOffset, dstSavings, checksum, transitions,
> 742:                 offsets, params, willGMTOffsetChange);

do we need to change it here?

src/java.base/share/classes/sun/util/resources/TimeZoneNames.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2033, Oracle and/or its affiliates. All rights reserved.

Wrong year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154945016
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1154944389

From naoto at openjdk.org  Fri Mar 31 22:13:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:13:14 GMT
Subject: <i18n dev> RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
References: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
Message-ID: <1FFB2yFyGduBvO4MmuQ2tE0_E8bq0fInuoZKzt4mGg8=.d2c901ad-1e49-4770-ade9-14b47deb2b75@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

Marked as reviewed by naoto (Reviewer).

> Do you track the legal tender date? Because that did change, for CLDR [unicode-org/cldr#2825](https://github.com/unicode-org/cldr/pull/2825)

Hi Steven,
No, JDK does not provide either historical currency information or dates. `Currency.getInstance(Locale)` always returns the new currency during the transition period by default. (Can be manipulated by modifying the `currency.properties` file)

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

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1367677172
PR Comment: https://git.openjdk.org/jdk/pull/13275#issuecomment-1492667558

From duke at openjdk.org  Fri Mar 31 22:17:15 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Fri, 31 Mar 2023 22:17:15 GMT
Subject: <i18n dev> RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
References: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
Message-ID: <ijgRx_zTc_QrtrHOmfUSMJONIdmqtGsiXBfTS70liXk=.b0bc8961-f55b-476c-bbda-3ec3696e7392@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1367679317

From jjg at openjdk.org  Fri Mar 31 22:18:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 22:18:15 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v2]
In-Reply-To: <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <45PBRYoUCLNG7cRceWjb_GDsve5PpvB_vCXb0frLXPg=.dcd02b78-4835-4810-817d-f3ca72e4567a@github.com>
 <xr0fgOmpPj6uUCvuSIiov-DKPYhTxPUEoFRwg-WSd7w=.1dd94a44-30f0-471d-a52a-7b16a431f882@github.com>
Message-ID: <is-v-fguWbSiEU4xVmQNC5S8HrjugCcUZ-LCgO9baSk=.89991275-b806-48d1-8920-08afabb59cab@github.com>

On Fri, 31 Mar 2023 16:28:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I didn't see any changes to security APIs - are they coming in a follow-on issue?

Yes, this is _Add `@spec` tags in java.base/java.* (part 1)_
The rest of `java.base` will be in part 2.

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

PR Comment: https://git.openjdk.org/jdk/pull/13248#issuecomment-1492670942

From naoto at openjdk.org  Fri Mar 31 22:48:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:48:29 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <G-JuA4B7q1ygFjywx4FOwGfJX2Ud-Jf4BwgrzPykvXg=.61ddf6ba-5a7d-45a2-87aa-4613ec3dfb3b@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Hmm, I just wonder why they are sticking to ISO-8859-1 as the default. I know j.u.Properties defaults to 8859-1, but PropertyResourceBundle, which is their primary use defaults to UTF-8 since JDK9 (https://openjdk.org/jeps/226)

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492682703