From serb at openjdk.java.net  Mon Nov  2 09:18:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 09:18:04 GMT
Subject: <i18n dev> RFR: 8211958: Broken links in java.desktop files
In-Reply-To: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
References: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
Message-ID: <419qL9UPahnCzXx_oOMJVGD_ZT3xVzvYCz7M4m0hTBE=.0cd2c408-3de5-4baf-866c-407219a4c96c@github.com>

On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
> This change fix just a few.
> 
> Also two cleanups are applied:
>  - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
>  - The html links to the java classes via `<a href>` replaced by the `{@link }`

src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html line 101:

> 99: 
> 100: The return value is a
> 101: <a href="../../util/Map.html"> Map</a> of

Broken link to Map.

src/java.desktop/share/classes/javax/print/DocFlavor.java line 159:

> 157:  * common flavors, the pre-defined *HOST {@code DocFlavors} may be used.
> 158:  * <p>
> 159:  * See <a href="../../java/lang/package-summary.html#charenc">character

Broken link to the java.base module

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

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

From serb at openjdk.java.net  Mon Nov  2 09:18:03 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 09:18:03 GMT
Subject: <i18n dev> RFR: 8211958: Broken links in java.desktop files
Message-ID: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>

Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
This change fix just a few.

Also two cleanups are applied:
 - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
 - The html links to the java classes via `<a href>` replaced by the `{@link }`

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

Commit messages:
 - Initial fix

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

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

From aivanov at openjdk.java.net  Mon Nov  2 13:17:58 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 2 Nov 2020 13:17:58 GMT
Subject: <i18n dev> RFR: 8211958: Broken links in java.desktop files
In-Reply-To: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
References: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
Message-ID: <e150Fw1azLiOoLczKaGo1EmMsl9Y7yniB2-H644GjN0=.f3b03022-715e-4afa-8e17-7121229fcc0f@github.com>

On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
> This change fix just a few.
> 
> Also two cleanups are applied:
>  - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
>  - The html links to the java classes via `<a href>` replaced by the `{@link }`

Marked as reviewed by aivanov (Reviewer).

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

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

From kravikumar at openjdk.java.net  Mon Nov  2 16:38:00 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 2 Nov 2020 16:38:00 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d
Message-ID: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>

Hi Guys,

Please review the integration of tzdata2020d to JDK.

Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8255226

TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.

Regression Tests pass along with JCK.

Please let me know if the changes are good to push.

Thanks,
Kiran

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

Commit messages:
 - 8255226: (tz) Upgrade time-zone data to tzdata2020d

Changes: https://git.openjdk.java.net/jdk/pull/1012/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1012&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255226
  Stats: 54 lines in 4 files changed: 34 ins; 2 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1012/head:pull/1012

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

From naoto at openjdk.java.net  Mon Nov  2 16:53:54 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 16:53:54 GMT
Subject: <i18n dev> Integrated: 8255671: Bidi.reorderVisually has misleading
 exception messages
In-Reply-To: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
References: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
Message-ID: <URkwSJmYy0wJlQT8LMwJRk9les68gEjUDfiYBbXFMwk=.e0a6e4d3-b930-46d9-9fbf-c86a4a6038a3@github.com>

On Fri, 30 Oct 2020 22:23:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple message fix that follows JDK-8255242.
> 
> Naoto

This pull request has now been integrated.

Changeset: 6dac8d27
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6dac8d27
Stats:     35 lines in 2 files changed: 32 ins; 0 del; 3 mod

8255671: Bidi.reorderVisually has misleading exception messages

Reviewed-by: joehw

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

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

From naoto at openjdk.java.net  Mon Nov  2 17:18:02 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 17:18:02 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>

On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

The test case needs copyright year change to 2020.

test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:

> 199:                 zid.equals("Iran") || // last rule mismatch
> 200:                 zid.equals("Asia/Gaza") || // last rule mismatch
> 201:                 zid.equals("Asia/Hebron")) { // last rule mismatch

Can you explain why these zones are failing? The criteria for excluding failing tests here is that the zone has negative dst and last rules beyond 2037, and I don't think those newly excluded zones suffice those.

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

Changes requested by naoto (Reviewer).

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

From scolebourne at openjdk.java.net  Mon Nov  2 17:44:00 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 2 Nov 2020 17:44:00 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v3]
In-Reply-To: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
Message-ID: <96h7JM1OhKA5v5Bx9qj9n08oRHav8V13E6Uor0m8SVw=.6960968e-0e3a-4ceb-95d0-a293838225ba@github.com>

On Fri, 30 Oct 2020 11:06:59 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed exception messages.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 497:
> 
>> 495:                         AMPM_OF_DAY.checkValidValue(ap);
>> 496:                     }
>> 497:                     updateCheckDayPeriodConflict(AMPM_OF_DAY, midpoint / 720);
> 
> No need to put `AMPM_OF_DAY` back in here because you've already resolved it to `HOUR_OF_DAY` and `MINUTE_OF_HOUR`. There probably does need to be validation to check that the day period agrees with the AM/PM value.

Line can still be removed AFAICT

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

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

From scolebourne at openjdk.java.net  Mon Nov  2 17:44:02 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 2 Nov 2020 17:44:02 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v3]
In-Reply-To: <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
Message-ID: <v6pthmUP-A2POQbI-tGr0Vm-RzG1rZp9A6sp2oyw4z8=.6f4bb8c3-2aef-420a-9a82-796eebb352e3@github.com>

On Fri, 30 Oct 2020 22:03:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed exception messages.

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 656:

> 654:             {"h B", "11 at night", 23},
> 655:             {"h B", "3 at night", 3},
> 656:             {"h B", "11 in the morning", 11},

Need tests for "51 in the morning" (which should parse in LENIENT as "3 in the morning" plus 2 days, see how HOUR_OF_DAY=51 works in general.

Similar issue with HOUR_OF_AMPM=3 and AMPM_OF_DAY=4.

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

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

From scolebourne at openjdk.java.net  Mon Nov  2 17:43:59 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 2 Nov 2020 17:43:59 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v3]
In-Reply-To: <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
Message-ID: <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>

On Fri, 30 Oct 2020 21:30:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/Parsed.java line 472:
>> 
>>> 470:         }
>>> 471:         if (dayPeriod != null) {
>>> 472:             if (fieldValues.containsKey(HOUR_OF_DAY)) {
>> 
>> Are we certain that the CLDR data does not contain day periods based on minutes as well as hours? This logic does not check against MINUTE_OF_HOUR for example. The logic also conflicts with the spec Javadoc that says MINUTE_OF_HOUR is validated.
>
> MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so it is only validated in updateCheckDayPeriodConflict.

But can you get a CLDR rule that says "at night" before 05:30 and "In the morning" from 05:30 onwards? If you can then I don't think it is handled, because HOUR_OF_DAY and MINUTE_OF_HOUR are not used together when checking against DayPeriod.

>> src/java.base/share/classes/java/time/format/Parsed.java line 500:
>> 
>>> 498:                 }
>>> 499:             }
>>> 500:         }
>> 
>> Looking at the existing logic, the `AMPM_OF_DAY` field is completely ignored if there is no `HOUR_OF_AMPM` field. Thus, there is no validation to check `AMPM_OF_DAY` against `HOUR_OF_DAY`. This seems odd. (AMPM_OF_DAY = 0 and HOUR_OF_DAY=18 does not look like it throws an exception, when it probably should).
>> 
>> On solution would be for `AMPM_OF_DAY` to be resolved to a day period at line 427, checking for conflicts with any parsed day period. (a small bug fix behavioural change)
>
> There are cases where a period crosses midnight, e.g., 23:00-04:00 so it cannot validate am/pm, so I decided to just override ampm with dayperiod without validating.

Pulling on this a little more.

As the PR stands, it seems that if the user passes in text with just a day-period of "AM" they get a `LocalTime` of 06:00 but if they pass in `AMPM_OF_DAY` of "AM" the get no `LocalTime` in the result. Is that right? If so, I don't think this is sustainable.

Thats why I think `AMPM_OF_DAY` will have to be resolved to a dayPeriod of "am" or "pm". If dayPeriod is more precise than `AMPM_OF_DAY`, then dayPeriod can silently take precedence

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

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

From kravikumar at openjdk.java.net  Mon Nov  2 18:09:03 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 2 Nov 2020 18:09:03 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d
In-Reply-To: <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
Message-ID: <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>

On Mon, 2 Nov 2020 17:10:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020d to JDK.
>> 
>> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
>> 
>> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
>> 
>> Regression Tests pass along with JCK.
>> 
>> Please let me know if the changes are good to push.
>> 
>> Thanks,
>> Kiran
>
> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
> 
>> 199:                 zid.equals("Iran") || // last rule mismatch
>> 200:                 zid.equals("Asia/Gaza") || // last rule mismatch
>> 201:                 zid.equals("Asia/Hebron")) { // last rule mismatch
> 
> Can you explain why these zones are failing? The criteria for excluding failing tests here is that the zone has negative dst and last rules beyond 2037, and I don't think those newly excluded zones suffice those.

It's probably these last rule what is causing the issue

Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
Rule Palestine	2020	max	-	Oct	Sat>=24	1:00	0	-

The failure seen is 

******************************
Asia/Gaza : Asia/Gaza
    -------------
    SimpleTimeZone (NG)
       stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
      stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=3,endMonth=9,endDay=24,endDayOfWeek=7,endTime=3600000,endTimeMode=0]

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

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

From naoto at openjdk.java.net  Mon Nov  2 18:18:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 18:18:00 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d
In-Reply-To: <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
Message-ID: <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>

On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
>> 
>>> 199:                 zid.equals("Iran") || // last rule mismatch
>>> 200:                 zid.equals("Asia/Gaza") || // last rule mismatch
>>> 201:                 zid.equals("Asia/Hebron")) { // last rule mismatch
>> 
>> Can you explain why these zones are failing? The criteria for excluding failing tests here is that the zone has negative dst and last rules beyond 2037, and I don't think those newly excluded zones suffice those.
>
> It's probably these last rule what is causing the issue
> 
> Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
> Rule Palestine	2020	max	-	Oct	Sat>=24	1:00	0	-
> 
> The failure seen is 
> 
> ******************************
> Asia/Gaza : Asia/Gaza
>     -------------
>     SimpleTimeZone (NG)
>        stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>       stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=3,endMonth=9,endDay=24,endDayOfWeek=7,endTime=3600000,endTimeMode=0]

My question is why it is failing. Have you figured it? The existing exceptions are either negative DST or last rule beyond 2037, which javazic cannot handle. The changes introduced with 2020d does not meet either of them. Unless we know why it is failing, we cannot be sure we can exclude it.

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

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

From serb at openjdk.java.net  Mon Nov  2 19:38:04 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 19:38:04 GMT
Subject: <i18n dev> Integrated: 8211958: Broken links in java.desktop files
In-Reply-To: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
References: <sFnwpabh_Xf5-cpvaIRcW_5pBNaLYnPikdMBjWNrhgU=.86892be0-c298-4c4e-9c7a-504521d638f8@github.com>
Message-ID: <DPYAPjZp3Opiz6Bx1F0D-CNkfLD99KzeQJfcys48tDw=.cadfd814-ceba-459b-9c07-6c08debcc85a@github.com>

On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817
> This change fix just a few.
> 
> Also two cleanups are applied:
>  - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/`
>  - The html links to the java classes via `<a href>` replaced by the `{@link }`

This pull request has now been integrated.

Changeset: acb5f654
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/acb5f654
Stats:     43 lines in 9 files changed: 0 ins; 4 del; 39 mod

8211958: Broken links in java.desktop files

Reviewed-by: aivanov

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

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

From naoto at openjdk.java.net  Mon Nov  2 23:17:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:17:10 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v4]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <qgF4cC9s4vjo_MdB1ix4zsR_9i3y_78pVxzhIkRh9Yc=.119a02c0-5c7b-4584-b05f-28ff3349a2ce@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:

 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516147298
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516123190
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516138455

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/29c47afc..297acc94

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

  Stats: 66 lines in 2 files changed: 53 ins; 3 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From naoto at openjdk.java.net  Mon Nov  2 23:17:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:17:11 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v3]
In-Reply-To: <v6pthmUP-A2POQbI-tGr0Vm-RzG1rZp9A6sp2oyw4z8=.6f4bb8c3-2aef-420a-9a82-796eebb352e3@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
 <v6pthmUP-A2POQbI-tGr0Vm-RzG1rZp9A6sp2oyw4z8=.6f4bb8c3-2aef-420a-9a82-796eebb352e3@github.com>
Message-ID: <kw7i8DY3Sg5tPgZP5mWX9N2auu5m_2ZX4EbdXN0wudY=.c6a1e155-d877-43bf-83a5-d48d8f0f6c4c@github.com>

On Mon, 2 Nov 2020 17:27:35 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed exception messages.
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 656:
> 
>> 654:             {"h B", "11 at night", 23},
>> 655:             {"h B", "3 at night", 3},
>> 656:             {"h B", "11 in the morning", 11},
> 
> Need tests for "51 in the morning" (which should parse in LENIENT as "3 in the morning" plus 2 days, see how HOUR_OF_DAY=51 works in general.
> 
> Similar issue with HOUR_OF_AMPM=3 and AMPM_OF_DAY=4.

Fixed.

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

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

From naoto at openjdk.java.net  Mon Nov  2 23:23:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:23:57 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v4]
In-Reply-To: <96h7JM1OhKA5v5Bx9qj9n08oRHav8V13E6Uor0m8SVw=.6960968e-0e3a-4ceb-95d0-a293838225ba@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <96h7JM1OhKA5v5Bx9qj9n08oRHav8V13E6Uor0m8SVw=.6960968e-0e3a-4ceb-95d0-a293838225ba@github.com>
Message-ID: <Et-GMOCvrHk8WobIWs3kBsi-GDF7mOL9wI2MUjO2cgU=.fe7fc32d-adb5-47b0-98bf-462b74496dae@github.com>

On Mon, 2 Nov 2020 17:08:10 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/Parsed.java line 497:
>> 
>>> 495:                         AMPM_OF_DAY.checkValidValue(ap);
>>> 496:                     }
>>> 497:                     updateCheckDayPeriodConflict(AMPM_OF_DAY, midpoint / 720);
>> 
>> No need to put `AMPM_OF_DAY` back in here because you've already resolved it to `HOUR_OF_DAY` and `MINUTE_OF_HOUR`. There probably does need to be validation to check that the day period agrees with the AM/PM value.
>
> Line can still be removed AFAICT

Fixed.

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

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

From naoto at openjdk.java.net  Mon Nov  2 23:23:56 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:23:56 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v4]
In-Reply-To: <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
Message-ID: <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>

On Mon, 2 Nov 2020 17:05:40 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so it is only validated in updateCheckDayPeriodConflict.
>
> But can you get a CLDR rule that says "at night" before 05:30 and "In the morning" from 05:30 onwards? If you can then I don't think it is handled, because HOUR_OF_DAY and MINUTE_OF_HOUR are not used together when checking against DayPeriod.

CLDR allows rules that involve MINUTE_OF_HOUR. The validation I meant was within the `updateCheckDayPeriodConflict`:
            long hod = fieldValues.get(HOUR_OF_DAY);
            long moh = fieldValues.containsKey(MINUTE_OF_HOUR) ? fieldValues.get(MINUTE_OF_HOUR) : 0;
            long mod =  hod * 60 + moh;
            if (!dayPeriod.includes(mod)) {
                throw new DateTimeException("Conflict found: Resolved time %02d:%02d".formatted(hod, moh) +
                        " conflicts with " + dayPeriod);
            }
which checks both hod/moh. moh is assumed zero if `MINUTE_OF_HOUR` does not exist. Are you suggesting `HOUR_OF_DAY` should also be assumed zero if it does not exist?

>> There are cases where a period crosses midnight, e.g., 23:00-04:00 so it cannot validate am/pm, so I decided to just override ampm with dayperiod without validating.
>
> Pulling on this a little more.
> 
> As the PR stands, it seems that if the user passes in text with just a day-period of "AM" they get a `LocalTime` of 06:00 but if they pass in `AMPM_OF_DAY` of "AM" the get no `LocalTime` in the result. Is that right? If so, I don't think this is sustainable.
> 
> Thats why I think `AMPM_OF_DAY` will have to be resolved to a dayPeriod of "am" or "pm". If dayPeriod is more precise than `AMPM_OF_DAY`, then dayPeriod can silently take precedence

I implemented what you suggested here in the latest PR, but that would be a behavioral change which requires a CSR, as "AM" would be resolved to 06:00 which was not before. Do you think it would be acceptable? If so, I will reopen the CSR and describe the change. (In fact some TCK failed with this impl)

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

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

From kravikumar at openjdk.java.net  Tue Nov  3 00:02:57 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 00:02:57 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d
In-Reply-To: <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
 <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
Message-ID: <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>

On Mon, 2 Nov 2020 18:14:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It's probably these last rule what is causing the issue
>> 
>> Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
>> Rule Palestine	2020	max	-	Oct	Sat>=24	1:00	0	-
>> 
>> The failure seen is 
>> 
>> ******************************
>> Asia/Gaza : Asia/Gaza
>>     -------------
>>     SimpleTimeZone (NG)
>>        stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>>       stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=3,endMonth=9,endDay=24,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>
> My question is why it is failing. Have you figured it? The existing exceptions are either negative DST or last rule beyond 2037, which javazic cannot handle. The changes introduced with 2020d does not meet either of them. Unless we know why it is failing, we cannot be sure we can exclude it.

Thanks for getting back Naoto, I believe this is a long-standing issue - https://bugs.openjdk.java.net/browse/JDK-8227293.

Looking back at the integration of tzdata2019a/tzdata2019b, the same issue was addressed by updating the source code - https://hg.openjdk.java.net/jdk/jdk/rev/79036e5e744b#l13.1. 

Here is some history to the issue - https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html

Please let me know your thoughts

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

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

From naoto at openjdk.java.net  Tue Nov  3 00:24:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 Nov 2020 00:24:00 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d
In-Reply-To: <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
 <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
 <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>
Message-ID: <CWOOoaUdoW42sKioocwW4jZ85zL5EfjZd-vRe1gnuxI=.f5ee6eae-c5cd-44b2-a683-89c0795ab16f@github.com>

On Tue, 3 Nov 2020 00:00:26 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> My question is why it is failing. Have you figured it? The existing exceptions are either negative DST or last rule beyond 2037, which javazic cannot handle. The changes introduced with 2020d does not meet either of them. Unless we know why it is failing, we cannot be sure we can exclude it.
>
> Thanks for getting back Naoto, I believe this is a long-standing issue - https://bugs.openjdk.java.net/browse/JDK-8227293.
> 
> Looking back at the integration of tzdata2019a/tzdata2019b, the same issue was addressed by updating the source code - https://hg.openjdk.java.net/jdk/jdk/rev/79036e5e744b#l13.1. 
> 
> Here is some history to the issue - https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html
> 
> Please let me know your thoughts

Should we then remove the hack in the ZoneInfoFile.java that excludes Gaza/Hebron instead?

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

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

From kravikumar at openjdk.java.net  Tue Nov  3 15:40:12 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 15:40:12 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d [v2]
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <tZ1Aw6hQ_9mTBptxjK6-uySsW_sSeKpJrQrIgja6NX4=.338713e8-ad91-43b3-a3a9-b3c306293f7a@github.com>

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar 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 three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8255226
 - 8255226: Updating ZoneInfoFile.java logic to avoid certain zones
 - 8255226: (tz) Upgrade time-zone data to tzdata2020d

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1012/files
  - new: https://git.openjdk.java.net/jdk/pull/1012/files/e859af83..8782181c

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

  Stats: 2120 lines in 83 files changed: 1178 ins; 580 del; 362 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1012/head:pull/1012

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

From kravikumar at openjdk.java.net  Tue Nov  3 15:42:55 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 15:42:55 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d [v2]
In-Reply-To: <CWOOoaUdoW42sKioocwW4jZ85zL5EfjZd-vRe1gnuxI=.f5ee6eae-c5cd-44b2-a683-89c0795ab16f@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
 <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
 <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>
 <CWOOoaUdoW42sKioocwW4jZ85zL5EfjZd-vRe1gnuxI=.f5ee6eae-c5cd-44b2-a683-89c0795ab16f@github.com>
Message-ID: <y6Y0SwdznkaNjTg9KHy-Txp8ZPeTFhCNHsk9A1303Xs=.ee9e6481-6fc4-4f13-a588-a90b91230103@github.com>

On Tue, 3 Nov 2020 00:21:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Thanks for getting back Naoto, I believe this is a long-standing issue - https://bugs.openjdk.java.net/browse/JDK-8227293.
>> 
>> Looking back at the integration of tzdata2019a/tzdata2019b, the same issue was addressed by updating the source code - https://hg.openjdk.java.net/jdk/jdk/rev/79036e5e744b#l13.1. 
>> 
>> Here is some history to the issue - https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html
>> 
>> Please let me know your thoughts
>
> Should we then remove the hack in the ZoneInfoFile.java that excludes Gaza/Hebron instead?

I had made changes to the ZoneInfoFile.java to avoid applying the logic present to Gaza/Hebron. Regression tests executed successfully.

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

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

From kravikumar at openjdk.java.net  Tue Nov  3 15:49:09 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 15:49:09 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d [v3]
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <VhA15wejTNIaiPen4iI73YmCSTNabvINmiyC1zr8Oqs=.3f14784b-acc7-461f-95bd-397fbc0b8071@github.com>

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar has updated the pull request incrementally with one additional commit since the last revision:

  8255226: Fixing whitespaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1012/files
  - new: https://git.openjdk.java.net/jdk/pull/1012/files/8782181c..e4a565e2

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

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

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

From naoto at openjdk.java.net  Tue Nov  3 18:12:03 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 Nov 2020 18:12:03 GMT
Subject: <i18n dev> RFR: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d [v3]
In-Reply-To: <VhA15wejTNIaiPen4iI73YmCSTNabvINmiyC1zr8Oqs=.3f14784b-acc7-461f-95bd-397fbc0b8071@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <VhA15wejTNIaiPen4iI73YmCSTNabvINmiyC1zr8Oqs=.3f14784b-acc7-461f-95bd-397fbc0b8071@github.com>
Message-ID: <CWPb2P5FXmatgTGcoSfrZxGGtw0Fujeb6fd37hKt8Zk=.f10e89ba-1b7d-4da2-96d9-2967cd74f4a8@github.com>

On Tue, 3 Nov 2020 15:49:09 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020d to JDK.
>> 
>> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
>> 
>> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
>> 
>> Regression Tests pass along with JCK.
>> 
>> Please let me know if the changes are good to push.
>> 
>> Thanks,
>> Kiran
>
> Kiran Sidhartha Ravikumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255226: Fixing whitespaces

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From naoto at openjdk.java.net  Tue Nov  3 18:23:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 Nov 2020 18:23:12 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v5]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <Dj2Tt8VtHoEUpSmMCj5e-EURs66D9SlFDqlLDZu88WI=.329fb314-1c72-4cca-8806-dc49943d86d5@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Fixed TCK test failures, added the new pattern char description in DateTimeFormatter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/297acc94..e52fe51f

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

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

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

From joehw at openjdk.java.net  Wed Nov  4 18:46:57 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 4 Nov 2020 18:46:57 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v5]
In-Reply-To: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
Message-ID: <jEjrbvC0UWHqg_4JKqtrqQewqNwkqxE3HViqOBalA_g=.3cb53665-b5d6-457f-816f-cb8bcdddbc5d@github.com>

On Fri, 30 Oct 2020 11:42:49 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed TCK test failures, added the new pattern char description in DateTimeFormatter
>
> Changes requested by scolebourne (Author).

Since 24:00 is not represented in for example LocalTime and H (hour-of-day) 0-23, it seems obvious midnight in the JDK would be 00:00, and the new DayPeriod tests proves that. The CLDR rule for midnight is also obvious, but the LDML spec does state that it "strongly recommend" that implementations provide for the ability to specify whether midnight is supported or not (and for either 00:00 or 24:00 or both). 

Just wonder whether there is a need to explicitly state the fact about midnight? DateTimeFormatterBuilder::appendInstant() for example, stated clearly how 24:00 is processed, e.g. "The end-of-day time of '24:00' is handled as midnight at the start of the following day."

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

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

From naoto at openjdk.java.net  Wed Nov  4 20:49:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 4 Nov 2020 20:49:57 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v5]
In-Reply-To: <jEjrbvC0UWHqg_4JKqtrqQewqNwkqxE3HViqOBalA_g=.3cb53665-b5d6-457f-816f-cb8bcdddbc5d@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <jEjrbvC0UWHqg_4JKqtrqQewqNwkqxE3HViqOBalA_g=.3cb53665-b5d6-457f-816f-cb8bcdddbc5d@github.com>
Message-ID: <VthlErjstCa3ltZilgl2Xk8OnXqbwZ52LAxtTrhWy2w=.e720dac2-9361-4035-a53d-207d9218fdc8@github.com>

On Wed, 4 Nov 2020 18:44:33 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Changes requested by scolebourne (Author).
>
> Since 24:00 is not represented in for example LocalTime and H (hour-of-day) 0-23, it seems obvious midnight in the JDK would be 00:00, and the new DayPeriod tests proves that. The CLDR rule for midnight is also obvious, but the LDML spec does state that it "strongly recommend" that implementations provide for the ability to specify whether midnight is supported or not (and for either 00:00 or 24:00 or both). 
> 
> Just wonder whether there is a need to explicitly state the fact about midnight? DateTimeFormatterBuilder::appendInstant() for example, stated clearly how 24:00 is processed, e.g. "The end-of-day time of '24:00' is handled as midnight at the start of the following day."

Thanks, Joe. I will incorporate some description about "midnight" in the next update.

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

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

From naoto at openjdk.java.net  Wed Nov  4 22:13:25 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 4 Nov 2020 22:13:25 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v6]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato 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 ten additional commits since the last revision:

 - Merge branch 'master' into dayperiod
 - Change based on CSR change.
 - Fixed TCK test failures, added the new pattern char description in DateTimeFormatter
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516147298
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516123190
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516138455
 - Fixed exception messages.
 - Addressed the following comments:
   - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
   - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
   - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
   - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
   - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
   - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
   - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
   - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
   - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
   - https://github.com/openjdk/jdk/pull/938#discussion_r515039056
 - 8247781: Day periods support

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/e52fe51f..4aa5b197

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

  Stats: 12803 lines in 661 files changed: 7123 ins; 3276 del; 2404 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From kravikumar at openjdk.java.net  Thu Nov  5 11:31:57 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Thu, 5 Nov 2020 11:31:57 GMT
Subject: <i18n dev> Integrated: 8255226: (tz) Upgrade time-zone data to
 tzdata2020d
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <4rYwfKPXXlBxc5V7Ij0-lLBvxPDl7qYtyFtJnPTbL5A=.a3d49bd2-db07-4048-bdce-6bbf378ad9c3@github.com>

On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: b65ff60a
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b65ff60a
Stats:     61 lines in 4 files changed: 38 ins; 2 del; 21 mod

8255226: (tz) Upgrade time-zone data to tzdata2020d

Reviewed-by: naoto

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

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

From rriggs at openjdk.java.net  Thu Nov  5 16:11:55 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 Nov 2020 16:11:55 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v3]
In-Reply-To: <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
Message-ID: <7vZA6TYuo_b7Z4_4OUqCSxYAKLRBUB3F3NGqa6osA8E=.e73908ae-349c-42e1-88e5-6e30cf809bef@github.com>

On Fri, 30 Oct 2020 22:03:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed exception messages.

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/time/format/Parsed.java line 180:

> 178:         cloned.chrono = this.chrono;
> 179:         cloned.leapSecond = this.leapSecond;
> 180:         cloned.dayPeriod= this.dayPeriod;

Add space before "=".

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

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

From rriggs at openjdk.java.net  Thu Nov  5 16:12:03 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 Nov 2020 16:12:03 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v6]
In-Reply-To: <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>
Message-ID: <g0GUXhc7FlezDMeKtmuRgCVljwN6_wrb0CjWv7Xc1Dc=.d6fab1c5-4755-420e-9abf-018c3b4ab0bb@github.com>

On Wed, 4 Nov 2020 22:13:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into dayperiod
>  - Change based on CSR change.
>  - Fixed TCK test failures, added the new pattern char description in DateTimeFormatter
>  - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516147298
>  - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516123190
>  - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516138455
>  - Fixed exception messages.
>  - Addressed the following comments:
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515039056
>  - 8247781: Day periods support

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

> 1477:      * for it in the formatter locale is from 21:00 to 06:00, then {@code HOUR_OF_DAY}
> 1478:      * is set to '1' and {@code MINUTE_OF_HOUR} set to '30'. If {@code AMPM_OF_DAY} exists
> 1479:      * and no {@code HOUR_OF_DAY} is resolved, the parsed day period takes the precedence.

"the precedence" -> "precedence"

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

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

From naoto at openjdk.java.net  Thu Nov  5 17:12:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 17:12:12 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v3]
In-Reply-To: <7vZA6TYuo_b7Z4_4OUqCSxYAKLRBUB3F3NGqa6osA8E=.e73908ae-349c-42e1-88e5-6e30cf809bef@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
 <7vZA6TYuo_b7Z4_4OUqCSxYAKLRBUB3F3NGqa6osA8E=.e73908ae-349c-42e1-88e5-6e30cf809bef@github.com>
Message-ID: <OW3Gc6P5KEakWSysjH8u0KF_0O5Q9Hp3aeatm4CmPBY=.897d0daf-1a1c-440c-9031-8e2b343a5621@github.com>

On Mon, 2 Nov 2020 19:20:10 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 exception messages.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 180:
> 
>> 178:         cloned.chrono = this.chrono;
>> 179:         cloned.leapSecond = this.leapSecond;
>> 180:         cloned.dayPeriod= this.dayPeriod;
> 
> Add space before "=".

Fixed.

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

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

From naoto at openjdk.java.net  Thu Nov  5 17:12:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 17:12:11 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Fixed typo/grammatical error.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/4aa5b197..b0649899

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

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

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

From naoto at openjdk.java.net  Thu Nov  5 17:12:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 17:12:14 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <g0GUXhc7FlezDMeKtmuRgCVljwN6_wrb0CjWv7Xc1Dc=.d6fab1c5-4755-420e-9abf-018c3b4ab0bb@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>
 <g0GUXhc7FlezDMeKtmuRgCVljwN6_wrb0CjWv7Xc1Dc=.d6fab1c5-4755-420e-9abf-018c3b4ab0bb@github.com>
Message-ID: <LPjtLYCQS_oOrfZxxbSdtfVgSJ9UBatJUnQ8izpW40I=.fcf315dc-f66b-4f33-bc6d-66e2222915b3@github.com>

On Thu, 5 Nov 2020 16:07:30 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 typo/grammatical error.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1479:
> 
>> 1477:      * for it in the formatter locale is from 21:00 to 06:00, then {@code HOUR_OF_DAY}
>> 1478:      * is set to '1' and {@code MINUTE_OF_HOUR} set to '30'. If {@code AMPM_OF_DAY} exists
>> 1479:      * and no {@code HOUR_OF_DAY} is resolved, the parsed day period takes the precedence.
> 
> "the precedence" -> "precedence"

Fixed.

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

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

From joehw at openjdk.java.net  Thu Nov  5 17:21:01 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 5 Nov 2020 17:21:01 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
Message-ID: <kvy8Rd-azX7Uaso_x_A5dAl1CZw_NDe3UxrZ_UXlmoA=.5d329b35-4684-4264-bb29-46822fd0d482@github.com>

On Thu, 5 Nov 2020 17:12:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo/grammatical error.

Marked as reviewed by joehw (Reviewer).

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

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

From scolebourne at openjdk.java.net  Thu Nov  5 23:52:02 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 5 Nov 2020 23:52:02 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
Message-ID: <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>

On Thu, 5 Nov 2020 17:12:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo/grammatical error.

test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java line 858:

> 856:         return new Object[][]{
> 857:                 {STRICT, 0, LocalTime.of(6, 0), 0},
> 858:                 {STRICT, 1, LocalTime.of(18, 0), 1},

As mentioned in my other comment, this seems odd in STRICT mode.

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

> 5053:         @Override
> 5054:         public boolean format(DateTimePrintContext context, StringBuilder buf) {
> 5055:             Long value = context.getValue(MINUTE_OF_DAY);

This does not match the spec: " During formatting, the day period is obtained from {@code HOUR_OF_DAY}, and optionally {@code MINUTE_OF_HOUR} if exist"

It is possible and legal to create a Temporal that returns `HOUR_OF_DAY` and `MINUTE_OF_HOUR` but not `MINUTE_OF_DAY`. As such, this method must be changed to follow the spec.

-----

In addition, it is possible for `HOUR_OF_DAY` and `MINUTE_OF_HOUR` to be outside their normal bounds. The right behaviour would be to combine the two fields within this method, and then use mod to get the value into the range 0 to 1440 before calling `dayPeriod.include`. (While the fall back behaviour below does cover this, it would be better to do what I propose here.)

An example of this is a `TransportTime` class where the day runs from 03:00 to 27:00 each day (because trains run after midnight for no extra cost to the passenger, and it is more convenient for the operator to treat the date that way). A `TransportTime` of 26:30 should still resolve to "night1" rather than fall back to "am".

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

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

From scolebourne at openjdk.java.net  Thu Nov  5 23:51:59 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 5 Nov 2020 23:51:59 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
Message-ID: <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>

On Mon, 2 Nov 2020 23:21:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Pulling on this a little more.
>> 
>> As the PR stands, it seems that if the user passes in text with just a day-period of "AM" they get a `LocalTime` of 06:00 but if they pass in `AMPM_OF_DAY` of "AM" the get no `LocalTime` in the result. Is that right? If so, I don't think this is sustainable.
>> 
>> Thats why I think `AMPM_OF_DAY` will have to be resolved to a dayPeriod of "am" or "pm". If dayPeriod is more precise than `AMPM_OF_DAY`, then dayPeriod can silently take precedence
>
> I implemented what you suggested here in the latest PR, but that would be a behavioral change which requires a CSR, as "AM" would be resolved to 06:00 which was not before. Do you think it would be acceptable? If so, I will reopen the CSR and describe the change. (In fact some TCK failed with this impl)

I find the whole "half way between the start and end" behaviour of day periods odd anyway, but if it is to be supported then it should be consistent as you've implemented. 

Another option I should have thought of earlier would be to simply not support the "half way between the start and end" behaviour of LDML in either dayPeriod or AM/PM. But since LDML defines it, you've implemented it, and it isn't overly harmful I think its OK to leave it in.

Would it be possible for STRICT mode to not have the "half way between the start and end" behaviour?

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

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

From naoto at openjdk.java.net  Fri Nov  6 03:03:59 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 03:03:59 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
Message-ID: <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>

On Thu, 5 Nov 2020 23:25:38 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo/grammatical error.
>
> test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java line 858:
> 
>> 856:         return new Object[][]{
>> 857:                 {STRICT, 0, LocalTime.of(6, 0), 0},
>> 858:                 {STRICT, 1, LocalTime.of(18, 0), 1},
> 
> As mentioned in my other comment, this seems odd in STRICT mode.

Did you mean in STRICT mode, HOUR_OF_AMPM should default to 0, and to 6 in SMART/LENIENT modes?

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

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

From scolebourne at openjdk.java.net  Fri Nov  6 09:14:58 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Fri, 6 Nov 2020 09:14:58 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
 <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>
Message-ID: <D0R1WkNIFGKaEtcT66x4msdO0pMMVpKHoAAiG1xmd7E=.213b20a1-0695-4890-b220-a5ff2208d68f@github.com>

On Fri, 6 Nov 2020 03:00:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java line 858:
>> 
>>> 856:         return new Object[][]{
>>> 857:                 {STRICT, 0, LocalTime.of(6, 0), 0},
>>> 858:                 {STRICT, 1, LocalTime.of(18, 0), 1},
>> 
>> As mentioned in my other comment, this seems odd in STRICT mode.
>
> Did you mean in STRICT mode, HOUR_OF_AMPM should default to 0, and to 6 in SMART/LENIENT modes?

No. I mean that when resolving AMPM/dayPeriod in strict mode, and there is no HOUR_OF_DAY or HOUR_OF_AMPM, then do not resolve using "half way between"(ie. fail). This will produce a result where `LocalTime` cannot be obtained.

var f = DateTimeFormatter.ofPattern("B").withResolverStyle(ResolverStyle.STRICT);
var t = LocalTime.from("at night", f);
would throw an exception in STRICT mode (whereas SMART or LENIENT would return a `LocalTime`). Same with pattern "a".

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

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

From naoto at openjdk.java.net  Fri Nov  6 21:12:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 21:12:11 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v8]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <mhZ-mRv8p80kHFCQkQvF92FUkWoByYUXm8zFgkH3vR0=.b66ab4e9-d924-4800-83fe-7624111352f2@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Addressed the following comments:
  - https://github.com/openjdk/jdk/pull/938#discussion_r518431077
  - https://github.com/openjdk/jdk/pull/938#discussion_r518616570
  - https://github.com/openjdk/jdk/pull/938#discussion_r518439782

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/b0649899..8054ce6b

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

  Stats: 28 lines in 4 files changed: 14 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From naoto at openjdk.java.net  Fri Nov  6 21:12:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 21:12:11 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <D0R1WkNIFGKaEtcT66x4msdO0pMMVpKHoAAiG1xmd7E=.213b20a1-0695-4890-b220-a5ff2208d68f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
 <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>
 <D0R1WkNIFGKaEtcT66x4msdO0pMMVpKHoAAiG1xmd7E=.213b20a1-0695-4890-b220-a5ff2208d68f@github.com>
Message-ID: <i7Zo3zBe3iAab5D5KEOuVulO7MpC6x8QlL2ope_WX6Q=.dfd7168c-0134-47b7-bb44-e7ff996bfa9f@github.com>

On Fri, 6 Nov 2020 09:12:38 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Did you mean in STRICT mode, HOUR_OF_AMPM should default to 0, and to 6 in SMART/LENIENT modes?
>
> No. I mean that when resolving AMPM/dayPeriod in strict mode, and there is no HOUR_OF_DAY or HOUR_OF_AMPM, then do not resolve using "half way between"(ie. fail). This will produce a result where `LocalTime` cannot be obtained.
> 
> var f = DateTimeFormatter.ofPattern("B").withResolverStyle(ResolverStyle.STRICT);
> var t = LocalTime.from("at night", f);
> would throw an exception in STRICT mode (whereas SMART or LENIENT would return a `LocalTime`). Same with pattern "a".

Changed to throw an exception in STRICT mode.

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

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

From naoto at openjdk.java.net  Fri Nov  6 21:12:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 21:12:12 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v7]
In-Reply-To: <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
Message-ID: <5fowCEUB6fq9jJPqJ-vc3dHPjBFSBLm8PweNV6ISwZE=.683ddc9d-536f-483c-be69-079a3728a12c@github.com>

On Thu, 5 Nov 2020 23:49:25 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo/grammatical error.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5055:
> 
>> 5053:         @Override
>> 5054:         public boolean format(DateTimePrintContext context, StringBuilder buf) {
>> 5055:             Long value = context.getValue(MINUTE_OF_DAY);
> 
> This does not match the spec: " During formatting, the day period is obtained from {@code HOUR_OF_DAY}, and optionally {@code MINUTE_OF_HOUR} if exist"
> 
> It is possible and legal to create a Temporal that returns `HOUR_OF_DAY` and `MINUTE_OF_HOUR` but not `MINUTE_OF_DAY`. As such, this method must be changed to follow the spec.
> 
> -----
> 
> In addition, it is possible for `HOUR_OF_DAY` and `MINUTE_OF_HOUR` to be outside their normal bounds. The right behaviour would be to combine the two fields within this method, and then use mod to get the value into the range 0 to 1440 before calling `dayPeriod.include`. (While the fall back behaviour below does cover this, it would be better to do what I propose here.)
> 
> An example of this is a `TransportTime` class where the day runs from 03:00 to 27:00 each day (because trains run after midnight for no extra cost to the passenger, and it is more convenient for the operator to treat the date that way). A `TransportTime` of 26:30 should still resolve to "night1" rather than fall back to "am".

Fixed.

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

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

From naoto at openjdk.java.net  Fri Nov  6 22:10:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 22:10:11 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v9]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <W7s-TdlHxXcmpop480lS0hkhJP7JO7aRA2Jkq4Vnxjc=.b4f47eb8-63e3-4055-9ca5-d1f83cd0f34d@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Fixed a comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/8054ce6b..3a9ea64a

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

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

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

From scolebourne at openjdk.java.net  Sat Nov  7 00:01:58 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Sat, 7 Nov 2020 00:01:58 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v9]
In-Reply-To: <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
 <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
Message-ID: <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>

On Thu, 5 Nov 2020 23:24:19 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> I implemented what you suggested here in the latest PR, but that would be a behavioral change which requires a CSR, as "AM" would be resolved to 06:00 which was not before. Do you think it would be acceptable? If so, I will reopen the CSR and describe the change. (In fact some TCK failed with this impl)
>
> I find the whole "half way between the start and end" behaviour of day periods odd anyway, but if it is to be supported then it should be consistent as you've implemented. 
> 
> Another option I should have thought of earlier would be to simply not support the "half way between the start and end" behaviour of LDML in either dayPeriod or AM/PM. But since LDML defines it, you've implemented it, and it isn't overly harmful I think its OK to leave it in.
> 
> Would it be possible for STRICT mode to not have the "half way between the start and end" behaviour?

I've had a look tonight, but found two more problems!

The comments at the start of `resolveTimeLenient()` indicate that setting the midpoint in `resolveTimeFields()` is a bad idea - it needs to be done inside `resolveTimeLenient()`. (This ensures user-defined fields can resolve to ChronoFields IIRC). Thus, the day period resolving would have to be split between the two methods. How important is the midpoint logic? Could it just be dropped?

Secondly, we need to ensure that "24:00 midnight" (using HOUR_OF_DAY only) correctly parses to the end of day midnight, not the start of day or an exception. This is related to the problem above. 

I _think_ (but haven't confirmed everything yet) that the only thing that should be in `resolveTimeFields()` is the resolution of HOUR_OF_AMPM + dayPeriod to HOUR_OF_DAY (with `dayPeriod` then being set to `null`). Everything else should go in `resolveTimeLenient()` - the midpoint logic in the first if block (where time fields are defaulted), and the validation logic at the end of the method.

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

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

From naoto at openjdk.java.net  Mon Nov  9 01:40:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 Nov 2020 01:40:12 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v10]
In-Reply-To: <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
 <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
 <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>
Message-ID: <X1JBy-5Svma-t50EpOmlCYMMrckOUylULK5YdcTWLMI=.d9ebf78e-a648-470e-9e53-2cc102160882@github.com>

On Fri, 6 Nov 2020 23:59:36 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> I find the whole "half way between the start and end" behaviour of day periods odd anyway, but if it is to be supported then it should be consistent as you've implemented. 
>> 
>> Another option I should have thought of earlier would be to simply not support the "half way between the start and end" behaviour of LDML in either dayPeriod or AM/PM. But since LDML defines it, you've implemented it, and it isn't overly harmful I think its OK to leave it in.
>> 
>> Would it be possible for STRICT mode to not have the "half way between the start and end" behaviour?
>
> I've had a look tonight, but found two more problems!
> 
> The comments at the start of `resolveTimeLenient()` indicate that setting the midpoint in `resolveTimeFields()` is a bad idea - it needs to be done inside `resolveTimeLenient()`. (This ensures user-defined fields can resolve to ChronoFields IIRC). Thus, the day period resolving would have to be split between the two methods. How important is the midpoint logic? Could it just be dropped?
> 
> Secondly, we need to ensure that "24:00 midnight" (using HOUR_OF_DAY only) correctly parses to the end of day midnight, not the start of day or an exception. This is related to the problem above. 
> 
> I _think_ (but haven't confirmed everything yet) that the only thing that should be in `resolveTimeFields()` is the resolution of HOUR_OF_AMPM + dayPeriod to HOUR_OF_DAY (with `dayPeriod` then being set to `null`). Everything else should go in `resolveTimeLenient()` - the midpoint logic in the first if block (where time fields are defaulted), and the validation logic at the end of the method.

Thanks for the insights. I believe I fixed both of the issues with the new commit.

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

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

From naoto at openjdk.java.net  Mon Nov  9 01:40:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 Nov 2020 01:40:11 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v10]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <Z_y8oHtX5z7xiMv47vPMIJm0YGw097bemeR2G9c6rTA=.90f6c639-d908-4f1b-a3a0-9ee97a97b0ac@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Addressing https://github.com/openjdk/jdk/pull/938#discussion_r519061476

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/3a9ea64a..7140ae27

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

  Stats: 90 lines in 3 files changed: 56 ins; 34 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From naoto at openjdk.java.net  Tue Nov 10 00:07:16 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 Nov 2020 00:07:16 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v11]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Clarified 24:00 for "midnight" type in the spec. Some clean up.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/7140ae27..ccefe70c

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

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

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

From naoto at openjdk.java.net  Tue Nov 10 19:52:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 Nov 2020 19:52:14 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v12]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Added a test case for user defined temporal field resolution with day period.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/ccefe70c..a960804f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=10-11

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

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

From naoto at openjdk.java.net  Tue Nov 10 19:58:58 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 Nov 2020 19:58:58 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v12]
In-Reply-To: <X1JBy-5Svma-t50EpOmlCYMMrckOUylULK5YdcTWLMI=.d9ebf78e-a648-470e-9e53-2cc102160882@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
 <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
 <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>
 <X1JBy-5Svma-t50EpOmlCYMMrckOUylULK5YdcTWLMI=.d9ebf78e-a648-470e-9e53-2cc102160882@github.com>
Message-ID: <dGOjTGi3zRqT0NFo3Xqugst4_CQrMuTnexFMAQY6A_A=.9865e7b4-2a14-4b24-85a2-09555f42ac15@github.com>

On Mon, 9 Nov 2020 01:37:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I've had a look tonight, but found two more problems!
>> 
>> The comments at the start of `resolveTimeLenient()` indicate that setting the midpoint in `resolveTimeFields()` is a bad idea - it needs to be done inside `resolveTimeLenient()`. (This ensures user-defined fields can resolve to ChronoFields IIRC). Thus, the day period resolving would have to be split between the two methods. How important is the midpoint logic? Could it just be dropped?
>> 
>> Secondly, we need to ensure that "24:00 midnight" (using HOUR_OF_DAY only) correctly parses to the end of day midnight, not the start of day or an exception. This is related to the problem above. 
>> 
>> I _think_ (but haven't confirmed everything yet) that the only thing that should be in `resolveTimeFields()` is the resolution of HOUR_OF_AMPM + dayPeriod to HOUR_OF_DAY (with `dayPeriod` then being set to `null`). Everything else should go in `resolveTimeLenient()` - the midpoint logic in the first if block (where time fields are defaulted), and the validation logic at the end of the method.
>
> Thanks for the insights. I believe I fixed both of the issues with the new commit.

Added a test case with the latest commit: https://github.com/openjdk/jdk/commit/a960804ff4d3f7df18e51fe59dcdcaf04542e10a

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

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

From rriggs at openjdk.java.net  Thu Nov 12 15:25:01 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 15:25:01 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v12]
In-Reply-To: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
Message-ID: <yVqa9HYTETWD3jT8iB_le0HwuMeMnkNkT8Hln7Zmo9I=.0b1ccc6e-bfa5-4077-bfd2-659632158441@github.com>

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a test case for user defined temporal field resolution with day period.

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 877:

> 875:         try {
> 876:             dtf.parse("0 at night");
> 877:             throw new RuntimeException("DateTimeParseException should be thrown");

Testng has `Assert.fail(message)` for this case.

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

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

From rriggs at openjdk.java.net  Thu Nov 12 15:25:00 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 15:25:00 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v11]
In-Reply-To: <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>
Message-ID: <Z1cjTmu9oi3nWjDDPp6IxJZz93dDmR6jsSSiroE-bJc=.053d3352-a793-43e2-8365-4421aee4ce4c@github.com>

On Tue, 10 Nov 2020 00:07:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarified 24:00 for "midnight" type in the spec. Some clean up.

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

> 1481:      * exception is thrown and the day period is ignored.
> 1482:      * <p>
> 1483:      * "midnight" type allows both "00:00" as the start-of-day and "24:00" as the

Editorial:  Add "The " at the beginning of the sentence.

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

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

From rriggs at openjdk.java.net  Thu Nov 12 15:45:05 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 15:45:05 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v12]
In-Reply-To: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
Message-ID: <XFs7_BF2vg0EP9x0Bt6KYlmmTJsqRkPwwJYqyDz60yI=.b786b60e-55af-492f-85d7-96788096a337@github.com>

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a test case for user defined temporal field resolution with day period.

Marked as reviewed by rriggs (Reviewer).

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

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

From scolebourne at openjdk.java.net  Thu Nov 12 17:07:05 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 12 Nov 2020 17:07:05 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v12]
In-Reply-To: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
Message-ID: <QmM8ovyIghPebG9hVAeHvTSBfeRPt-noT9AF6tvv6Rs=.3d4f6cdd-af86-4342-abf1-9672b752e6bf@github.com>

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a test case for user defined temporal field resolution with day period.

src/java.base/share/classes/java/time/format/Parsed.java line 550:

> 548:                     long midpoint = dayPeriod.mid();
> 549:                     fieldValues.put(HOUR_OF_DAY, midpoint / 60);
> 550:                     fieldValues.put(MINUTE_OF_HOUR, midpoint % 60);

Set `dayPeriod = null` here, as it has been successfully used.

src/java.base/share/classes/java/time/format/Parsed.java line 502:

> 500:                 HOUR_OF_AMPM.checkValidValue(hoap);
> 501:             }
> 502:             if (dayPeriod.includes((hoap % 24 + 12) * 60)) {

Pretty sure the 24 should be 12.

Also, it should use `Math.floorMod()` to handle `HOUR_OF_AMPM = -1` (which is 11 o'clock).

Also, this doesn't take into account minutes. So if the day period rule is afternoon1 to 18:30 and evening1 after 18:30, and the input is `HOUR_OF_AMPM = 6, MINUTE_OF_HOUR = 45`, this will fail to resolve,

Something like this should work (no need for `updateCheckDayPeriodConflict`):

    long hoap = fieldValues.remove(HOUR_OF_AMPM);
    if (resolverStyle == ResolverStyle.LENIENT) {
      HOUR_OF_AMPM.checkValidValue(hoap);
    }
    Long mohObj = fieldValues.get(MINUTE_OF_HOUR);
    long moh = mohObj != null ? Math.floorMod(mohObj, 60) : 0;
    long excessHours = dayPeriod.includes(Math.floorMod(hoap, 12) + 12 * 60 + moh ? 12 : 0;
    long hod = Math.addExact(hoap, excessHours);
    updateCheckConflict(HOUR_OF_AMPM, HOUR_OF_DAY, hod);
    dayPeriod = null;

src/java.base/share/classes/java/time/format/Parsed.java line 546:

> 544: 
> 545:             // Set the hour-of-day, if not exist and not in STRICT, to the mid point of the day period or am/pm.
> 546:             if (!fieldValues.containsKey(HOUR_OF_DAY) && resolverStyle != ResolverStyle.STRICT) {

Since this logic replaces both `HOUR_OF_DAY` and `MINUTE_OF_HOUR` I think it should only be invoked if both do not exist. Beyond that, it doesn't really make sense to do this logic if second/sub-second are present. Thus, it needs to check all four fields and can then directly set the time.

    if (!fieldValues.containsKey(HOUR_OF_DAY) && 
        !fieldValues.containsKey(MINUTE_OF_HOUR) && 
        !fieldValues.containsKey(SECOND_OF_MINUTE) && 
        !fieldValues.containsKey(NANO_OF_SECOND) && 
        resolverStyle != ResolverStyle.STRICT) {

      if (dayPeriod != null) {
        long midpoint = dayPeriod.mid();
        resolveTime(midpoint / 60, midpoint % 60, 0, 0);
        dayPeriod = null;
      } else if (fieldValues.containsKey(AMPM_OF_DAY)) {
        long ap = fieldValues.remove(AMPM_OF_DAY);
        if (resolverStyle == ResolverStyle.LENIENT) {
          resolveTime(Math.addExact(Math.multiplyExact(ap, 12), 6), 0, 0, 0);
        } else {  // SMART
          AMPM_OF_DAY.checkValidValue(ap);
          resolveTime(ap * 12 + 6, 0, 0, 0);
    }

src/java.base/share/classes/java/time/format/Parsed.java line 568:

> 566:                 if (dayPeriod != null) {
> 567:                     // Check whether the hod is within the day period
> 568:                     updateCheckDayPeriodConflict(HOUR_OF_DAY, hod);

With the other changes, this is the only use of this method and it can therefore be simplified (no need to check for conflicts, just whether it matches the day period).

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 778:

> 776:                 {"h B", ResolverStyle.SMART, "59 in the morning", 11},
> 777: 
> 778:                 {"H B", ResolverStyle.LENIENT, "47 at night", 23},

This test should be split in two - smart (fails) and lenient (succeeds). The lenient tests should ensure that `p.query(DateTimeFormatter.parsedExcessDays())` returns the expected number of excess days. 

I'd also add a test for a negative value such as "-2 at night"

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

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

From herrick at openjdk.java.net  Thu Nov 12 18:32:02 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 18:32:02 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

preliminary changes for JDK-8189198 for evaluation

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

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

From herrick at openjdk.java.net  Thu Nov 12 18:32:02 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 18:32:02 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
Message-ID: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>

JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Commit messages:
 - Merge branch 'master' into JDK-8189198
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs

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

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

From kcr at openjdk.java.net  Thu Nov 12 19:22:01 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Nov 2020 19:22:01 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <j3MK4sBx_azdu0U4AH9Ys6cO9i7225Sku6Qqzy5CiyU=.05465f80-fd5b-46fd-821f-e3d8f07b2527@github.com>
Message-ID: <GvP5LlxK0ocbdaxXbPDFAtX1v3sIZav1dHpSi54EEdg=.e2f907f8-d9e5-4910-be6a-6ec83f9d1ef9@github.com>

On Mon, 9 Nov 2020 13:57:32 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> preliminary changes for JDK-8189198 for evaluation

The following field, which is currently deprecated (not for removal) should probably also be marked as deprecated for removal::

javax.naming.Context:
    static final String APPLET

The CSR and JEP should be updated accordingly.

Also, what about the following?

javax.swing.text.html.parser.DTD
    Element applet

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

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

From iris at openjdk.java.net  Thu Nov 12 19:40:54 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 12 Nov 2020 19:40:54 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <1hu3mjRsBg1gnnWXUNl9TQ8PoPFjmGOaXkr6Vdd4mOo=.7ead6f18-6b34-42e4-adfb-756ada49eb61@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Since all APIs in the java.applet package are deprecated "forRemoval = true", consider adding a brief deprecation note to java/applet/package-info.java too.

As an example, when all of the APIs in package java.rmi.activation were similarly deprecated in JDK 15, the following note was added: 

https://docs.oracle.com/en/java/javase/15/docs/api/java.rmi/java/rmi/activation/package-summary.html .

Thanks!
Iris

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

Marked as reviewed by iris (Reviewer).

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

From naoto at openjdk.java.net  Thu Nov 12 20:03:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:03:14 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v13]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Addressed the following comments:
  - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
  - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
  - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
  - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
  - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
  - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
  - https://github.com/openjdk/jdk/pull/938#discussion_r522266836

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/a960804f..570b4582

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=11-12

  Stats: 75 lines in 3 files changed: 23 ins; 23 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From naoto at openjdk.java.net  Thu Nov 12 20:09:08 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:09:08 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v12]
In-Reply-To: <QmM8ovyIghPebG9hVAeHvTSBfeRPt-noT9AF6tvv6Rs=.3d4f6cdd-af86-4342-abf1-9672b752e6bf@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
 <QmM8ovyIghPebG9hVAeHvTSBfeRPt-noT9AF6tvv6Rs=.3d4f6cdd-af86-4342-abf1-9672b752e6bf@github.com>
Message-ID: <YxXizzeh3_HVnp09-Efvf9JcvD4is2-UF1sUjH-jK_c=.0f601ede-9ef5-4146-8fe5-5d4afbda88ad@github.com>

On Thu, 12 Nov 2020 15:41:56 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a test case for user defined temporal field resolution with day period.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 550:
> 
>> 548:                     long midpoint = dayPeriod.mid();
>> 549:                     fieldValues.put(HOUR_OF_DAY, midpoint / 60);
>> 550:                     fieldValues.put(MINUTE_OF_HOUR, midpoint % 60);
> 
> Set `dayPeriod = null` here, as it has been successfully used.

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 502:
> 
>> 500:                 HOUR_OF_AMPM.checkValidValue(hoap);
>> 501:             }
>> 502:             if (dayPeriod.includes((hoap % 24 + 12) * 60)) {
> 
> Pretty sure the 24 should be 12.
> 
> Also, it should use `Math.floorMod()` to handle `HOUR_OF_AMPM = -1` (which is 11 o'clock).
> 
> Also, this doesn't take into account minutes. So if the day period rule is afternoon1 to 18:30 and evening1 after 18:30, and the input is `HOUR_OF_AMPM = 6, MINUTE_OF_HOUR = 45`, this will fail to resolve,
> 
> Something like this should work (no need for `updateCheckDayPeriodConflict`):
> 
>     long hoap = fieldValues.remove(HOUR_OF_AMPM);
>     if (resolverStyle == ResolverStyle.LENIENT) {
>       HOUR_OF_AMPM.checkValidValue(hoap);
>     }
>     Long mohObj = fieldValues.get(MINUTE_OF_HOUR);
>     long moh = mohObj != null ? Math.floorMod(mohObj, 60) : 0;
>     long excessHours = dayPeriod.includes(Math.floorMod(hoap, 12) + 12 * 60 + moh ? 12 : 0;
>     long hod = Math.addExact(hoap, excessHours);
>     updateCheckConflict(HOUR_OF_AMPM, HOUR_OF_DAY, hod);
>     dayPeriod = null;

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 546:
> 
>> 544: 
>> 545:             // Set the hour-of-day, if not exist and not in STRICT, to the mid point of the day period or am/pm.
>> 546:             if (!fieldValues.containsKey(HOUR_OF_DAY) && resolverStyle != ResolverStyle.STRICT) {
> 
> Since this logic replaces both `HOUR_OF_DAY` and `MINUTE_OF_HOUR` I think it should only be invoked if both do not exist. Beyond that, it doesn't really make sense to do this logic if second/sub-second are present. Thus, it needs to check all four fields and can then directly set the time.
> 
>     if (!fieldValues.containsKey(HOUR_OF_DAY) && 
>         !fieldValues.containsKey(MINUTE_OF_HOUR) && 
>         !fieldValues.containsKey(SECOND_OF_MINUTE) && 
>         !fieldValues.containsKey(NANO_OF_SECOND) && 
>         resolverStyle != ResolverStyle.STRICT) {
> 
>       if (dayPeriod != null) {
>         long midpoint = dayPeriod.mid();
>         resolveTime(midpoint / 60, midpoint % 60, 0, 0);
>         dayPeriod = null;
>       } else if (fieldValues.containsKey(AMPM_OF_DAY)) {
>         long ap = fieldValues.remove(AMPM_OF_DAY);
>         if (resolverStyle == ResolverStyle.LENIENT) {
>           resolveTime(Math.addExact(Math.multiplyExact(ap, 12), 6), 0, 0, 0);
>         } else {  // SMART
>           AMPM_OF_DAY.checkValidValue(ap);
>           resolveTime(ap * 12 + 6, 0, 0, 0);
>     }

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 568:
> 
>> 566:                 if (dayPeriod != null) {
>> 567:                     // Check whether the hod is within the day period
>> 568:                     updateCheckDayPeriodConflict(HOUR_OF_DAY, hod);
> 
> With the other changes, this is the only use of this method and it can therefore be simplified (no need to check for conflicts, just whether it matches the day period).

Fixed.

> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 778:
> 
>> 776:                 {"h B", ResolverStyle.SMART, "59 in the morning", 11},
>> 777: 
>> 778:                 {"H B", ResolverStyle.LENIENT, "47 at night", 23},
> 
> This test should be split in two - smart (fails) and lenient (succeeds). The lenient tests should ensure that `p.query(DateTimeFormatter.parsedExcessDays())` returns the expected number of excess days. 
> 
> I'd also add a test for a negative value such as "-2 at night"

Fixed.

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

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

From naoto at openjdk.java.net  Thu Nov 12 20:09:05 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:09:05 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v12]
In-Reply-To: <yVqa9HYTETWD3jT8iB_le0HwuMeMnkNkT8Hln7Zmo9I=.0b1ccc6e-bfa5-4077-bfd2-659632158441@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
 <yVqa9HYTETWD3jT8iB_le0HwuMeMnkNkT8Hln7Zmo9I=.0b1ccc6e-bfa5-4077-bfd2-659632158441@github.com>
Message-ID: <UFcLrQMiiUoq04bIvT3Nv1FP8-ZL4FuTwto1pF5ViCw=.f766ffdb-cad8-41b1-b860-1965dc3c92f8@github.com>

On Thu, 12 Nov 2020 15:21:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a test case for user defined temporal field resolution with day period.
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 877:
> 
>> 875:         try {
>> 876:             dtf.parse("0 at night");
>> 877:             throw new RuntimeException("DateTimeParseException should be thrown");
> 
> Testng has `Assert.fail(message)` for this case.

Fixed.

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

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

From naoto at openjdk.java.net  Thu Nov 12 20:09:04 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:09:04 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v11]
In-Reply-To: <Z1cjTmu9oi3nWjDDPp6IxJZz93dDmR6jsSSiroE-bJc=.053d3352-a793-43e2-8365-4421aee4ce4c@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>
 <Z1cjTmu9oi3nWjDDPp6IxJZz93dDmR6jsSSiroE-bJc=.053d3352-a793-43e2-8365-4421aee4ce4c@github.com>
Message-ID: <l8H--FnpRHlCx9Kt2HSNPMha0czgRZWHBYeH_LA3q30=.5b1aa0e4-79ac-43d9-ada9-e58e0b2700bc@github.com>

On Thu, 12 Nov 2020 15:18:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarified 24:00 for "midnight" type in the spec. Some clean up.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1483:
> 
>> 1481:      * exception is thrown and the day period is ignored.
>> 1482:      * <p>
>> 1483:      * "midnight" type allows both "00:00" as the start-of-day and "24:00" as the
> 
> Editorial:  Add "The " at the beginning of the sentence.

Fixed.

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

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

From herrick at openjdk.java.net  Thu Nov 12 20:48:13 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 20:48:13 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick 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 six additional commits since the last revision:

 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - Merge branch 'master' into JDK-8189198
 - Merge branch 'master' into JDK-8189198
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/a74deeee..d9850cd8

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

  Stats: 7753 lines in 89 files changed: 4891 ins; 1603 del; 1259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

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

From scolebourne at openjdk.java.net  Thu Nov 12 22:01:01 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 12 Nov 2020 22:01:01 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v13]
In-Reply-To: <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>
Message-ID: <aCQlAaZ5H4ZFpGmesZNHQzWiLgXARGwEeRhTWKm0hMg=.dc7244d4-151e-4cdc-af92-4e6fc4d39d9a@github.com>

On Thu, 12 Nov 2020 20:03:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed the following comments:
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522266836

Approved with one overflow to fix.

The spec could do with some rewording too. It might be better to explicitly mention the "resolving phase" with the three parts:

> The day period is combined with other fields to make a `LocalTime` in the resolving phase. If the `HOUR_OF_AMPM` field is present, it is combined with the day period to make `HOUR_OF_DAY` taking into account any `MINUTE_OF_HOUR` value. If `HOUR_OF_DAY` is present, it is validated against the day period taking into account any `MINUTE_OF_HOUR` value. If a day period is present without `HOUR_OF_DAY`, `MINUTE_OF_HOUR`, `SECOND_OF_MINUTE` and `NANO_OF_SECOND` then the midpoint of the day period is set as the time.

Note that the above is incomplete, and it doesn't describe STRICT/LENIENT, so the actual words will be more complex,

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

> 5061:             }
> 5062:             Long moh = context.getValue(MINUTE_OF_HOUR);
> 5063:             long value = (hod * 60 + (moh != null ? moh : 0)) % 1_440;

`long value = Math.floorMod(hod, 24) * 60 + (moh != null ? Math.floorMod(moh, 60) : 0);`

and remove the next three lines

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

Marked as reviewed by scolebourne (Author).

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

From naoto at openjdk.java.net  Thu Nov 12 23:11:15 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 23:11:15 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v13]
In-Reply-To: <aCQlAaZ5H4ZFpGmesZNHQzWiLgXARGwEeRhTWKm0hMg=.dc7244d4-151e-4cdc-af92-4e6fc4d39d9a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>
 <aCQlAaZ5H4ZFpGmesZNHQzWiLgXARGwEeRhTWKm0hMg=.dc7244d4-151e-4cdc-af92-4e6fc4d39d9a@github.com>
Message-ID: <Mq0wVmNZDvzm8zC9fBGPN0_vePntMqjF2OFbOPUNHdI=.e59b133c-a678-44d6-b07a-abddd88fafd3@github.com>

On Thu, 12 Nov 2020 21:49:16 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed the following comments:
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522266836
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5063:
> 
>> 5061:             }
>> 5062:             Long moh = context.getValue(MINUTE_OF_HOUR);
>> 5063:             long value = (hod * 60 + (moh != null ? moh : 0)) % 1_440;
> 
> `long value = Math.floorMod(hod, 24) * 60 + (moh != null ? Math.floorMod(moh, 60) : 0);`
> 
> and remove the next three lines

Thanks, Stephen. I made the changes based on your comments.

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

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

From naoto at openjdk.java.net  Thu Nov 12 23:11:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 23:11:14 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v14]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <lyoWXiAsNIlmnVAYYdCL4_PcMxIz34pArDsner113_U=.d2416b09-c158-4b25-955b-ef1d09dd7b86@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Re-worded the spec of appendDayPeriodText, refactored calculation of minute-of-day.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/570b4582..1aa3134f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=12-13

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

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

From almatvee at openjdk.java.net  Thu Nov 12 23:52:56 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 12 Nov 2020 23:52:56 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <JVMXf2S7V5H6rariy6z8YkOGlh3YAtu2O6TWup0KeyY=.729335e8-4acc-4146-be1f-f5329cd98caf@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick 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 six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

Marked as reviewed by almatvee (Committer).

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

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

From kcr at openjdk.java.net  Fri Nov 13 00:27:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 00:27:58 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <Ycx4b7aaw5u8aiSS2NkJhWpuXdQjIRVbEn4DZautriM=.bbab7054-a46f-49c7-b8b7-ee0174aaa8b8@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

@andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer.

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

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

From alanb at openjdk.java.net  Fri Nov 13 09:35:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 Nov 2020 09:35:00 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick 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 six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.naming/share/classes/javax/naming/Context.java line 1087:

> 1085:     @Deprecated(since="16", forRemoval=true)
> 1086:     String APPLET = "java.naming.applet";
> 1087: };

Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

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

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

From herrick at openjdk.java.net  Fri Nov 13 15:05:15 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 15:05:15 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/d9850cd8..c6ea7714

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

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

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

From kcr at openjdk.java.net  Fri Nov 13 18:03:59 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:03:59 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
Message-ID: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>

On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andy Herrick 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 six additional commits since the last revision:
>> 
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - Merge branch 'master' into JDK-8189198
>>  - Merge branch 'master' into JDK-8189198
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.naming/share/classes/javax/naming/Context.java line 1087:
> 
>> 1085:     @Deprecated(since="16", forRemoval=true)
>> 1086:     String APPLET = "java.naming.applet";
>> 1087: };
> 
> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

Good point, since it was in fact deprecated in 9.

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

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

From kcr at openjdk.java.net  Fri Nov 13 18:23:02 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:23:02 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
Message-ID: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>

On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.desktop/share/classes/java/applet/package-info.java line 40:

> 38:  * <p>
> 39:  * Deprecated.
> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.

That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

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

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

From herrick at openjdk.java.net  Fri Nov 13 18:22:59 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 18:22:59 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v2]
In-Reply-To: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
 <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
Message-ID: <gYa0bATGPUhfwxiRzpSFAjvkqohOGexGE2wtQOhzU2A=.0686d174-96f9-48c3-8bce-2222bdf38e3b@github.com>

On Fri, 13 Nov 2020 18:01:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> src/java.naming/share/classes/javax/naming/Context.java line 1087:
>> 
>>> 1085:     @Deprecated(since="16", forRemoval=true)
>>> 1086:     String APPLET = "java.naming.applet";
>>> 1087: };
>> 
>> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).
>
> Good point, since it was in fact deprecated in 9.

yes - changed to since="9" this morning

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

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

From igraves at openjdk.java.net  Fri Nov 13 22:32:17 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 22:32:17 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v6]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <2mQzlvikTfBI9wGHRly2GopMAJ1YQwYvkmap-Kz4Ilc=.37dc7834-f1f3-49c8-8ff6-4bbb4b9b7b87@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves 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 14 additional commits since the last revision:

 - Merge branch 'format-string-numeric-bound' of github.com:igraves/jdk into format-string-numeric-bound
 - Additional specificity around width
 - Tweaking verbiage
 - Updating docs specifying exception for 0 indices
 - Throwing exceptions for zeroth indexes
 - Updating docs
 - Updating docs and throwing errors accordingly
 - Making IllegalFormatArgumentIndexException package private
 - Additional specificity around width
 - Tweaking verbiage
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/96b6dcaf...a84d3f2f

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/0526ef43..a84d3f2f

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

  Stats: 302178 lines in 580 files changed: 296317 ins; 3588 del; 2273 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

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

From igraves at openjdk.java.net  Fri Nov 13 23:10:08 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 23:10:08 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v7]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <HMrF3ymlCBI25gzG8RR-8-pmf1L_T5VrxsFXx3MSrNE=.bbc51a3d-ae9c-4d98-9239-190baf3ebc05@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Making IllegalFormatArgumentIndexException package private
 - Additional specificity around width
 - Tweaking verbiage
 - Updating docs specifying exception for 0 indices
 - Throwing exceptions for zeroth indexes
 - Updating docs
 - Updating docs and throwing errors accordingly

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

Changes: https://git.openjdk.java.net/jdk/pull/516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=06
  Stats: 94 lines in 4 files changed: 86 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

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

From igraves at openjdk.java.net  Fri Nov 13 23:12:56 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 23:12:56 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v7]
In-Reply-To: <rWfrZZY9p0Y97KCo6tSmK0vYrHrzqTWAAn4NzLtY8L8=.9ccce67d-a400-4fbc-b7d6-b2cb78f8d014@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>
 <rWfrZZY9p0Y97KCo6tSmK0vYrHrzqTWAAn4NzLtY8L8=.9ccce67d-a400-4fbc-b7d6-b2cb78f8d014@github.com>
Message-ID: <PNbzBDrPGFq_Gb0XF9SpOHEKP9xgnSA2tceK5tJWduk=.857ea2b3-8ef2-4aad-854e-7234ff3f8b10@github.com>

On Tue, 6 Oct 2020 19:10:46 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Is the new exception type useful?  yes, it matches the previous pattern.
>> But it does not (and none of the IllegalFormatException subclasses) produce a readable message with the offending value. So the developer will not see anything useful.
>> The fine grained exceptions provide little value.
>
> I've been on the fence about this, personally. The Formatter uses pretty fine-grained exception types for error conditions. I'd be okay discontinuing this practice here, but am not sure what to replace this with. Perhaps we enable `IllegalFormatException` to be, itself, public and instantiable ?

Updates (including cleaning up some git weirdness with rebasing) include adherence to the new CSR draft proposal. This makes the new exception type package-private.

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

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

From serb at openjdk.java.net  Fri Nov 13 23:29:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 23:29:59 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v3]
In-Reply-To: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
 <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
Message-ID: <duVZxCWBKhVJrPXH4TcaSygW8i99rc9pLXcJe1bXC_s=.5bc72434-59bb-44d8-a957-9c391237397e@github.com>

On Fri, 13 Nov 2020 18:20:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.desktop/share/classes/java/applet/package-info.java line 40:
> 
>> 38:  * <p>
>> 39:  * Deprecated.
>> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.
> 
> That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

The deprecation description should point to the new API which might be used instead of the deprecated ones. So the text "deprecated without replacement" was intentionally added, it will be good to preserve it.

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

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

From igraves at openjdk.java.net  Fri Nov 13 23:31:12 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 23:31:12 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v8]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <3S4BAXFZ25C4FF_O6igaXEQmYOiJ4-XtiPoQ5j1x38M=.56d9a12c-8b9a-474a-a198-e81d6f67d1ee@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Moving additional methods to package private

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/4bcb053e..5a0effe1

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

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

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

From herrick at openjdk.java.net  Sun Nov 15 19:09:07 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sun, 15 Nov 2020 19:09:07 GMT
Subject: <i18n dev> RFR: JDK-8189198: Add "forRemoval = true" to Applet
 APIs [v4]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <n07B5X31Of1E-zQbdfwwtShOQ54zESY2s6oQQ8npBNU=.1beb38c9-1241-44cb-bf64-e64e0c9b3ea5@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8189198: Add "forRemoval = true" to Applet APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/c6ea7714..bc781bea

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

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

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

From naoto at openjdk.java.net  Mon Nov 16 18:28:46 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 Nov 2020 18:28:46 GMT
Subject: <i18n dev> RFR: 8247781: Day periods support [v15]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <kSGUXySY-J6uFgJ3Q_xnD0ZeOsSrLgwh2IeCoO5sdqs=.e1db5d63-db2f-4186-8132-16b6c46ebbb8@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato 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 18 additional commits since the last revision:

 - Merge branch 'master' into dayperiod
 - Re-worded the spec of appendDayPeriodText, refactored calculation of minute-of-day.
 - Addressed the following comments:
   - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
   - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
   - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
   - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
   - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
   - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
   - https://github.com/openjdk/jdk/pull/938#discussion_r522266836
 - Added a test case for user defined temporal field resolution with day period.
 - Clarified 24:00 for "midnight" type in the spec. Some clean up.
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r519061476
 - Fixed a comment.
 - Addressed the following comments:
   - https://github.com/openjdk/jdk/pull/938#discussion_r518431077
   - https://github.com/openjdk/jdk/pull/938#discussion_r518616570
   - https://github.com/openjdk/jdk/pull/938#discussion_r518439782
 - Fixed typo/grammatical error.
 - Merge branch 'master' into dayperiod
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0278aec9...e5db226c

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/1aa3134f..e5db226c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=13-14

  Stats: 74639 lines in 1037 files changed: 41843 ins; 21966 del; 10830 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From naoto at openjdk.java.net  Mon Nov 16 23:16:19 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 Nov 2020 23:16:19 GMT
Subject: <i18n dev> Integrated: 8247781: Day periods support
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <btm7bKHuGPB0LohMNbwUg1GAophPreljC2K-9v1VR-k=.78ca8cc0-206b-4038-a927-3afe5e364b8b@github.com>

On Thu, 29 Oct 2020 15:59:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

This pull request has now been integrated.

Changeset: bf84dac4
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf84dac4
Stats:     1243 lines in 20 files changed: 1039 ins; 87 del; 117 mod

8247781: Day periods support

Reviewed-by: scolebourne, rriggs, joehw

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

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

From igraves at openjdk.java.net  Tue Nov 17 19:58:29 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 17 Nov 2020 19:58:29 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v9]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Adding test coverage. Tweaking wording in docs.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/5a0effe1..aaa35af2

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

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

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

From rriggs at openjdk.java.net  Tue Nov 17 21:44:08 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 17 Nov 2020 21:44:08 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v9]
In-Reply-To: <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>
Message-ID: <JHaBMuCrcdx78acvU9pxPDmrKVEkkj9KcwxhyyzHY3M=.78b7bc31-429b-46fd-9831-6b24e94037e7@github.com>

On Tue, 17 Nov 2020 19:58:29 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test coverage. Tweaking wording in docs.

test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 52:

> 50:             }
> 51:         }
> 52:         throw new RuntimeException("Expected IllegalFormatException for zero argument index.");

The wording of errors around exceptions can be misinterpreted. Did an expected exception occur or not?
If all you saw was the exception without the line of code, would it be unambiguous?

src/java.base/share/classes/java/util/Formatter.java line 2802:

> 2800:                     // skip the trailing '$'
> 2801:                     index = Integer.parseInt(s, start, end - 1, 10);
> 2802:                     if(index <= 0) {

Add a space after 'if' please.

test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 1:

> 1: /*

Typically, using the TestNG framework is preferable for new tests.
In addition to a convenient set of Asserts that check and print expected vs actual and message
it includes patterns for testing for expected exceptions.

test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 98:

> 96:     }
> 97: 
> 98: }

Add a newline at end-of-file.

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 64:

> 62:     public String getMessage() {
> 63:         return String.format("Illegal format argument index = %d", getIndex());
> 64:     }

The exception with a very large negative number isn't going to easy to recognize.
Can the exception message say (for the Integer.MIN_VALUE) that the index is not valid index.
Its probably too much to ask have an indication where in the format string the offending index occurs.

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

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

From naoto at openjdk.java.net  Tue Nov 17 23:28:21 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 Nov 2020 23:28:21 GMT
Subject: <i18n dev> RFR: 8251317: Support for CLDR version 38
Message-ID: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>

Hi,

Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

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

Commit messages:
 - Updated the version in `cldr.md` files
 - Merge branch 'master' into cldr
 - 8251317: Support for CLDR version 38

Changes: https://git.openjdk.java.net/jdk/pull/1279/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1279&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251317
  Stats: 57338 lines in 209 files changed: 41958 ins; 4932 del; 10448 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1279.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1279/head:pull/1279

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

From smarks at openjdk.java.net  Tue Nov 17 23:57:13 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 17 Nov 2020 23:57:13 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v9]
In-Reply-To: <JHaBMuCrcdx78acvU9pxPDmrKVEkkj9KcwxhyyzHY3M=.78b7bc31-429b-46fd-9831-6b24e94037e7@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>
 <JHaBMuCrcdx78acvU9pxPDmrKVEkkj9KcwxhyyzHY3M=.78b7bc31-429b-46fd-9831-6b24e94037e7@github.com>
Message-ID: <e-MqQvukifDsDfskjs9XmOJ7k8TX2zpBv_Q4qZjxDq4=.9c44c76e-a050-4d3d-b303-6f06ef77b38e@github.com>

On Tue, 17 Nov 2020 21:21:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding test coverage. Tweaking wording in docs.
>
> test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 1:
> 
>> 1: /*
> 
> Typically, using the TestNG framework is preferable for new tests.
> In addition to a convenient set of Asserts that check and print expected vs actual and message
> it includes patterns for testing for expected exceptions.

Yes, these tests are amenable to TestNG's `assertThrows` method. That might be all you need; we generally aren't too concerned about the exact content and formatting of the exception's message. However, if you want to make additional assertions over the thrown exception, it can be obtained using `expectThrows` instead of `assertThrows`.

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

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

From naoto at openjdk.java.net  Wed Nov 18 02:07:01 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 Nov 2020 02:07:01 GMT
Subject: <i18n dev> RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <Vi38PG7PPjWFSSw0L0hI_KErgM19ncMx4tRMIGROEyc=.200b59de-f342-49f2-a8d3-c5d4e8ef696b@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Looks like the generated webrev is empty, possibly due to this issue (https://bugs.openjdk.java.net/browse/SKARA-732). Here is the one manually generated:
https://cr.openjdk.java.net/~naoto/cldr/webrev.00/

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

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

From erikj at openjdk.java.net  Wed Nov 18 13:36:07 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 18 Nov 2020 13:36:07 GMT
Subject: <i18n dev> RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <6y-uJZl6ZqCrkPzq84kdwWndQbhVLGWbl5k9Hl0lv4A=.a843d0d5-e2be-41e2-be22-86021da9f00f@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Looks fine from a build point of view.

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

Marked as reviewed by erikj (Reviewer).

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

From igraves at openjdk.java.net  Wed Nov 18 20:57:26 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 20:57:26 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v10]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <wPcbmJQ-jTBVVir2z0FukqAQAZZ7kQPD0iFWn3gX2UI=.f8c8a18d-2e5f-405f-88cd-9fd3445b6a6c@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Docfixes, exception messages, formatting and moving tests to testng

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/aaa35af2..03d55944

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

  Stats: 177 lines in 5 files changed: 77 ins; 98 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

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

From bchristi at openjdk.java.net  Wed Nov 18 21:18:05 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 18 Nov 2020 21:18:05 GMT
Subject: <i18n dev> RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <tHh3uXWWKnFpSW9uWupt9WjkolM-6U353JO1Fk9L4vo=.a1621452-c4c5-49eb-9e7b-68a8cdff00d4@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Changes seem fine to me.

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

Marked as reviewed by bchristi (Reviewer).

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

From igraves at openjdk.java.net  Wed Nov 18 22:09:21 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 22:09:21 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v11]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Exception message tweak

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/03d55944..36e8d3a3

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

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

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

From rriggs at openjdk.java.net  Wed Nov 18 22:34:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 22:34:06 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v11]
In-Reply-To: <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>
Message-ID: <bUPA8A5EWW7sQIdyCIQjVa-D6x5HwvjbQAp3IEf0_yE=.ca045fa9-3416-4b36-babe-743ae033780f@github.com>

On Wed, 18 Nov 2020 22:09:21 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exception message tweak

Marked as reviewed by rriggs (Reviewer).

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

> 64: 
> 65:         if (index == Integer.MIN_VALUE) {
> 66:            return "Format argument index: (unrepresentable as int)";

Perhaps "(not representable as int)" is more readable.

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

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

From igraves at openjdk.java.net  Wed Nov 18 22:52:07 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 22:52:07 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v11]
In-Reply-To: <bUPA8A5EWW7sQIdyCIQjVa-D6x5HwvjbQAp3IEf0_yE=.ca045fa9-3416-4b36-babe-743ae033780f@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>
 <bUPA8A5EWW7sQIdyCIQjVa-D6x5HwvjbQAp3IEf0_yE=.ca045fa9-3416-4b36-babe-743ae033780f@github.com>
Message-ID: <ZP0_b9SkUkTnKI67GftkX5rGAuoE6_DM94y_GxfExwQ=.dbee8707-178d-4a7a-a2ee-285fe7b14db8@github.com>

On Wed, 18 Nov 2020 22:30:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exception message tweak
>
> src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 66:
> 
>> 64: 
>> 65:         if (index == Integer.MIN_VALUE) {
>> 66:            return "Format argument index: (unrepresentable as int)";
> 
> Perhaps "(not representable as int)" is more readable.

After reading it a few times, I agree.

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

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

From igraves at openjdk.java.net  Wed Nov 18 22:57:19 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 22:57:19 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  'unrepresentable' to 'not representable'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/36e8d3a3..223282d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=10-11

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

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

From rriggs at openjdk.java.net  Wed Nov 18 23:54:11 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 23:54:11 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
Message-ID: <EaNWdLa41Iw5eENmtgFHJEtO2uvLuoTUm6bYg-xGTcM=.8fed1135-0aac-4544-bf5c-c99fc1c6a29c@github.com>

On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   'unrepresentable' to 'not representable'

Marked as reviewed by rriggs (Reviewer).

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

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

From smarks at openjdk.java.net  Thu Nov 19 00:42:05 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 19 Nov 2020 00:42:05 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
Message-ID: <MhhKG6zR1D8bKDbkRkWVPDF2mQSqy7yzzBGugCICyMg=.a70133fe-2911-435e-84d7-b49ae786a9a1@github.com>

On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   'unrepresentable' to 'not representable'

Marked as reviewed by smarks (Reviewer).

test/jdk/java/util/IllegalFormatException/TestFormatSpecifierBounds.java line 48:

> 46:             String r = String.format("%2147483648$s", "A", "B");
> 47:         });
> 48:         //assertEquals(e.getMessage(), "Illegal format argument index = " + Integer.MIN_VALUE);

Extraneous comment?

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

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

From igraves at openjdk.java.net  Thu Nov 19 00:58:21 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 19 Nov 2020 00:58:21 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v13]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <5IpbSrdcuKa4kWC2OEozS7TkcDl_UrQ23ypTugtXWvw=.5e8f3c17-337d-4e73-8901-3480b852763c@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Comment cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/223282d4..78fc8176

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=11-12

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

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

From igraves at openjdk.java.net  Thu Nov 19 00:58:22 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 19 Nov 2020 00:58:22 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <MhhKG6zR1D8bKDbkRkWVPDF2mQSqy7yzzBGugCICyMg=.a70133fe-2911-435e-84d7-b49ae786a9a1@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
 <MhhKG6zR1D8bKDbkRkWVPDF2mQSqy7yzzBGugCICyMg=.a70133fe-2911-435e-84d7-b49ae786a9a1@github.com>
Message-ID: <A1yptvYVd54saLXVfpc_EjmqbWHTovTUEL_Q9fKKO7E=.48ff913a-dce1-4c82-bcf2-51a3834ebe8f@github.com>

On Thu, 19 Nov 2020 00:38:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   'unrepresentable' to 'not representable'
>
> test/jdk/java/util/IllegalFormatException/TestFormatSpecifierBounds.java line 48:
> 
>> 46:             String r = String.format("%2147483648$s", "A", "B");
>> 47:         });
>> 48:         //assertEquals(e.getMessage(), "Illegal format argument index = " + Integer.MIN_VALUE);
> 
> Extraneous comment?

So it would seem!

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

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

From joehw at openjdk.java.net  Thu Nov 19 01:42:08 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 19 Nov 2020 01:42:08 GMT
Subject: <i18n dev> RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <i2kgDC11e8F9RUZ4dOPkIibZ5leKg1Fb95WqfhJ8Py0=.9cbbf365-4e3b-4f18-8eb2-7cc31f2678f3@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Looks good to me.

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

Marked as reviewed by joehw (Reviewer).

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

From naoto at openjdk.java.net  Thu Nov 19 17:53:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 Nov 2020 17:53:11 GMT
Subject: <i18n dev> RFR: 8211449" Correction to the spec of implicit
 negative subpattern in DecimalFormat
Message-ID: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>

Hi,

Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

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

Commit messages:
 - 8211449: Correction to the spec of implicit negative subpattern in DecimalFormat

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

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

From bpb at openjdk.java.net  Thu Nov 19 18:04:04 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 19 Nov 2020 18:04:04 GMT
Subject: <i18n dev> RFR: 8211449: Correction to the spec of implicit
 negative subpattern in DecimalFormat
In-Reply-To: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
References: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
Message-ID: <zvYxvBG0y4S-k4LlKASVtCvbfvggMZ5h-WAgMIqAM2k=.d74b98c7-d1ca-4d2e-86ae-ced4bdfd23de@github.com>

On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

Marked as reviewed by bpb (Reviewer).

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

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

From lancea at openjdk.java.net  Thu Nov 19 18:20:06 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 18:20:06 GMT
Subject: <i18n dev> RFR: 8211449: Correction to the spec of implicit
 negative subpattern in DecimalFormat
In-Reply-To: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
References: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
Message-ID: <t_wSasdp0vEZLYtTdFJjtJ4d0vDN3zLm2DNBb_T5aBk=.8a5ba0c4-3e88-49a1-828e-fbe9cae1dd8d@github.com>

On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

Looks fine, pending CSR approval :-)

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

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

From smarks at openjdk.java.net  Thu Nov 19 20:21:05 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 19 Nov 2020 20:21:05 GMT
Subject: <i18n dev> RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v13]
In-Reply-To: <5IpbSrdcuKa4kWC2OEozS7TkcDl_UrQ23ypTugtXWvw=.5e8f3c17-337d-4e73-8901-3480b852763c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <5IpbSrdcuKa4kWC2OEozS7TkcDl_UrQ23ypTugtXWvw=.5e8f3c17-337d-4e73-8901-3480b852763c@github.com>
Message-ID: <_3RAvXY8Ua9Bs_WM9tnoTrv8viowc2JoxGp8p0afA3I=.2afe8051-5db6-4c1c-9f43-04a50507f48a@github.com>

On Thu, 19 Nov 2020 00:58:21 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment cleanup

Marked as reviewed by smarks (Reviewer).

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

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

From igraves at openjdk.java.net  Thu Nov 19 20:24:04 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 19 Nov 2020 20:24:04 GMT
Subject: <i18n dev> Integrated: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <B79WPkolbTjgP7hxCCqsKfb8nR0k_Dhvlbx7Royr1ug=.a1680f96-e51f-4850-8a79-b8df92150400@github.com>

On Mon, 5 Oct 2020 22:23:56 GMT, Ian Graves <igraves at openjdk.org> wrote:

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

This pull request has now been integrated.

Changeset: 080c707a
Author:    Ian Graves <igraves at openjdk.org>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/080c707a
Stats:     175 lines in 5 files changed: 167 ins; 0 del; 8 mod

8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly

Reviewed-by: rriggs, smarks

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

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

From naoto at openjdk.java.net  Thu Nov 19 22:44:08 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 Nov 2020 22:44:08 GMT
Subject: <i18n dev> Integrated: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <XOsM_z2kJgv9AVfq7GxgMaP2QoDvLoq756kKpIx2O8o=.8939805d-e5e3-4159-979e-22c8b31db052@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

This pull request has now been integrated.

Changeset: 68138893
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/68138893
Stats:     57338 lines in 209 files changed: 41958 ins; 4932 del; 10448 mod

8251317: Support for CLDR version 38

Reviewed-by: erikj, bchristi, joehw

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

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

From naoto at openjdk.java.net  Fri Nov 20 17:13:04 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 20 Nov 2020 17:13:04 GMT
Subject: <i18n dev> Integrated: 8211449: Correction to the spec of implicit
 negative subpattern in DecimalFormat
In-Reply-To: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
References: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
Message-ID: <8fTrEiipobLTkkVHLQM0BsfQLJYZ9-sW2Rv36NHBnpY=.c40adcfc-aa8f-4772-9cd3-0d01d5a9d14e@github.com>

On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

This pull request has now been integrated.

Changeset: 2c3a2bed
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c3a2bed
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8211449: Correction to the spec of implicit negative subpattern in DecimalFormat

Reviewed-by: bpb

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

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

From naoto at openjdk.java.net  Fri Nov 20 18:01:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 20 Nov 2020 18:01:14 GMT
Subject: <i18n dev> RFR: 8247432: Update IANA Language Subtag Registry to
 Version 2020-09-29
Message-ID: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>

Hi,

Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

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

Commit messages:
 - LSR 2020-09-29
 - LSR 2020-07-17

Changes: https://git.openjdk.java.net/jdk/pull/1357/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1357&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247432
  Stats: 52 lines in 2 files changed: 44 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1357.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1357/head:pull/1357

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

From joehw at openjdk.java.net  Fri Nov 20 21:48:05 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 20 Nov 2020 21:48:05 GMT
Subject: <i18n dev> RFR: 8247432: Update IANA Language Subtag Registry
 to Version 2020-09-29
In-Reply-To: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
References: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
Message-ID: <LpGv3NViw_6283T43Ef-TKbWG1WtEduzXFWhHq36nSk=.b7251d5f-5a79-4f52-994d-d7c7fd6013e9@github.com>

On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

Marked as reviewed by joehw (Reviewer).

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

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

From naoto at openjdk.java.net  Mon Nov 23 16:44:56 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Nov 2020 16:44:56 GMT
Subject: <i18n dev> Integrated: 8247432: Update IANA Language Subtag
 Registry to Version 2020-09-29
In-Reply-To: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
References: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
Message-ID: <D3q7Jjy1mGbLqrzYPKOJghxb2BX-ZAcb_u18OENi0xU=.1ead8912-1605-49f2-a331-ae6de30d5bc4@github.com>

On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

This pull request has now been integrated.

Changeset: ae0ca743
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ae0ca743
Stats:     52 lines in 2 files changed: 44 ins; 5 del; 3 mod

8247432: Update IANA Language Subtag Registry to Version 2020-09-29

Reviewed-by: joehw

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

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