From naoto.sato at oracle.com  Mon Jul  1 15:32:22 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 1 Jul 2019 08:32:22 -0700
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
Message-ID: <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>

Hi Thejasvi,

Thanks for fixing this.

Since those new test cases depend on the CLDR localization, which might 
change in other implementations, those test cases should be in 
jdk/java/time/test directory, as "tck" tests should only test the spec. 
Please create a new test case for this in the "test" directory (with 
@modules jdk.localedata directive) similar to the existing TCK one. Also 
the current test in the TCK should enforce that it runs in Locale.US so 
that the result should match "GMT."

Naoto

On 6/28/19 5:59 AM, Thejasvi Voniadka wrote:
> Hi,
> 
> Request you to please review this change.
> 
> 
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8154520
> 
> 
> Description:    At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value.
> 
> 
> Webrev:    http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/
> 
> 
> Additional notes:    I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it.
> 

From thejasvi.v.voniadka at oracle.com  Tue Jul  2 14:32:07 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Tue, 2 Jul 2019 07:32:07 -0700 (PDT)
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
Message-ID: <590cca03-1741-41a2-9544-157d1f553835@default>

Hi Naoto,

Thank you for the review. I have performed the modifications, and here is the updated webrev:

http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/


I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format.




-----Original Message-----
From: Naoto Sato 
Sent: Monday, July 01, 2019 9:02 PM
To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

Hi Thejasvi,

Thanks for fixing this.

Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. 
Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT."

Naoto

On 6/28/19 5:59 AM, Thejasvi Voniadka wrote:
> Hi,
> 
> Request you to please review this change.
> 
> 
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8154520
> 
> 
> Description:    At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value.
> 
> 
> Webrev:    http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/
> 
> 
> Additional notes:    I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it.
> 

From naoto.sato at oracle.com  Tue Jul  2 16:03:12 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 2 Jul 2019 09:03:12 -0700
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <590cca03-1741-41a2-9544-157d1f553835@default>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
 <590cca03-1741-41a2-9544-157d1f553835@default>
Message-ID: <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>

Hi Thejasvi,

Here are my comments to the webrev:

TCKOffsetPrinterParser.java

- No need to define Locale_US as a static field, nor have it in the test 
data (data_print_localized) then pass it as an argument to the test. 
Specifying Locale.US in line 572, 578, and 586 should suffice.

TestOffsetPrinterParser.java

- Copyright year is 2019.

- It would be nice if some comments that reads something like "This test 
relies on the localized text of "GMT" in the CLDR."

- Test class (and the description) should include "Localized", as it is 
testing the implementation of localized version of OffsetIdPrinterParser.

- Line 64-76: I prefer just instantiating them in the test data, not 
defining a static field for each, unless there will be duplicate in the 
test data.

- Line 111, 118, 124, 132: I believe the locale parameter is required. 
Make sure that with Objects.requireNonNull(), or fail if it's null.

Naoto

On 7/2/19 7:32 AM, Thejasvi Voniadka wrote:
> Hi Naoto,
> 
> Thank you for the review. I have performed the modifications, and here is the updated webrev:
> 
> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/
> 
> 
> I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format.
> 
> 
> 
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Monday, July 01, 2019 9:02 PM
> To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string
> 
> Hi Thejasvi,
> 
> Thanks for fixing this.
> 
> Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec.
> Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT."
> 
> Naoto
> 
> On 6/28/19 5:59 AM, Thejasvi Voniadka wrote:
>> Hi,
>>
>> Request you to please review this change.
>>
>>
>> JBS:    https://bugs.openjdk.java.net/browse/JDK-8154520
>>
>>
>> Description:    At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value.
>>
>>
>> Webrev:    http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/
>>
>>
>> Additional notes:    I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it.
>>

From thejasvi.v.voniadka at oracle.com  Wed Jul  3 12:32:29 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Wed, 3 Jul 2019 05:32:29 -0700 (PDT)
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
 <590cca03-1741-41a2-9544-157d1f553835@default>
 <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>
Message-ID: <d9e37b31-dc78-464b-9597-8ebde688e734@default>

Hi Naoto,

Thank you for the review. Please find the updated webrev:

http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/


The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java.



-----Original Message-----
From: Naoto Sato 
Sent: Tuesday, July 02, 2019 9:33 PM
To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

Hi Thejasvi,

Here are my comments to the webrev:

TCKOffsetPrinterParser.java

- No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. 
Specifying Locale.US in line 572, 578, and 586 should suffice.

TestOffsetPrinterParser.java

- Copyright year is 2019.

- It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR."

- Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser.

- Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data.

- Line 111, 118, 124, 132: I believe the locale parameter is required. 
Make sure that with Objects.requireNonNull(), or fail if it's null.

Naoto

On 7/2/19 7:32 AM, Thejasvi Voniadka wrote:
> Hi Naoto,
> 
> Thank you for the review. I have performed the modifications, and here is the updated webrev:
> 
> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/
> 
> 
> I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format.
> 
> 
> 
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Monday, July 01, 2019 9:02 PM
> To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; 
> core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8154520: java.time: 
> appendLocalizedOffset() should return the localized "GMT" string
> 
> Hi Thejasvi,
> 
> Thanks for fixing this.
> 
> Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec.
> Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT."
> 
> Naoto
> 
> On 6/28/19 5:59 AM, Thejasvi Voniadka wrote:
>> Hi,
>>
>> Request you to please review this change.
>>
>>
>> JBS:    https://bugs.openjdk.java.net/browse/JDK-8154520
>>
>>
>> Description:    At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value.
>>
>>
>> Webrev:    http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/
>>
>>
>> Additional notes:    I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it.
>>

From naoto.sato at oracle.com  Wed Jul  3 16:10:36 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 3 Jul 2019 09:10:36 -0700
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <d9e37b31-dc78-464b-9597-8ebde688e734@default>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
 <590cca03-1741-41a2-9544-157d1f553835@default>
 <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>
 <d9e37b31-dc78-464b-9597-8ebde688e734@default>
Message-ID: <d0d0f0c2-c456-c68a-7ee3-7d05088a4c8e@oracle.com>

Looks good.

Naoto

On 7/3/19 5:32 AM, Thejasvi Voniadka wrote:
> Hi Naoto,
> 
> Thank you for the review. Please find the updated webrev:
> 
> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/
> 
> 
> The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java.
> 
> 
> 
> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, July 02, 2019 9:33 PM
> To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string
> 
> Hi Thejasvi,
> 
> Here are my comments to the webrev:
> 
> TCKOffsetPrinterParser.java
> 
> - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test.
> Specifying Locale.US in line 572, 578, and 586 should suffice.
> 
> TestOffsetPrinterParser.java
> 
> - Copyright year is 2019.
> 
> - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR."
> 
> - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser.
> 
> - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data.
> 
> - Line 111, 118, 124, 132: I believe the locale parameter is required.
> Make sure that with Objects.requireNonNull(), or fail if it's null.
> 
> Naoto
> 
> On 7/2/19 7:32 AM, Thejasvi Voniadka wrote:
>> Hi Naoto,
>>
>> Thank you for the review. I have performed the modifications, and here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/
>>
>>
>> I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format.
>>
>>
>>
>>
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Monday, July 01, 2019 9:02 PM
>> To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>;
>> core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
>> Subject: Re: <i18n dev> RFR: 8154520: java.time:
>> appendLocalizedOffset() should return the localized "GMT" string
>>
>> Hi Thejasvi,
>>
>> Thanks for fixing this.
>>
>> Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec.
>> Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT."
>>
>> Naoto
>>
>> On 6/28/19 5:59 AM, Thejasvi Voniadka wrote:
>>> Hi,
>>>
>>> Request you to please review this change.
>>>
>>>
>>> JBS:    https://bugs.openjdk.java.net/browse/JDK-8154520
>>>
>>>
>>> Description:    At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value.
>>>
>>>
>>> Webrev:    http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/
>>>
>>>
>>> Additional notes:    I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it.
>>>

From Roger.Riggs at oracle.com  Wed Jul  3 17:16:18 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 3 Jul 2019 13:16:18 -0400
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <d0d0f0c2-c456-c68a-7ee3-7d05088a4c8e@oracle.com>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
 <590cca03-1741-41a2-9544-157d1f553835@default>
 <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>
 <d9e37b31-dc78-464b-9597-8ebde688e734@default>
 <d0d0f0c2-c456-c68a-7ee3-7d05088a4c8e@oracle.com>
Message-ID: <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com>

Hi,

Looks ok, but...

.../java/time/format/DateTimeFormatterBuilder.java
3924: needs a space in "if(" -> "if ("

java/time/format/TestLocalizedOffsetPrinterParser.java

I would cut the number of test cases to a minimum; only need to ensure 
the code is correct.
We don't need to be testing the CLDR data; it is just? pass through.
At least cut the number of different locale's used to cut the risk of 
unexpected maintenance.

Thanks, Roger



On 7/3/19 12:10 PM, naoto.sato at oracle.com wrote:
> Looks good.
>
> Naoto
>
> On 7/3/19 5:32 AM, Thejasvi Voniadka wrote:
>> Hi Naoto,
>>
>> Thank you for the review. Please find the updated webrev:
>>
>> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/
>>
>>
>> The TCKOffsetPrinterParser.java has been reverted back to what it 
>> was, except for the copyright year and the locale addition. I have 
>> incorporated your comments to TestLocalizedOffsetPrinterParser.java.
>>
>>
>>
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Tuesday, July 02, 2019 9:33 PM
>> To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; 
>> core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
>> Subject: Re: <i18n dev> RFR: 8154520: java.time: 
>> appendLocalizedOffset() should return the localized "GMT" string
>>
>> Hi Thejasvi,
>>
>> Here are my comments to the webrev:
>>
>> TCKOffsetPrinterParser.java
>>
>> - No need to define Locale_US as a static field, nor have it in the 
>> test data (data_print_localized) then pass it as an argument to the 
>> test.
>> Specifying Locale.US in line 572, 578, and 586 should suffice.
>>
>> TestOffsetPrinterParser.java
>>
>> - Copyright year is 2019.
>>
>> - It would be nice if some comments that reads something like "This 
>> test relies on the localized text of "GMT" in the CLDR."
>>
>> - Test class (and the description) should include "Localized", as it 
>> is testing the implementation of localized version of 
>> OffsetIdPrinterParser.
>>
>> - Line 64-76: I prefer just instantiating them in the test data, not 
>> defining a static field for each, unless there will be duplicate in 
>> the test data.
>>
>> - Line 111, 118, 124, 132: I believe the locale parameter is required.
>> Make sure that with Objects.requireNonNull(), or fail if it's null.
>>
>> Naoto
>>
>> On 7/2/19 7:32 AM, Thejasvi Voniadka wrote:
>>> Hi Naoto,
>>>
>>> Thank you for the review. I have performed the modifications, and 
>>> here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/
>>>
>>>
>>> I have moved the new tests from TCK area. I have also updated the 
>>> current TCK test to explicitly pass Locale.US while calling format.
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Naoto Sato
>>> Sent: Monday, July 01, 2019 9:02 PM
>>> To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>;
>>> core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
>>> Subject: Re: <i18n dev> RFR: 8154520: java.time:
>>> appendLocalizedOffset() should return the localized "GMT" string
>>>
>>> Hi Thejasvi,
>>>
>>> Thanks for fixing this.
>>>
>>> Since those new test cases depend on the CLDR localization, which 
>>> might change in other implementations, those test cases should be in 
>>> jdk/java/time/test directory, as "tck" tests should only test the spec.
>>> Please create a new test case for this in the "test" directory (with 
>>> @modules jdk.localedata directive) similar to the existing TCK one. 
>>> Also the current test in the TCK should enforce that it runs in 
>>> Locale.US so that the result should match "GMT."
>>>
>>> Naoto
>>>
>>> On 6/28/19 5:59 AM, Thejasvi Voniadka wrote:
>>>> Hi,
>>>>
>>>> Request you to please review this change.
>>>>
>>>>
>>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520
>>>>
>>>>
>>>> Description:??? At present, the 
>>>> "DateTimeFormatterBuilder.appendLocalizedOffset()" method 
>>>> formulates the base string as "GMT", without accounting for 
>>>> locale-specific transformations. This change is to return the 
>>>> localized version of "GMT" instead. So for example, instead of 
>>>> returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" 
>>>> is the localized string for "GMT" for the locale associated with 
>>>> the formatter. I have used 
>>>> DateTimeTextProvider.getLocalizedResource() method to return the 
>>>> "gmtZeroFormat" value from CLDR/LDML corresponding to the given 
>>>> locale. The code defaults to "GMT" in the absence of such a 
>>>> localized value.
>>>>
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/
>>>>
>>>>
>>>> Additional notes:??? I preferred to update and reuse an existing 
>>>> test instead of creating a new one. It already has the niceties in 
>>>> place, and creating another method would mean some amount of code 
>>>> redundancy. However, if that's the recommended norm, then I can 
>>>> change it.
>>>>


From thejasvi.v.voniadka at oracle.com  Fri Jul  5 03:45:58 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Thu, 4 Jul 2019 20:45:58 -0700 (PDT)
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
 <590cca03-1741-41a2-9544-157d1f553835@default>
 <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>
 <d9e37b31-dc78-464b-9597-8ebde688e734@default>
 <d0d0f0c2-c456-c68a-7ee3-7d05088a4c8e@oracle.com>
 <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com>
Message-ID: <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default>

Hi Roger,

?

Thank you for the review. I am in transit this weekend, but I will fix this and republish as soon as I can.

?

?

From: Roger Riggs 
Sent: Wednesday, July 03, 2019 10:46 PM
To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

?

Hi,

Looks ok, but...

.../java/time/format/DateTimeFormatterBuilder.java
3924: needs a space in "if(" -> "if ("

java/time/format/TestLocalizedOffsetPrinterParser.java

I would cut the number of test cases to a minimum; only need to ensure the code is correct.
We don't need to be testing the CLDR data; it is just? pass through.
At least cut the number of different locale's used to cut the risk of unexpected maintenance.

Thanks, Roger




On 7/3/19 12:10 PM, HYPERLINK "mailto:naoto.sato at oracle.com"naoto.sato at oracle.com wrote:

Looks good. 

Naoto 

On 7/3/19 5:32 AM, Thejasvi Voniadka wrote: 



Hi Naoto, 

Thank you for the review. Please find the updated webrev: 

http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ 


The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java. 



-----Original Message----- 
From: Naoto Sato 
Sent: Tuesday, July 02, 2019 9:33 PM 
To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"<thejasvi.v.voniadka at oracle.com>; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net 
Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string 

Hi Thejasvi, 

Here are my comments to the webrev: 

TCKOffsetPrinterParser.java 

- No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. 
Specifying Locale.US in line 572, 578, and 586 should suffice. 

TestOffsetPrinterParser.java 

- Copyright year is 2019. 

- It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." 

- Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. 

- Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. 

- Line 111, 118, 124, 132: I believe the locale parameter is required. 
Make sure that with Objects.requireNonNull(), or fail if it's null. 

Naoto 

On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: 



Hi Naoto, 

Thank you for the review. I have performed the modifications, and here is the updated webrev: 

http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ 


I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. 




-----Original Message----- 
From: Naoto Sato 
Sent: Monday, July 01, 2019 9:02 PM 
To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"<thejasvi.v.voniadka at oracle.com>; 
HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net 
Subject: Re: <i18n dev> RFR: 8154520: java.time: 
appendLocalizedOffset() should return the localized "GMT" string 

Hi Thejasvi, 

Thanks for fixing this. 

Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. 
Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." 

Naoto 

On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: 



Hi, 

Request you to please review this change. 


JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520 


Description:??? At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. 


Webrev:??? http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ 


Additional notes:??? I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. 

?

From ramanand.patil at oracle.com  Fri Jul  5 14:16:43 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Fri, 5 Jul 2019 07:16:43 -0700 (PDT)
Subject: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a
 and 8225580: tzdata2018i integration causes test failures on jdk-13
Message-ID: <0a339591-f5ac-4680-ac70-1a48d8699999@default>

Hi all,
Please review the patch for tzdata2019a integration into jdk project.
Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
https://bugs.openjdk.java.net/browse/JDK-8225580

Summary:
- The fix contains cumulative tzdata changes from tzdata2018i and tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier.
- In JDK-13/14, multiple failures were seen during integration of tzdata2018i (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix for this in CLDRConverter.java.
- There are 2 type of test failures in TestZoneInfo310.java file, which are solved in this patch by providing workarounds, But a permanent fix needs to be added in future for the same. Below are the 2 bugs created to track the development on it:
	1. https://bugs.openjdk.java.net/browse/JDK-8223388: TestZoneInfo310.java fails post tzdata2018i integration:
This failure is seen for the TimeZones which are having zone rules defined till year 2037 or beyond. For now, the failing zones are skipped.
The supporting test class ZoneInfo.java has maxYear defined http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/calendar/zi/Zoneinfo.java#l40, changing this max value greater than the zone rule's last year also fixes the issue, but further investigation is needed on why this boundary condition is affecting the test behavior.
	2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone rules:
There are many hacks and assumptions in the class sun.util.calendar.ZoneInfoFile.java. This issue looks because of the code starting from here: http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java#l552
There is an assumption where the transition date is >=24,(line 577 and 599) it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and Asia/Hebron zones.
For now, I have fixed these 2 problematic timezones by overwriting the assumption made on line 577, where date of month dom = startRule.dom;
I think, overriding of the second jdk hack on line 599 is not required as the "dom" is calculated from the last rule there. Keeping this bug open as we need to find a generic solution for this issue, without hard-coding the values and adding specific time zone names in exclusion as seen in many places in this class file.

- The patch has passed all the related testing including JCK tests.


Regards,
Ramanand.
    
    
    
    

From gnu.andrew at redhat.com  Fri Jul  5 17:49:48 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 5 Jul 2019 18:49:48 +0100
Subject: <i18n dev> RFR: [8u] JDK-8218781: Localized names for Japanese
 Era Reiwa in COMPAT provider
In-Reply-To: <17daddcde35ed4f072a7502c10388a25f49924db.camel@redhat.com>
References: <0e093fe1-2bc5-c1ba-0f69-3e1754ebdef4@redhat.com>
 <17daddcde35ed4f072a7502c10388a25f49924db.camel@redhat.com>
Message-ID: <8999a5c4-8cb3-9b3b-e7e0-11c04ce1b8a2@redhat.com>



On 05/07/2019 17:52, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218781
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/
>>
>> OpenJDK 8u uses an older version of the CLDR data to 9, and is thus
>> missing a number of locale data files updated by the original version of
>> 8218781. Thus, some chunks are absent from the 8u backport.
> 
> Ugh, the JDK 13 fix got pushed via 8219781 :( No wonder I wasn't
> finding anything.
> 

Ah, so it wasn't a typo on my part in 8u.

> Hmm, there is no COMPAT provider in JDK 8u. That's JDK 9 onwards. See:
> https://bugs.openjdk.java.net/browse/JDK-8062006
> 
> In JDK 8u -Djava.locale.providers=COMPAT (as used in the test[1]) will
> result in the default list, which is JRE,SPI as far as I can see.
> 

Yes, it's effectively redundant. I guess we could remove it but it then
creates divergence.

>> In most cases, this actually makes no difference in testing, because the
>> locale data files for hr, in, lt, nl and sv simply duplicate the English
>> values. Thus, the only ones that fail the test are no (uses a short era
>> of "R") and sr_Latn ("Reiva").
> 
> Right, but why intentionally introduce test failures? I'm worried about
> signal vs. noise here.
> 
>> I propose that we apply 8218781 for the locales we have now, and look at
>> backporting updated CLDR data for 8u232 or 8u242. The updates -
>> primarily JDK-8008577 - are tied up with configuration changes which we
>> don't want to import to 8, so a backport will require some work and
>> significant testing.
>>
>> In short, please review this patch, taking into consideration that some
>> locales will be absent and that data is duplicated for others
>> (JDK-8159943, not in 8u, makes the short and long eras use a shared
>> variable where they are identical)
> 
> Have you considered something like this patch so as to avoid the test
> failures and then re-enable them once a fix comes in?
> 

That seems like a good way to make sure it doesn't get fixed.

> diff --git a/test/java/util/Calendar/JapanEraNameCompatTest.java b/test/java/util/Calendar/JapanEraNameCompatTest.java
> --- a/test/java/util/Calendar/JapanEraNameCompatTest.java
> +++ b/test/java/util/Calendar/JapanEraNameCompatTest.java
> @@ -96,12 +96,12 @@
>              { new Locale("hi", "IN"), HindiName, HindiName },
>              { new Locale("ru"), RussianName, RussianName },
>              { new Locale("sr"), SerbianName, SerbianName },
> -            { Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
> +            //{ Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
>              { new Locale("hr"), EngName, EngName },
>              { new Locale("in"), EngName, EngName },
>              { new Locale("lt"), EngName, EngName },
>              { new Locale("nl"), EngName, EngName },
> -            { new Locale("no"), EngName, "R" },
> +            //{ new Locale("no"), EngName, "R" },
>              { new Locale("sv"), EngName, EngName },
>              // el fallback to root
>              { new Locale("el"), EngName, EngName }
> 
> This would make it more apparent that it's intentional. Perhaps filing
> a bug that it's not a complete fix would be even better. Thoughts?
> 

As I said, the intention is to look at the viability of backporting the
updated CLDR data. There are already bugs for that.

> Thanks,
> Severin
> 
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/35818757a9c6/test/java/util/Calendar/JapanEraNameCompatTest.java#l29
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From srl at icu-project.org  Fri Jul  5 18:30:51 2019
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 5 Jul 2019 11:30:51 -0700
Subject: <i18n dev> RFR: [8u] JDK-8218781: Localized names for Japanese
 Era Reiwa in COMPAT provider
In-Reply-To: <8999a5c4-8cb3-9b3b-e7e0-11c04ce1b8a2@redhat.com>
References: <0e093fe1-2bc5-c1ba-0f69-3e1754ebdef4@redhat.com>
 <17daddcde35ed4f072a7502c10388a25f49924db.camel@redhat.com>
 <8999a5c4-8cb3-9b3b-e7e0-11c04ce1b8a2@redhat.com>
Message-ID: <F836EE3D-146C-4715-804D-63A26C7133E1@icu-project.org>

[Resend from the correct address?]

Hi all,

For what it?s worth,
 CLDR itself doesn?t usually ?backport? data. (So there?s no CLDR source for such a backport.) I don?t know if CLDR has ever released a dot release for a release past the last released major version.


  FYI, For ICU, what we did (for a large number of releases) is a very specific spot fix of the locale data.

- icu4j changes for 56.2 including binary data locale blob change: https://github.com/unicode-org/icu/commit/b5999f7e7fa54c4f0fb9e9cd5e80095bb27eea32 <https://github.com/unicode-org/icu/commit/b5999f7e7fa54c4f0fb9e9cd5e80095bb27eea32>
- icu4c changes for 56.2 including textual changes to the intermediate format: https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43 <https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43> 

Example: 
 https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43#diff-2990754f360524737be2791c1ab20e94R2384 <https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43#diff-2990754f360524737be2791c1ab20e94R2384> ( change for Japanese )


--
Steven R. Loomis | @srl295 | git.io/srl295



> El jul. 5, 2019, a las 10:49 a. m., Andrew John Hughes <gnu.andrew at redhat.com> escribi?:
> 
> 
> 
> On 05/07/2019 17:52, Severin Gehwolf wrote:
>> Hi Andrew,
>> 
>> On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218781
>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/
>>> 
>>> OpenJDK 8u uses an older version of the CLDR data to 9, and is thus
>>> missing a number of locale data files updated by the original version of
>>> 8218781. Thus, some chunks are absent from the 8u backport.
>> 
>> Ugh, the JDK 13 fix got pushed via 8219781 :( No wonder I wasn't
>> finding anything.
>> 
> 
> Ah, so it wasn't a typo on my part in 8u.
> 
>> Hmm, there is no COMPAT provider in JDK 8u. That's JDK 9 onwards. See:
>> https://bugs.openjdk.java.net/browse/JDK-8062006
>> 
>> In JDK 8u -Djava.locale.providers=COMPAT (as used in the test[1]) will
>> result in the default list, which is JRE,SPI as far as I can see.
>> 
> 
> Yes, it's effectively redundant. I guess we could remove it but it then
> creates divergence.
> 
>>> In most cases, this actually makes no difference in testing, because the
>>> locale data files for hr, in, lt, nl and sv simply duplicate the English
>>> values. Thus, the only ones that fail the test are no (uses a short era
>>> of "R") and sr_Latn ("Reiva").
>> 
>> Right, but why intentionally introduce test failures? I'm worried about
>> signal vs. noise here.
>> 
>>> I propose that we apply 8218781 for the locales we have now, and look at
>>> backporting updated CLDR data for 8u232 or 8u242. The updates -
>>> primarily JDK-8008577 - are tied up with configuration changes which we
>>> don't want to import to 8, so a backport will require some work and
>>> significant testing.
>>> 
>>> In short, please review this patch, taking into consideration that some
>>> locales will be absent and that data is duplicated for others
>>> (JDK-8159943, not in 8u, makes the short and long eras use a shared
>>> variable where they are identical)
>> 
>> Have you considered something like this patch so as to avoid the test
>> failures and then re-enable them once a fix comes in?
>> 
> 
> That seems like a good way to make sure it doesn't get fixed.
> 
>> diff --git a/test/java/util/Calendar/JapanEraNameCompatTest.java b/test/java/util/Calendar/JapanEraNameCompatTest.java
>> --- a/test/java/util/Calendar/JapanEraNameCompatTest.java
>> +++ b/test/java/util/Calendar/JapanEraNameCompatTest.java
>> @@ -96,12 +96,12 @@
>>             { new Locale("hi", "IN"), HindiName, HindiName },
>>             { new Locale("ru"), RussianName, RussianName },
>>             { new Locale("sr"), SerbianName, SerbianName },
>> -            { Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
>> +            //{ Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
>>             { new Locale("hr"), EngName, EngName },
>>             { new Locale("in"), EngName, EngName },
>>             { new Locale("lt"), EngName, EngName },
>>             { new Locale("nl"), EngName, EngName },
>> -            { new Locale("no"), EngName, "R" },
>> +            //{ new Locale("no"), EngName, "R" },
>>             { new Locale("sv"), EngName, EngName },
>>             // el fallback to root
>>             { new Locale("el"), EngName, EngName }
>> 
>> This would make it more apparent that it's intentional. Perhaps filing
>> a bug that it's not a complete fix would be even better. Thoughts?
>> 
> 
> As I said, the intention is to look at the viability of backporting the
> updated CLDR data. There are already bugs for that.
> 
>> Thanks,
>> Severin
>> 
>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/35818757a9c6/test/java/util/Calendar/JapanEraNameCompatTest.java#l29
>> 
> 
> -- 
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
> 


From gnu.andrew at redhat.com  Sat Jul  6 16:22:32 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Sat, 6 Jul 2019 17:22:32 +0100
Subject: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
 tzdata2019a and 8225580: tzdata2018i integration causes test failures on
 jdk-13
In-Reply-To: <0a339591-f5ac-4680-ac70-1a48d8699999@default>
References: <0a339591-f5ac-4680-ac70-1a48d8699999@default>
Message-ID: <aa0e5119-e552-9737-d2fc-d2e84a5aab9f@redhat.com>



On 05/07/2019 15:16, Ramanand Patil wrote:
> Hi all,
> Please review the patch for tzdata2019a integration into jdk project.
> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
> https://bugs.openjdk.java.net/browse/JDK-8225580
> 
> Summary:
> - The fix contains cumulative tzdata changes from tzdata2018i and tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier.
> - In JDK-13/14, multiple failures were seen during integration of tzdata2018i (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix for this in CLDRConverter.java.

I would guess this is due to the CLDR update (JDK-8221432: Upgrade CLDR
to Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs
inappropriate in some way?

Fix looks good. One minor change:

+            AVAILABLE_TZIDS = new HashSet(ZoneId.getAvailableZoneIds());

is missing the <String> or <>:

+            AVAILABLE_TZIDS = new HashSet<>(ZoneId.getAvailableZoneIds());

Will this fix also resolve JDK-8225580? If so, it's probably worth
mentioning both bug IDs in the commit.

> - There are 2 type of test failures in TestZoneInfo310.java file, which are solved in this patch by providing workarounds, But a permanent fix needs to be added in future for the same. Below are the 2 bugs created to track the development on it:
> 	1. https://bugs.openjdk.java.net/browse/JDK-8223388: TestZoneInfo310.java fails post tzdata2018i integration:
> This failure is seen for the TimeZones which are having zone rules defined till year 2037 or beyond. For now, the failing zones are skipped.
> The supporting test class ZoneInfo.java has maxYear defined http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/calendar/zi/Zoneinfo.java#l40, changing this max value greater than the zone rule's last year also fixes the issue, but further investigation is needed on why this boundary condition is affecting the test behavior.

I wonder if 2037 is in someway related to the rollover of 32-bit time
values?

> 	2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone rules:
> There are many hacks and assumptions in the class sun.util.calendar.ZoneInfoFile.java. This issue looks because of the code starting from here: http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java#l552
> There is an assumption where the transition date is >=24,(line 577 and 599) it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and Asia/Hebron zones.
> For now, I have fixed these 2 problematic timezones by overwriting the assumption made on line 577, where date of month dom = startRule.dom;
> I think, overriding of the second jdk hack on line 599 is not required as the "dom" is calculated from the last rule there. Keeping this bug open as we need to find a generic solution for this issue, without hard-coding the values and adding specific time zone names in exclusion as seen in many places in this class file.
> 
> - The patch has passed all the related testing including JCK tests.
> 
> 
> Regards,
> Ramanand.
>     
>     
>     
>     
> 

Looks good to me, with the above minor adjustment.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From gnu.andrew at redhat.com  Mon Jul  8 02:49:31 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 8 Jul 2019 03:49:31 +0100
Subject: <i18n dev> RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data to
	tzdata2019a
Message-ID: <c102a1b3-451e-8f31-f806-b312abdd95c5@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8224560
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8224560/webrev.01/

This is the 8u version of the patch proposed in [0]. It mostly applies
as is, but the CLDRConverter.java changes can be dropped (no JDK-8189784
and friends in 8u). The changes to TestZoneInfo310.java ideally should
be applied after JDK-8157792, which is a clean backport I have also
flagged with jdk8u-fix-request.

I don't know whether we want to still try and include this in 8u222 or
not. It is pretty late and people may already be testing finished builds.

Ok for 8u-dev?

[0] https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From ramanand.patil at oracle.com  Mon Jul  8 10:35:03 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 8 Jul 2019 03:35:03 -0700 (PDT)
Subject: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
 tzdata2019a and 8225580: tzdata2018i integration causes test failures on
 jdk-13
In-Reply-To: <aa0e5119-e552-9737-d2fc-d2e84a5aab9f@redhat.com>
References: <0a339591-f5ac-4680-ac70-1a48d8699999@default>
 <aa0e5119-e552-9737-d2fc-d2e84a5aab9f@redhat.com>
Message-ID: <e22d7da8-865b-43d9-8442-c44a795b15b7@default>

Hi Andrew,
Thank you for your review.
Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/

Regards,
Ramanand.

> -----Original Message-----
> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Sent: Saturday, July 6, 2019 9:53 PM
> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-
> dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
> tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-
> 13
> 
> 
> 
> On 05/07/2019 15:16, Ramanand Patil wrote:
> > Hi all,
> > Please review the patch for tzdata2019a integration into jdk project.
> > Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
> > Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
> > https://bugs.openjdk.java.net/browse/JDK-8225580
> >
> > Summary:
> > - The fix contains cumulative tzdata changes from tzdata2018i and
> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier.
> > - In JDK-13/14, multiple failures were seen during integration of tzdata2018i
> (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix
> for this in CLDRConverter.java.
> 
> I would guess this is due to the CLDR update (JDK-8221432: Upgrade CLDR to
> Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs
> inappropriate in some way?
> 
> Fix looks good. One minor change:
> 
> +            AVAILABLE_TZIDS = new
> + HashSet(ZoneId.getAvailableZoneIds());
> 
> is missing the <String> or <>:
> 
> +            AVAILABLE_TZIDS = new
> + HashSet<>(ZoneId.getAvailableZoneIds());
> 
> Will this fix also resolve JDK-8225580? If so, it's probably worth mentioning
> both bug IDs in the commit.
Yes, this fix will also resolve JDK-8225580, hence included in the subject line.
And thank you, I will add both bug IDs in the commit message.
> 
> > - There are 2 type of test failures in TestZoneInfo310.java file, which are
> solved in this patch by providing workarounds, But a permanent fix needs to
> be added in future for the same. Below are the 2 bugs created to track the
> development on it:
> > 	1. https://bugs.openjdk.java.net/browse/JDK-8223388:
> TestZoneInfo310.java fails post tzdata2018i integration:
> > This failure is seen for the TimeZones which are having zone rules defined
> till year 2037 or beyond. For now, the failing zones are skipped.
> > The supporting test class ZoneInfo.java has maxYear defined
> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/cale
> ndar/zi/Zoneinfo.java#l40, changing this max value greater than the zone
> rule's last year also fixes the issue, but further investigation is needed on why
> this boundary condition is affecting the test behavior.
> 
> I wonder if 2037 is in someway related to the rollover of 32-bit time values?
I think, not directly related but how the test and JDK handles these values.
In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I think the test somehow miscalculates it.
http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/share/classes/sun/util/calendar/ZoneInfo.java#l48
I think, I should re-visit and see if these test are really needed now. As per the long standing bug JDK-8166983 suggestion was to remove the whole tests from test/sun/util/calendar/zi
> 
> > 	2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293
> TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone
> rules:
> > There are many hacks and assumptions in the class
> > sun.util.calendar.ZoneInfoFile.java. This issue looks because of the
> > code starting from here:
> > http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/sha
> > re/classes/sun/util/calendar/ZoneInfoFile.java#l552
> > There is an assumption where the transition date is >=24,(line 577 and 599)
> it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and
> Asia/Hebron zones.
> > For now, I have fixed these 2 problematic timezones by overwriting the
> > assumption made on line 577, where date of month dom = startRule.dom; I
> think, overriding of the second jdk hack on line 599 is not required as the
> "dom" is calculated from the last rule there. Keeping this bug open as we
> need to find a generic solution for this issue, without hard-coding the values
> and adding specific time zone names in exclusion as seen in many places in
> this class file.
> >
> > - The patch has passed all the related testing including JCK tests.
> >
> >
> > Regards,
> > Ramanand.
> >
> >
> >
> >
> >
> 
> Looks good to me, with the above minor adjustment.
> 
> Thanks,
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint
> = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
> 

From andrew_m_leonard at uk.ibm.com  Mon Jul  8 13:38:09 2019
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Mon, 8 Jul 2019 14:38:09 +0100
Subject: <i18n dev> [8u] Re-examine closed i18n tests to see it they can
 be moved to the jdk repository
Message-ID: <OF34D44D2D.90BFD5CD-ON80258431.004AD3E8-80258431.004AE7C1@notes.na.collabserv.com>

Hi Andrew,
I'm currently still seeing these new tests still failing on the latest 
jdk8u, is there a locale data fix for these? or is there another issue 
with them?
  FAILED: java/util/Calendar/CalendarRegression.java
  FAILED: java/util/Calendar/JapanEraNameCompatTest.java
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From naoto.sato at oracle.com  Mon Jul  8 17:49:01 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 8 Jul 2019 10:49:01 -0700
Subject: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
 tzdata2019a and 8225580: tzdata2018i integration causes test failures on
 jdk-13
In-Reply-To: <e22d7da8-865b-43d9-8442-c44a795b15b7@default>
References: <0a339591-f5ac-4680-ac70-1a48d8699999@default>
 <aa0e5119-e552-9737-d2fc-d2e84a5aab9f@redhat.com>
 <e22d7da8-865b-43d9-8442-c44a795b15b7@default>
Message-ID: <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com>

Hi Ramanand,

As to the change in ZoneInfoFile.java, I would put that special handling 
of Gaza/Hebron in line 577, as well as merging the comment in 575,576, 
so that it won't duplicate the code.

Otherwise looks good.

Naoto

On 7/8/19 3:35 AM, Ramanand Patil wrote:
> Hi Andrew,
> Thank you for your review.
> Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/
> 
> Regards,
> Ramanand.
> 
>> -----Original Message-----
>> From: Andrew John Hughes <gnu.andrew at redhat.com>
>> Sent: Saturday, July 6, 2019 9:53 PM
>> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-
>> dev at openjdk.java.net; i18n-dev at openjdk.java.net
>> Subject: Re: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
>> tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-
>> 13
>>
>>
>>
>> On 05/07/2019 15:16, Ramanand Patil wrote:
>>> Hi all,
>>> Please review the patch for tzdata2019a integration into jdk project.
>>> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
>>> https://bugs.openjdk.java.net/browse/JDK-8225580
>>>
>>> Summary:
>>> - The fix contains cumulative tzdata changes from tzdata2018i and
>> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier.
>>> - In JDK-13/14, multiple failures were seen during integration of tzdata2018i
>> (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix
>> for this in CLDRConverter.java.
>>
>> I would guess this is due to the CLDR update (JDK-8221432: Upgrade CLDR to
>> Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs
>> inappropriate in some way?
>>
>> Fix looks good. One minor change:
>>
>> +            AVAILABLE_TZIDS = new
>> + HashSet(ZoneId.getAvailableZoneIds());
>>
>> is missing the <String> or <>:
>>
>> +            AVAILABLE_TZIDS = new
>> + HashSet<>(ZoneId.getAvailableZoneIds());
>>
>> Will this fix also resolve JDK-8225580? If so, it's probably worth mentioning
>> both bug IDs in the commit.
> Yes, this fix will also resolve JDK-8225580, hence included in the subject line.
> And thank you, I will add both bug IDs in the commit message.
>>
>>> - There are 2 type of test failures in TestZoneInfo310.java file, which are
>> solved in this patch by providing workarounds, But a permanent fix needs to
>> be added in future for the same. Below are the 2 bugs created to track the
>> development on it:
>>> 	1. https://bugs.openjdk.java.net/browse/JDK-8223388:
>> TestZoneInfo310.java fails post tzdata2018i integration:
>>> This failure is seen for the TimeZones which are having zone rules defined
>> till year 2037 or beyond. For now, the failing zones are skipped.
>>> The supporting test class ZoneInfo.java has maxYear defined
>> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/cale
>> ndar/zi/Zoneinfo.java#l40, changing this max value greater than the zone
>> rule's last year also fixes the issue, but further investigation is needed on why
>> this boundary condition is affecting the test behavior.
>>
>> I wonder if 2037 is in someway related to the rollover of 32-bit time values?
> I think, not directly related but how the test and JDK handles these values.
> In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I think the test somehow miscalculates it.
> http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/share/classes/sun/util/calendar/ZoneInfo.java#l48
> I think, I should re-visit and see if these test are really needed now. As per the long standing bug JDK-8166983 suggestion was to remove the whole tests from test/sun/util/calendar/zi
>>
>>> 	2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293
>> TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone
>> rules:
>>> There are many hacks and assumptions in the class
>>> sun.util.calendar.ZoneInfoFile.java. This issue looks because of the
>>> code starting from here:
>>> http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/sha
>>> re/classes/sun/util/calendar/ZoneInfoFile.java#l552
>>> There is an assumption where the transition date is >=24,(line 577 and 599)
>> it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and
>> Asia/Hebron zones.
>>> For now, I have fixed these 2 problematic timezones by overwriting the
>>> assumption made on line 577, where date of month dom = startRule.dom; I
>> think, overriding of the second jdk hack on line 599 is not required as the
>> "dom" is calculated from the last rule there. Keeping this bug open as we
>> need to find a generic solution for this issue, without hard-coding the values
>> and adding specific time zone names in exclusion as seen in many places in
>> this class file.
>>>
>>> - The patch has passed all the related testing including JCK tests.
>>>
>>>
>>> Regards,
>>> Ramanand.
>>>
>>>
>>>
>>>
>>>
>>
>> Looks good to me, with the above minor adjustment.
>>
>> Thanks,
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint
>> = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>> https://keybase.io/gnu_andrew
>>

From naoto.sato at oracle.com  Mon Jul  8 22:11:56 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 8 Jul 2019 15:11:56 -0700
Subject: <i18n dev> [13] RFR: 8227127: Era designator not displayed
 correctly using the COMPAT provider
Message-ID: <259bb4e9-b4ba-cde8-d2ff-afcb460866c3@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8227127

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8227127/webrev.00/

This is a regression caused by the fix to 8039301, where era display 
names are correctly retrieved with styles. This revealed that the short 
names for Gregorian eras are missing in COMPAT locale provider. 
Providing the proper display names in its resource bundles fixes the issue.

Naoto

From thejasvi.v.voniadka at oracle.com  Tue Jul  9 07:50:43 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Tue, 9 Jul 2019 00:50:43 -0700 (PDT)
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
 <590cca03-1741-41a2-9544-157d1f553835@default>
 <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>
 <d9e37b31-dc78-464b-9597-8ebde688e734@default>
 <d0d0f0c2-c456-c68a-7ee3-7d05088a4c8e@oracle.com>
 <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com>
 <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default>
Message-ID: <b993dd76-3977-4dba-b987-3b7230f8aab4@default>

Hi Roger,

Please find the updated webrev:

http://cr.openjdk.java.net/~vagarwal/8154520/webrev.4/


I have updated both lines 3924 and 3874 of .../java/time/format/DateTimeFormatterBuilder.java.

I have reduced the number of tests to just 3, and the number of locales to just 1 in java/time/format/TestLocalizedOffsetPrinterParser.java. That should provide sufficient coverage towards the functionality.



-----Original Message-----
From: Thejasvi Voniadka 
Sent: Friday, July 05, 2019 9:16 AM
To: Roger Riggs <roger.riggs at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: RE: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

Hi Roger,

?

Thank you for the review. I am in transit this weekend, but I will fix this and republish as soon as I can.

?

?

From: Roger Riggs 
Sent: Wednesday, July 03, 2019 10:46 PM
To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

?

Hi,

Looks ok, but...

.../java/time/format/DateTimeFormatterBuilder.java
3924: needs a space in "if(" -> "if ("

java/time/format/TestLocalizedOffsetPrinterParser.java

I would cut the number of test cases to a minimum; only need to ensure the code is correct.
We don't need to be testing the CLDR data; it is just? pass through.
At least cut the number of different locale's used to cut the risk of unexpected maintenance.

Thanks, Roger




On 7/3/19 12:10 PM, HYPERLINK "mailto:naoto.sato at oracle.com"naoto.sato at oracle.com wrote:

Looks good. 

Naoto 

On 7/3/19 5:32 AM, Thejasvi Voniadka wrote: 



Hi Naoto, 

Thank you for the review. Please find the updated webrev: 

http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/ 


The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java. 



-----Original Message----- 
From: Naoto Sato 
Sent: Tuesday, July 02, 2019 9:33 PM 
To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"<thejasvi.v.voniadka at oracle.com>; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net 
Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string 

Hi Thejasvi, 

Here are my comments to the webrev: 

TCKOffsetPrinterParser.java 

- No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test. 
Specifying Locale.US in line 572, 578, and 586 should suffice. 

TestOffsetPrinterParser.java 

- Copyright year is 2019. 

- It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR." 

- Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser. 

- Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data. 

- Line 111, 118, 124, 132: I believe the locale parameter is required. 
Make sure that with Objects.requireNonNull(), or fail if it's null. 

Naoto 

On 7/2/19 7:32 AM, Thejasvi Voniadka wrote: 



Hi Naoto, 

Thank you for the review. I have performed the modifications, and here is the updated webrev: 

http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/ 


I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format. 




-----Original Message----- 
From: Naoto Sato 
Sent: Monday, July 01, 2019 9:02 PM 
To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"<thejasvi.v.voniadka at oracle.com>; 
HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net 
Subject: Re: <i18n dev> RFR: 8154520: java.time: 
appendLocalizedOffset() should return the localized "GMT" string 

Hi Thejasvi, 

Thanks for fixing this. 

Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec. 
Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT." 

Naoto 

On 6/28/19 5:59 AM, Thejasvi Voniadka wrote: 



Hi, 

Request you to please review this change. 


JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520 


Description:??? At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value. 


Webrev:??? http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/ 


Additional notes:??? I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it. 

?

From ramanand.patil at oracle.com  Tue Jul  9 12:09:52 2019
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 9 Jul 2019 05:09:52 -0700 (PDT)
Subject: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
 tzdata2019a and 8225580: tzdata2018i integration causes test failures on
 jdk-13
In-Reply-To: <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com>
References: <0a339591-f5ac-4680-ac70-1a48d8699999@default>
 <aa0e5119-e552-9737-d2fc-d2e84a5aab9f@redhat.com>
 <e22d7da8-865b-43d9-8442-c44a795b15b7@default>
 <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com>
Message-ID: <cd00c790-767e-4fa7-8516-b43ed93f92d2@default>

Hi Naoto,
Thank you for the review. Revised webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/


I plan to push the changes tomorrow, if there are no further comments.


Regards,
Ramanand.

> -----Original Message-----
> From: Naoto Sato
> Sent: Monday, July 8, 2019 11:19 PM
> To: Ramanand Patil <ramanand.patil at oracle.com>; Andrew John Hughes
> <gnu.andrew at redhat.com>; core-libs-dev at openjdk.java.net; i18n-
> dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
> tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-
> 13
> 
> Hi Ramanand,
> 
> As to the change in ZoneInfoFile.java, I would put that special handling of
> Gaza/Hebron in line 577, as well as merging the comment in 575,576, so that
> it won't duplicate the code.
> 
> Otherwise looks good.
> 
> Naoto
> 
> On 7/8/19 3:35 AM, Ramanand Patil wrote:
> > Hi Andrew,
> > Thank you for your review.
> > Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/
> >
> > Regards,
> > Ramanand.
> >
> >> -----Original Message-----
> >> From: Andrew John Hughes <gnu.andrew at redhat.com>
> >> Sent: Saturday, July 6, 2019 9:53 PM
> >> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-
> >> dev at openjdk.java.net; i18n-dev at openjdk.java.net
> >> Subject: Re: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
> >> tzdata2019a and 8225580: tzdata2018i integration causes test failures
> >> on jdk-
> >> 13
> >>
> >>
> >>
> >> On 05/07/2019 15:16, Ramanand Patil wrote:
> >>> Hi all,
> >>> Please review the patch for tzdata2019a integration into jdk project.
> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
> >>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
> >>> https://bugs.openjdk.java.net/browse/JDK-8225580
> >>>
> >>> Summary:
> >>> - The fix contains cumulative tzdata changes from tzdata2018i and
> >> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier.
> >>> - In JDK-13/14, multiple failures were seen during integration of
> >>> tzdata2018i
> >> (JDK-8225580), those are fixed now. Many thanks to Naoto for
> >> providing a fix for this in CLDRConverter.java.
> >>
> >> I would guess this is due to the CLDR update (JDK-8221432: Upgrade
> >> CLDR to Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs
> >> inappropriate in some way?
> >>
> >> Fix looks good. One minor change:
> >>
> >> +            AVAILABLE_TZIDS = new
> >> + HashSet(ZoneId.getAvailableZoneIds());
> >>
> >> is missing the <String> or <>:
> >>
> >> +            AVAILABLE_TZIDS = new
> >> + HashSet<>(ZoneId.getAvailableZoneIds());
> >>
> >> Will this fix also resolve JDK-8225580? If so, it's probably worth
> >> mentioning both bug IDs in the commit.
> > Yes, this fix will also resolve JDK-8225580, hence included in the subject
> line.
> > And thank you, I will add both bug IDs in the commit message.
> >>
> >>> - There are 2 type of test failures in TestZoneInfo310.java file,
> >>> which are
> >> solved in this patch by providing workarounds, But a permanent fix
> >> needs to be added in future for the same. Below are the 2 bugs
> >> created to track the development on it:
> >>> 	1. https://bugs.openjdk.java.net/browse/JDK-8223388:
> >> TestZoneInfo310.java fails post tzdata2018i integration:
> >>> This failure is seen for the TimeZones which are having zone rules
> >>> defined
> >> till year 2037 or beyond. For now, the failing zones are skipped.
> >>> The supporting test class ZoneInfo.java has maxYear defined
> >> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/uti
> >> l/cale ndar/zi/Zoneinfo.java#l40, changing this max value greater
> >> than the zone rule's last year also fixes the issue, but further
> >> investigation is needed on why this boundary condition is affecting
> >> the test behavior.
> >>
> >> I wonder if 2037 is in someway related to the rollover of 32-bit time
> values?
> > I think, not directly related but how the test and JDK handles these values.
> > In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I
> think the test somehow miscalculates it.
> > http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/sha
> > re/classes/sun/util/calendar/ZoneInfo.java#l48
> > I think, I should re-visit and see if these test are really needed
> > now. As per the long standing bug JDK-8166983 suggestion was to remove
> > the whole tests from test/sun/util/calendar/zi
> >>
> >>> 	2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293
> >> TestZoneInfo310.java fails post tzdata2019a integration for Palestine
> >> zone
> >> rules:
> >>> There are many hacks and assumptions in the class
> >>> sun.util.calendar.ZoneInfoFile.java. This issue looks because of the
> >>> code starting from here:
> >>> http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/s
> >>> ha
> >>> re/classes/sun/util/calendar/ZoneInfoFile.java#l552
> >>> There is an assumption where the transition date is >=24,(line 577
> >>> and 599)
> >> it assumes it is the "last" rule, but it is not last rule in case of
> >> Asia/Gaza and Asia/Hebron zones.
> >>> For now, I have fixed these 2 problematic timezones by overwriting
> >>> the assumption made on line 577, where date of month dom =
> >>> startRule.dom; I
> >> think, overriding of the second jdk hack on line 599 is not required
> >> as the "dom" is calculated from the last rule there. Keeping this bug
> >> open as we need to find a generic solution for this issue, without
> >> hard-coding the values and adding specific time zone names in
> >> exclusion as seen in many places in this class file.
> >>>
> >>> - The patch has passed all the related testing including JCK tests.
> >>>
> >>>
> >>> Regards,
> >>> Ramanand.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> Looks good to me, with the above minor adjustment.
> >>
> >> Thanks,
> >> --
> >> Andrew :)
> >>
> >> Senior Free Java Software Engineer
> >> Red Hat, Inc. (http://www.redhat.com)
> >>
> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> >> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> >> https://keybase.io/gnu_andrew
> >>

From naoto.sato at oracle.com  Tue Jul  9 13:07:19 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 9 Jul 2019 06:07:19 -0700
Subject: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
 tzdata2019a and 8225580: tzdata2018i integration causes test failures on
 jdk-13
In-Reply-To: <cd00c790-767e-4fa7-8516-b43ed93f92d2@default>
References: <0a339591-f5ac-4680-ac70-1a48d8699999@default>
 <aa0e5119-e552-9737-d2fc-d2e84a5aab9f@redhat.com>
 <e22d7da8-865b-43d9-8442-c44a795b15b7@default>
 <52bdd34c-67b4-7e50-c555-15e49f250b0c@oracle.com>
 <cd00c790-767e-4fa7-8516-b43ed93f92d2@default>
Message-ID: <94fd20a2-8011-532b-2b11-f82ff023c423@oracle.com>

Looks good, Ramanand.

Naoto

On 7/9/19 5:09 AM, Ramanand Patil wrote:
> Hi Naoto,
> Thank you for the review. Revised webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/
> 
> 
> I plan to push the changes tomorrow, if there are no further comments.
> 
> 
> Regards,
> Ramanand.
> 
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Monday, July 8, 2019 11:19 PM
>> To: Ramanand Patil <ramanand.patil at oracle.com>; Andrew John Hughes
>> <gnu.andrew at redhat.com>; core-libs-dev at openjdk.java.net; i18n-
>> dev at openjdk.java.net
>> Subject: Re: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
>> tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-
>> 13
>>
>> Hi Ramanand,
>>
>> As to the change in ZoneInfoFile.java, I would put that special handling of
>> Gaza/Hebron in line 577, as well as merging the comment in 575,576, so that
>> it won't duplicate the code.
>>
>> Otherwise looks good.
>>
>> Naoto
>>
>> On 7/8/19 3:35 AM, Ramanand Patil wrote:
>>> Hi Andrew,
>>> Thank you for your review.
>>> Updated webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.01/
>>>
>>> Regards,
>>> Ramanand.
>>>
>>>> -----Original Message-----
>>>> From: Andrew John Hughes <gnu.andrew at redhat.com>
>>>> Sent: Saturday, July 6, 2019 9:53 PM
>>>> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-
>>>> dev at openjdk.java.net; i18n-dev at openjdk.java.net
>>>> Subject: Re: <i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to
>>>> tzdata2019a and 8225580: tzdata2018i integration causes test failures
>>>> on jdk-
>>>> 13
>>>>
>>>>
>>>>
>>>> On 05/07/2019 15:16, Ramanand Patil wrote:
>>>>> Hi all,
>>>>> Please review the patch for tzdata2019a integration into jdk project.
>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
>>>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
>>>>> https://bugs.openjdk.java.net/browse/JDK-8225580
>>>>>
>>>>> Summary:
>>>>> - The fix contains cumulative tzdata changes from tzdata2018i and
>>>> tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier.
>>>>> - In JDK-13/14, multiple failures were seen during integration of
>>>>> tzdata2018i
>>>> (JDK-8225580), those are fixed now. Many thanks to Naoto for
>>>> providing a fix for this in CLDRConverter.java.
>>>>
>>>> I would guess this is due to the CLDR update (JDK-8221432: Upgrade
>>>> CLDR to Version 35.1) in OpenJDK 13, making TimeZone.getAvailableIDs
>>>> inappropriate in some way?
>>>>
>>>> Fix looks good. One minor change:
>>>>
>>>> +            AVAILABLE_TZIDS = new
>>>> + HashSet(ZoneId.getAvailableZoneIds());
>>>>
>>>> is missing the <String> or <>:
>>>>
>>>> +            AVAILABLE_TZIDS = new
>>>> + HashSet<>(ZoneId.getAvailableZoneIds());
>>>>
>>>> Will this fix also resolve JDK-8225580? If so, it's probably worth
>>>> mentioning both bug IDs in the commit.
>>> Yes, this fix will also resolve JDK-8225580, hence included in the subject
>> line.
>>> And thank you, I will add both bug IDs in the commit message.
>>>>
>>>>> - There are 2 type of test failures in TestZoneInfo310.java file,
>>>>> which are
>>>> solved in this patch by providing workarounds, But a permanent fix
>>>> needs to be added in future for the same. Below are the 2 bugs
>>>> created to track the development on it:
>>>>> 	1. https://bugs.openjdk.java.net/browse/JDK-8223388:
>>>> TestZoneInfo310.java fails post tzdata2018i integration:
>>>>> This failure is seen for the TimeZones which are having zone rules
>>>>> defined
>>>> till year 2037 or beyond. For now, the failing zones are skipped.
>>>>> The supporting test class ZoneInfo.java has maxYear defined
>>>> http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/uti
>>>> l/cale ndar/zi/Zoneinfo.java#l40, changing this max value greater
>>>> than the zone rule's last year also fixes the issue, but further
>>>> investigation is needed on why this boundary condition is affecting
>>>> the test behavior.
>>>>
>>>> I wonder if 2037 is in someway related to the rollover of 32-bit time
>> values?
>>> I think, not directly related but how the test and JDK handles these values.
>>> In JDK, the transitions beyond 2037 are delegated to SimpleTimeZone, and I
>> think the test somehow miscalculates it.
>>> http://hg.openjdk.java.net/jdk/jdk/file/5919b273def6/src/java.base/sha
>>> re/classes/sun/util/calendar/ZoneInfo.java#l48
>>> I think, I should re-visit and see if these test are really needed
>>> now. As per the long standing bug JDK-8166983 suggestion was to remove
>>> the whole tests from test/sun/util/calendar/zi
>>>>
>>>>> 	2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293
>>>> TestZoneInfo310.java fails post tzdata2019a integration for Palestine
>>>> zone
>>>> rules:
>>>>> There are many hacks and assumptions in the class
>>>>> sun.util.calendar.ZoneInfoFile.java. This issue looks because of the
>>>>> code starting from here:
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/s
>>>>> ha
>>>>> re/classes/sun/util/calendar/ZoneInfoFile.java#l552
>>>>> There is an assumption where the transition date is >=24,(line 577
>>>>> and 599)
>>>> it assumes it is the "last" rule, but it is not last rule in case of
>>>> Asia/Gaza and Asia/Hebron zones.
>>>>> For now, I have fixed these 2 problematic timezones by overwriting
>>>>> the assumption made on line 577, where date of month dom =
>>>>> startRule.dom; I
>>>> think, overriding of the second jdk hack on line 599 is not required
>>>> as the "dom" is calculated from the last rule there. Keeping this bug
>>>> open as we need to find a generic solution for this issue, without
>>>> hard-coding the values and adding specific time zone names in
>>>> exclusion as seen in many places in this class file.
>>>>>
>>>>> - The patch has passed all the related testing including JCK tests.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Ramanand.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Looks good to me, with the above minor adjustment.
>>>>
>>>> Thanks,
>>>> --
>>>> Andrew :)
>>>>
>>>> Senior Free Java Software Engineer
>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>
>>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>>> https://keybase.io/gnu_andrew
>>>>

From Roger.Riggs at oracle.com  Tue Jul  9 14:09:35 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 9 Jul 2019 10:09:35 -0400
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset()
 should return the localized "GMT" string
In-Reply-To: <b993dd76-3977-4dba-b987-3b7230f8aab4@default>
References: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>
 <1e497a17-ac12-d2f6-064f-39c4cb15223b@oracle.com>
 <590cca03-1741-41a2-9544-157d1f553835@default>
 <0ba3fe52-ba6f-df36-7a99-d5b8741920fc@oracle.com>
 <d9e37b31-dc78-464b-9597-8ebde688e734@default>
 <d0d0f0c2-c456-c68a-7ee3-7d05088a4c8e@oracle.com>
 <0c7e5fbf-74fe-cb40-4878-5287bf6581ea@oracle.com>
 <24971d96-e27a-4d2d-bc2f-5290a353e2f4@default>
 <b993dd76-3977-4dba-b987-3b7230f8aab4@default>
Message-ID: <374dd44a-bd41-b48a-9943-bed34424b224@oracle.com>

Hi Thejasvi,

Looks good, thanks for the updates

Roger

On 7/9/19 3:50 AM, Thejasvi Voniadka wrote:
> Hi Roger,
>
> Please find the updated webrev:
>
> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.4/
>
>
> I have updated both lines 3924 and 3874 of .../java/time/format/DateTimeFormatterBuilder.java.
>
> I have reduced the number of tests to just 3, and the number of locales to just 1 in java/time/format/TestLocalizedOffsetPrinterParser.java. That should provide sufficient coverage towards the functionality.
>
>
>
> -----Original Message-----
> From: Thejasvi Voniadka
> Sent: Friday, July 05, 2019 9:16 AM
> To: Roger Riggs <roger.riggs at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: RE: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string
>
> Hi Roger,
>
>   
>
> Thank you for the review. I am in transit this weekend, but I will fix this and republish as soon as I can.
>
>   
>
>   
>
> From: Roger Riggs
> Sent: Wednesday, July 03, 2019 10:46 PM
> To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string
>
>   
>
> Hi,
>
> Looks ok, but...
>
> .../java/time/format/DateTimeFormatterBuilder.java
> 3924: needs a space in "if(" -> "if ("
>
> java/time/format/TestLocalizedOffsetPrinterParser.java
>
> I would cut the number of test cases to a minimum; only need to ensure the code is correct.
> We don't need to be testing the CLDR data; it is just? pass through.
> At least cut the number of different locale's used to cut the risk of unexpected maintenance.
>
> Thanks, Roger
>
>
>
>
> On 7/3/19 12:10 PM, HYPERLINK "mailto:naoto.sato at oracle.com"naoto.sato at oracle.com wrote:
>
> Looks good.
>
> Naoto
>
> On 7/3/19 5:32 AM, Thejasvi Voniadka wrote:
>
>
>
> Hi Naoto,
>
> Thank you for the review. Please find the updated webrev:
>
> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.3/
>
>
> The TCKOffsetPrinterParser.java has been reverted back to what it was, except for the copyright year and the locale addition. I have incorporated your comments to TestLocalizedOffsetPrinterParser.java.
>
>
>
> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, July 02, 2019 9:33 PM
> To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"<thejasvi.v.voniadka at oracle.com>; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string
>
> Hi Thejasvi,
>
> Here are my comments to the webrev:
>
> TCKOffsetPrinterParser.java
>
> - No need to define Locale_US as a static field, nor have it in the test data (data_print_localized) then pass it as an argument to the test.
> Specifying Locale.US in line 572, 578, and 586 should suffice.
>
> TestOffsetPrinterParser.java
>
> - Copyright year is 2019.
>
> - It would be nice if some comments that reads something like "This test relies on the localized text of "GMT" in the CLDR."
>
> - Test class (and the description) should include "Localized", as it is testing the implementation of localized version of OffsetIdPrinterParser.
>
> - Line 64-76: I prefer just instantiating them in the test data, not defining a static field for each, unless there will be duplicate in the test data.
>
> - Line 111, 118, 124, 132: I believe the locale parameter is required.
> Make sure that with Objects.requireNonNull(), or fail if it's null.
>
> Naoto
>
> On 7/2/19 7:32 AM, Thejasvi Voniadka wrote:
>
>
>
> Hi Naoto,
>
> Thank you for the review. I have performed the modifications, and here is the updated webrev:
>
> http://cr.openjdk.java.net/~vagarwal/8154520/webrev.2/
>
>
> I have moved the new tests from TCK area. I have also updated the current TCK test to explicitly pass Locale.US while calling format.
>
>
>
>
> -----Original Message-----
> From: Naoto Sato
> Sent: Monday, July 01, 2019 9:02 PM
> To: Thejasvi Voniadka HYPERLINK "mailto:thejasvi.v.voniadka at oracle.com"<thejasvi.v.voniadka at oracle.com>;
> HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> RFR: 8154520: java.time:
> appendLocalizedOffset() should return the localized "GMT" string
>
> Hi Thejasvi,
>
> Thanks for fixing this.
>
> Since those new test cases depend on the CLDR localization, which might change in other implementations, those test cases should be in jdk/java/time/test directory, as "tck" tests should only test the spec.
> Please create a new test case for this in the "test" directory (with @modules jdk.localedata directive) similar to the existing TCK one. Also the current test in the TCK should enforce that it runs in Locale.US so that the result should match "GMT."
>
> Naoto
>
> On 6/28/19 5:59 AM, Thejasvi Voniadka wrote:
>
>
>
> Hi,
>
> Request you to please review this change.
>
>
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8154520
>
>
> Description:??? At present, the "DateTimeFormatterBuilder.appendLocalizedOffset()" method formulates the base string as "GMT", without accounting for locale-specific transformations. This change is to return the localized version of "GMT" instead. So for example, instead of returning "GMT +5.30", it may now return "XXXX +5.30" where "XXXX" is the localized string for "GMT" for the locale associated with the formatter. I have used DateTimeTextProvider.getLocalizedResource() method to return the "gmtZeroFormat" value from CLDR/LDML corresponding to the given locale. The code defaults to "GMT" in the absence of such a localized value.
>
>
> Webrev:??? http://cr.openjdk.java.net/~vagarwal/8154520/webrev.1/
>
>
> Additional notes:??? I preferred to update and reuse an existing test instead of creating a new one. It already has the niceties in place, and creating another method would mean some amount of code redundancy. However, if that's the recommended norm, then I can change it.
>
>   


From ying.z.zhou at oracle.com  Wed Jul 10 06:53:31 2019
From: ying.z.zhou at oracle.com (Ying Zhou)
Date: Wed, 10 Jul 2019 14:53:31 +0800
Subject: <i18n dev> [14]RFR of JDK-8227289:Enable assertions for some shell
 to java conversion tests after JDK-8218960
Message-ID: <eaa8019e-440b-299f-d3a8-50ff6745d924@oracle.com>

Hello,

Please review this patch for updating below tests by adding -ea/esa to 
launcher parameters.

- /test/jdk/java/util/Calendar/SupplementalJapaneseEraTestRun.java
- /test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheckRun.java
- /test/jdk/java/util/TimeZone/Bug8066652Run.java
- 
/test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java
- /test/jdk/java/util/ResourceBundle/modules/ModuleTestUtil.java
- /test/jdk/java/util/ResourceBundle/modules/layer/LayerTest.java
- /test/jdk/java/util/ResourceBundle/modules/unnamed/UnNamedTest.java
- /test/jdk/java/util/ResourceBundle/modules/visibility/VisibilityTest.java

JDK Bug: JDK-8227289 <https://bugs.openjdk.java.net/browse/JDK-8227289>

webrev: http://cr.openjdk.java.net/~yzhou/8227289/webrev.00/

Thanks,

Daisy

From naoto.sato at oracle.com  Wed Jul 10 16:12:32 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 10 Jul 2019 09:12:32 -0700
Subject: <i18n dev> [14]RFR of JDK-8227289:Enable assertions for some
 shell to java conversion tests after JDK-8218960
In-Reply-To: <eaa8019e-440b-299f-d3a8-50ff6745d924@oracle.com>
References: <eaa8019e-440b-299f-d3a8-50ff6745d924@oracle.com>
Message-ID: <f98f15ad-8e86-b170-38f0-ab8922b8cbde@oracle.com>

Looks good to me.

Naoto

On 7/9/19 11:53 PM, Ying Zhou wrote:
> Hello,
> 
> Please review this patch for updating below tests by adding -ea/esa to 
> launcher parameters.
> 
> - /test/jdk/java/util/Calendar/SupplementalJapaneseEraTestRun.java
> - /test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheckRun.java
> - /test/jdk/java/util/TimeZone/Bug8066652Run.java
> - 
> /test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java
> - /test/jdk/java/util/ResourceBundle/modules/ModuleTestUtil.java
> - /test/jdk/java/util/ResourceBundle/modules/layer/LayerTest.java
> - /test/jdk/java/util/ResourceBundle/modules/unnamed/UnNamedTest.java
> - /test/jdk/java/util/ResourceBundle/modules/visibility/VisibilityTest.java
> 
> JDK Bug: JDK-8227289 <https://bugs.openjdk.java.net/browse/JDK-8227289>
> 
> webrev: http://cr.openjdk.java.net/~yzhou/8227289/webrev.00/
> 
> Thanks,
> 
> Daisy

From gnu.andrew at redhat.com  Thu Jul 11 17:16:27 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 11 Jul 2019 18:16:27 +0100
Subject: <i18n dev> RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data
	to tzdata2019a
In-Reply-To: <F25A290A-5EA0-4221-A97C-99ED80EA601D@azul.com>
References: <c102a1b3-451e-8f31-f806-b312abdd95c5@redhat.com>
 <F25A290A-5EA0-4221-A97C-99ED80EA601D@azul.com>
Message-ID: <29963c39-7cdc-62af-698f-c3f153fbac18@redhat.com>



On 11/07/2019 07:37, Dmitry Cherepanov wrote:
> Looks good to me.
> 
> One suggestion: does it make sense to include additional change in ZoneInfoFile.java to address the comment [1] in 8u too, it was fixed in the final patch for jdk/jdk13 [2].
> 
> Thanks,
> 
> Dmitry
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061216.html
> [2] https://hg.openjdk.java.net/jdk/jdk13/rev/8df81df1cce4#l13.1
> 

Yeah, my original post was based on the original webrev I reviewed prior
to that comment being made, and the final commit.

Here's an updated version based on the final commit, which I'm also
including in 8u222:

https://cr.openjdk.java.net/~andrew/openjdk8/8224560/webrev.02/

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew


From takiguc at linux.vnet.ibm.com  Fri Jul 19 13:57:49 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 19 Jul 2019 22:57:49 +0900
Subject: <i18n dev> 8227919:  8213232 causes crashes on solaris sparc64
Message-ID: <fd2d79ac2d59baaa5863b49c866ed51b@linux.vnet.ibm.com>

Hello.

I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1]

Please follow the steps:
1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC
2. Run xim_root on desktop
3. Move input focus to XIM demo window
4. Press Ctrl key and Press Right mouse button

Please put the output into JDK-8227919 [1] or post it into mailing list.
I really appreciate if you are using XIM like IIIMF.

[1] https://bugs.openjdk.java.net/browse/JDK-8227919
[2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c

Thanks,
Ichiroh Takiguchi


From takiguc at linux.vnet.ibm.com  Mon Jul 22 12:12:44 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 22 Jul 2019 21:12:44 +0900
Subject: <i18n dev> <AWT Dev> 8227919: 8213232 causes crashes on solaris
	sparc64
In-Reply-To: <D223AEFF-F430-40A3-B4BF-C81EB2058818@azul.com>
References: <fd2d79ac2d59baaa5863b49c866ed51b@linux.vnet.ibm.com>
 <D223AEFF-F430-40A3-B4BF-C81EB2058818@azul.com>
Message-ID: <af09bfec3f9e21c4a051b4f72eb55282@linux.vnet.ibm.com>

Hello Vladimir.

I appreciate your reply.

I did not expect "[1]w=0x0", it means xim_root could not receive focus 
window via XIC.
I checked ibus XIM server on Linux s390x platform again, it also 
returned "[1]w=0" ...
I was confused.

I'd like to add new instruction
5. Run xim_root with XMODIFIERS=@im=local environment variable on 
desktop, like
    $ XMODIFIERS=@im=local ./xim_root
6. Move input focus to XIM demo window
7. Press Ctrl key and Press Right mouse button

I tested xim_root on Linux s390x platform.

$ XMODIFIERS=@im=ibus ./xim_root
fevent = 0x3
topwindow = 0x1e00001, window = 0x1e00002
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945
XSetInputFocus() is called
FocusOut: window=0x1e00002(Internal Window)
  XUnsetICFocus
FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit)
FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit)
FocusIn: window=0x1e00002(Internal Window)
  XSetICFocus
KeyPress:
ButtonPress:
[1]w=0x0
[2]w=0x0
[1]state=0x0
[2]state=0x0
State: Unknown
ClientMessage is received

I tried it with XMODIFIERS=@im=local
$ XMODIFIERS=@im=local ./xim_root
fevent = 0
topwindow = 0x2000001, window = 0x2000002
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372
XSetInputFocus() is called
FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
FocusIn: window=0x2000002(Internal Window)
  XSetICFocus
KeyPress:
ButtonPress:
[1]w=0x2000002
[2]w=0x2000002
[1]state=0x2
[2]state=0x2
State: IM Off
ClientMessage is received

I was expected this result.
$ XMODIFIERS=@im=kinput2 ./xim_root
fevent = 0x3
topwindow = 0x2000001, window = 0x2000002
ClientMessage is received
WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128
XSetInputFocus() is called
FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
FocusIn: window=0x2000002(Internal Window)
  XSetICFocus
KeyPress:
ButtonPress:
[1]w=0x200000200000000
[2]w=0x2000002
[1]state=0x200000000
[2]state=0x2
State: IM Off
ClientMessage is received

I'm sorry, it seemed current code did not work on even if Linux s390x 
platform.

Thanks,
Ichiroh Takiguchi

On 2019-07-19 23:29, Vladimir Kempik wrote:
> Hello
> I?m probably missing something about XIM on X side here, using ssh
> -X from ubuntu(with Xserver) to solaris11 sparc64 machine
> 
> the output is
> 
> fevent = 0x3
> topwindow = 0x3800001, window = 0x3800002
> ClientMessage is received
> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503
> XSetInputFocus() is called
> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x3800002(Internal Window)
>  XSetICFocus
> FocusOut: window=0x3800002(Internal Window)
>  XUnsetICFocus
> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit)
> ClientMessage is received
> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238
> XSetInputFocus() is called
> ButtonPress:
> [1]w=0x0
> [2]w=0x0
> [1]state=0x0
> [2]state=0x0
> State: Unknown
> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x3800002(Internal Window)
> 
> 
> I also had to press left button, not right one.
> 
> 
> I think when you initialy created 8213232 you were targeting linux
> ppc64 BE system in your patch and simply forgot about another 64-bit
> BE system - solaris sparc64
> 
> I would propose this fix for 8227919
> 
> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
> @@ -1671,7 +1671,7 @@
>  {
>      X11InputMethodData *pX11IMData = NULL;
>      char * ret = NULL;
> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN)
> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN)
>      // XIMPreeditState value which is used for XGetICValues must be
> 32bit on BigEndian XOrg's xlib
>      unsigned int state = XIMPreeditUnKnown;
>  #else
> 
> Such change already allowed to pass our internal tests on solaris 
> sparc64
> 
> if you think it?s ok then let me take over and finish with 8227919
> 
> Thanks, Vladimir
> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi
> <takiguc at linux.vnet.ibm.com<mailto:takiguc at linux.vnet.ibm.com>>
> ???????(?):
> 
> Hello.
> 
> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1]
> 
> Please follow the steps:
> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC
> 2. Run xim_root on desktop
> 3. Move input focus to XIM demo window
> 4. Press Ctrl key and Press Right mouse button
> 
> Please put the output into JDK-8227919 [1] or post it into mailing 
> list.
> I really appreciate if you are using XIM like IIIMF.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8227919
> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c
> 
> Thanks,
> Ichiroh Takiguchi

From naoto.sato at oracle.com  Mon Jul 22 14:54:40 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 22 Jul 2019 07:54:40 -0700
Subject: <i18n dev> [13] RFR: 8228450: unicode.md and icu.md text should be
	pre-formatted
Message-ID: <a09db303-7ec9-b1eb-cf96-2fabda984cb0@oracle.com>

Hi,

Please review this doc only fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8228450

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8228450/webrev.00/

This is simply to supply triple back ticks (```) in the .md files so 
that the text will not be formatted on HTML conversion.

Naoto

From Roger.Riggs at oracle.com  Mon Jul 22 15:01:14 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 22 Jul 2019 11:01:14 -0400
Subject: <i18n dev> [13] RFR: 8228450: unicode.md and icu.md text should
 be pre-formatted
In-Reply-To: <a09db303-7ec9-b1eb-cf96-2fabda984cb0@oracle.com>
References: <a09db303-7ec9-b1eb-cf96-2fabda984cb0@oracle.com>
Message-ID: <a1a6fdde-46b4-ac5f-17d2-5e8b31ec8456@oracle.com>

Looks fine

On 7/22/19 10:54 AM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review this doc only fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8228450
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8228450/webrev.00/
>
> This is simply to supply triple back ticks (```) in the .md files so 
> that the text will not be formatted on HTML conversion.
>
> Naoto


From takiguc at linux.vnet.ibm.com  Mon Jul 22 18:08:14 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 23 Jul 2019 03:08:14 +0900
Subject: <i18n dev> <AWT Dev> 8227919: 8213232 causes crashes on solaris
	sparc64
In-Reply-To: <AF7A9AFF-3563-41EF-B283-8AF57AFEFAAD@azul.com>
References: <fd2d79ac2d59baaa5863b49c866ed51b@linux.vnet.ibm.com>
 <D223AEFF-F430-40A3-B4BF-C81EB2058818@azul.com>
 <af09bfec3f9e21c4a051b4f72eb55282@linux.vnet.ibm.com>
 <AF7A9AFF-3563-41EF-B283-8AF57AFEFAAD@azul.com>
Message-ID: <ebba94e9ea7db4230c340a76ec34160d@linux.vnet.ibm.com>

Hello Vladimir.

I really appreciate your help.

"XMODIFIERS=@im=local" is related Multi key Compose feature [1]
One of document said "XMODIFIERS=@im=none" [2]

Could you try "XMODIFIERS=@im=none" ?

[1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml
[2] https://fedoraproject.org/wiki/I18N/InputMethods

Thanks,
Ichiroh Takiguchi

On 2019-07-22 23:58, Vladimir Kempik wrote:
> Hello
> I?m getting Bus Error on startup with
> XMODIFIERS=@im=local ./xim_root
> nothing yet in log at that moment.
> 
> Thanks, Vladimir
> 
>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi 
>> <takiguc at linux.vnet.ibm.com> ???????(?):
>> 
>> Hello Vladimir.
>> 
>> I appreciate your reply.
>> 
>> I did not expect "[1]w=0x0", it means xim_root could not receive focus 
>> window via XIC.
>> I checked ibus XIM server on Linux s390x platform again, it also 
>> returned "[1]w=0" ...
>> I was confused.
>> 
>> I'd like to add new instruction
>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on 
>> desktop, like
>>   $ XMODIFIERS=@im=local ./xim_root
>> 6. Move input focus to XIM demo window
>> 7. Press Ctrl key and Press Right mouse button
>> 
>> I tested xim_root on Linux s390x platform.
>> 
>> $ XMODIFIERS=@im=ibus ./xim_root
>> fevent = 0x3
>> topwindow = 0x1e00001, window = 0x1e00002
>> ClientMessage is received
>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945
>> XSetInputFocus() is called
>> FocusOut: window=0x1e00002(Internal Window)
>> XUnsetICFocus
>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit)
>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit)
>> FocusIn: window=0x1e00002(Internal Window)
>> XSetICFocus
>> KeyPress:
>> ButtonPress:
>> [1]w=0x0
>> [2]w=0x0
>> [1]state=0x0
>> [2]state=0x0
>> State: Unknown
>> ClientMessage is received
>> 
>> I tried it with XMODIFIERS=@im=local
>> $ XMODIFIERS=@im=local ./xim_root
>> fevent = 0
>> topwindow = 0x2000001, window = 0x2000002
>> ClientMessage is received
>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372
>> XSetInputFocus() is called
>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
>> FocusIn: window=0x2000002(Internal Window)
>> XSetICFocus
>> KeyPress:
>> ButtonPress:
>> [1]w=0x2000002
>> [2]w=0x2000002
>> [1]state=0x2
>> [2]state=0x2
>> State: IM Off
>> ClientMessage is received
>> 
>> I was expected this result.
>> $ XMODIFIERS=@im=kinput2 ./xim_root
>> fevent = 0x3
>> topwindow = 0x2000001, window = 0x2000002
>> ClientMessage is received
>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128
>> XSetInputFocus() is called
>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
>> FocusIn: window=0x2000002(Internal Window)
>> XSetICFocus
>> KeyPress:
>> ButtonPress:
>> [1]w=0x200000200000000
>> [2]w=0x2000002
>> [1]state=0x200000000
>> [2]state=0x2
>> State: IM Off
>> ClientMessage is received
>> 
>> I'm sorry, it seemed current code did not work on even if Linux s390x 
>> platform.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2019-07-19 23:29, Vladimir Kempik wrote:
>>> Hello
>>> I?m probably missing something about XIM on X side here, using ssh
>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine
>>> the output is
>>> fevent = 0x3
>>> topwindow = 0x3800001, window = 0x3800002
>>> ClientMessage is received
>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503
>>> XSetInputFocus() is called
>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
>>> FocusIn: window=0x3800002(Internal Window)
>>> XSetICFocus
>>> FocusOut: window=0x3800002(Internal Window)
>>> XUnsetICFocus
>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit)
>>> ClientMessage is received
>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238
>>> XSetInputFocus() is called
>>> ButtonPress:
>>> [1]w=0x0
>>> [2]w=0x0
>>> [1]state=0x0
>>> [2]state=0x0
>>> State: Unknown
>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
>>> FocusIn: window=0x3800002(Internal Window)
>>> I also had to press left button, not right one.
>>> I think when you initialy created 8213232 you were targeting linux
>>> ppc64 BE system in your patch and simply forgot about another 64-bit
>>> BE system - solaris sparc64
>>> I would propose this fix for 8227919
>>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>> @@ -1671,7 +1671,7 @@
>>> {
>>>     X11InputMethodData *pX11IMData = NULL;
>>>     char * ret = NULL;
>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN)
>>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN)
>>>     // XIMPreeditState value which is used for XGetICValues must be
>>> 32bit on BigEndian XOrg's xlib
>>>     unsigned int state = XIMPreeditUnKnown;
>>> #else
>>> Such change already allowed to pass our internal tests on solaris 
>>> sparc64
>>> if you think it?s ok then let me take over and finish with 8227919
>>> Thanks, Vladimir
>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi
>>> <takiguc at linux.vnet.ibm.com 
>>> <mailto:takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com 
>>> <mailto:takiguc at linux.vnet.ibm.com>>>
>>> ???????(?):
>>> Hello.
>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1]
>>> Please follow the steps:
>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC
>>> 2. Run xim_root on desktop
>>> 3. Move input focus to XIM demo window
>>> 4. Press Ctrl key and Press Right mouse button
>>> Please put the output into JDK-8227919 [1] or post it into mailing 
>>> list.
>>> I really appreciate if you are using XIM like IIIMF.
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919
>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c
>>> Thanks,
>>> Ichiroh Takiguchi


From takiguc at linux.vnet.ibm.com  Fri Jul 26 12:53:49 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 26 Jul 2019 21:53:49 +0900
Subject: <i18n dev> RFR [13] 8227919: 8213232 causes crashes on solaris
	sparc64
In-Reply-To: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com>
References: <fd2d79ac2d59baaa5863b49c866ed51b@linux.vnet.ibm.com>
 <D223AEFF-F430-40A3-B4BF-C81EB2058818@azul.com>
 <af09bfec3f9e21c4a051b4f72eb55282@linux.vnet.ibm.com>
 <AF7A9AFF-3563-41EF-B283-8AF57AFEFAAD@azul.com>
 <ebba94e9ea7db4230c340a76ec34160d@linux.vnet.ibm.com>
 <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com>
Message-ID: <aa86f9adad81cb26853c645a82951410@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8227919
Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/

It's crash issue for Solaris SPARC platform.
If possible, please push this fix into 13.

XIMPreditState is changed to unsigned long instead of unsigned int on 
64bit Big endian.
It's same as Java8.
I think Solaris SPARC's issue can be fixed by this fix.

Vladimir,
I appreciate your great help.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2019-07-23 20:00, Vladimir Kempik wrote:
> Hello
> 
> it still crashes with  "Bus Error"
> 
> I guess I may miss something on X server side.
> Thanks, Vladimir.
> 
>> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi 
>> <takiguc at linux.vnet.ibm.com> ???????(?):
>> 
>> Hello Vladimir.
>> 
>> I really appreciate your help.
>> 
>> "XMODIFIERS=@im=local" is related Multi key Compose feature [1]
>> One of document said "XMODIFIERS=@im=none" [2]
>> 
>> Could you try "XMODIFIERS=@im=none" ?
>> 
>> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml 
>> <https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml>
>> [2] https://fedoraproject.org/wiki/I18N/InputMethods 
>> <https://fedoraproject.org/wiki/I18N/InputMethods>
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2019-07-22 23:58, Vladimir Kempik wrote:
>>> Hello
>>> I?m getting Bus Error on startup with
>>> XMODIFIERS=@im=local ./xim_root
>>> nothing yet in log at that moment.
>>> Thanks, Vladimir
>>>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi 
>>>> <takiguc at linux.vnet.ibm.com> ???????(?):
>>>> Hello Vladimir.
>>>> I appreciate your reply.
>>>> I did not expect "[1]w=0x0", it means xim_root could not receive 
>>>> focus window via XIC.
>>>> I checked ibus XIM server on Linux s390x platform again, it also 
>>>> returned "[1]w=0" ...
>>>> I was confused.
>>>> I'd like to add new instruction
>>>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on 
>>>> desktop, like
>>>>  $ XMODIFIERS=@im=local ./xim_root
>>>> 6. Move input focus to XIM demo window
>>>> 7. Press Ctrl key and Press Right mouse button
>>>> I tested xim_root on Linux s390x platform.
>>>> $ XMODIFIERS=@im=ibus ./xim_root
>>>> fevent = 0x3
>>>> topwindow = 0x1e00001, window = 0x1e00002
>>>> ClientMessage is received
>>>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945
>>>> XSetInputFocus() is called
>>>> FocusOut: window=0x1e00002(Internal Window)
>>>> XUnsetICFocus
>>>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit)
>>>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit)
>>>> FocusIn: window=0x1e00002(Internal Window)
>>>> XSetICFocus
>>>> KeyPress:
>>>> ButtonPress:
>>>> [1]w=0x0
>>>> [2]w=0x0
>>>> [1]state=0x0
>>>> [2]state=0x0
>>>> State: Unknown
>>>> ClientMessage is received
>>>> I tried it with XMODIFIERS=@im=local
>>>> $ XMODIFIERS=@im=local ./xim_root
>>>> fevent = 0
>>>> topwindow = 0x2000001, window = 0x2000002
>>>> ClientMessage is received
>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372
>>>> XSetInputFocus() is called
>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
>>>> FocusIn: window=0x2000002(Internal Window)
>>>> XSetICFocus
>>>> KeyPress:
>>>> ButtonPress:
>>>> [1]w=0x2000002
>>>> [2]w=0x2000002
>>>> [1]state=0x2
>>>> [2]state=0x2
>>>> State: IM Off
>>>> ClientMessage is received
>>>> I was expected this result.
>>>> $ XMODIFIERS=@im=kinput2 ./xim_root
>>>> fevent = 0x3
>>>> topwindow = 0x2000001, window = 0x2000002
>>>> ClientMessage is received
>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128
>>>> XSetInputFocus() is called
>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
>>>> FocusIn: window=0x2000002(Internal Window)
>>>> XSetICFocus
>>>> KeyPress:
>>>> ButtonPress:
>>>> [1]w=0x200000200000000
>>>> [2]w=0x2000002
>>>> [1]state=0x200000000
>>>> [2]state=0x2
>>>> State: IM Off
>>>> ClientMessage is received
>>>> I'm sorry, it seemed current code did not work on even if Linux 
>>>> s390x platform.
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> On 2019-07-19 23:29, Vladimir Kempik wrote:
>>>>> Hello
>>>>> I?m probably missing something about XIM on X side here, using 
>>>>> ssh
>>>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine
>>>>> the output is
>>>>> fevent = 0x3
>>>>> topwindow = 0x3800001, window = 0x3800002
>>>>> ClientMessage is received
>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503
>>>>> XSetInputFocus() is called
>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
>>>>> FocusIn: window=0x3800002(Internal Window)
>>>>> XSetICFocus
>>>>> FocusOut: window=0x3800002(Internal Window)
>>>>> XUnsetICFocus
>>>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit)
>>>>> ClientMessage is received
>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238
>>>>> XSetInputFocus() is called
>>>>> ButtonPress:
>>>>> [1]w=0x0
>>>>> [2]w=0x0
>>>>> [1]state=0x0
>>>>> [2]state=0x0
>>>>> State: Unknown
>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
>>>>> FocusIn: window=0x3800002(Internal Window)
>>>>> I also had to press left button, not right one.
>>>>> I think when you initialy created 8213232 you were targeting linux
>>>>> ppc64 BE system in your patch and simply forgot about another 
>>>>> 64-bit
>>>>> BE system - solaris sparc64
>>>>> I would propose this fix for 8227919
>>>>> --- 
>>>>> a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>>> +++ 
>>>>> b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
>>>>> @@ -1671,7 +1671,7 @@
>>>>> {
>>>>>    X11InputMethodData *pX11IMData = NULL;
>>>>>    char * ret = NULL;
>>>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN)
>>>>> +#if defined(__linux__) && defined(_LP64) && 
>>>>> !defined(_LITTLE_ENDIAN)
>>>>>    // XIMPreeditState value which is used for XGetICValues must be
>>>>> 32bit on BigEndian XOrg's xlib
>>>>>    unsigned int state = XIMPreeditUnKnown;
>>>>> #else
>>>>> Such change already allowed to pass our internal tests on solaris 
>>>>> sparc64
>>>>> if you think it?s ok then let me take over and finish with 
>>>>> 8227919
>>>>> Thanks, Vladimir
>>>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi
>>>>> <takiguc at linux.vnet.ibm.com <mailto:takiguc at linux.vnet.ibm.com> 
>>>>> <mailto:takiguc at linux.vnet.ibm.com 
>>>>> <mailto:takiguc at linux.vnet.ibm.com>><mailto:takiguc at linux.vnet.ibm.com 
>>>>> <mailto:takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com 
>>>>> <mailto:takiguc at linux.vnet.ibm.com>>>>
>>>>> ???????(?):
>>>>> Hello.
>>>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 
>>>>> [1]
>>>>> Please follow the steps:
>>>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC
>>>>> 2. Run xim_root on desktop
>>>>> 3. Move input focus to XIM demo window
>>>>> 4. Press Ctrl key and Press Right mouse button
>>>>> Please put the output into JDK-8227919 [1] or post it into mailing 
>>>>> list.
>>>>> I really appreciate if you are using XIM like IIIMF.
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919
>>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c
>>>>> Thanks,
>>>>> Ichiroh Takiguchi


From naoto.sato at oracle.com  Fri Jul 26 18:03:33 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 26 Jul 2019 11:03:33 -0700
Subject: <i18n dev> [14] RFR: 8228465: HOST locale provider holds wrong era
 name for GregorianCalendar in US locale
Message-ID: <896001db-ee9f-b5c6-09ff-a605f2429c4f@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8228465

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8228465/webrev.00/

Similar issue was reported with JDK-8039301, in which 
Calendar.getDisplayName() method was modified. The same fix needs to be 
applied to Calendar.getDisplayNames().

Naoto

From lance.andersen at oracle.com  Fri Jul 26 18:23:48 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 26 Jul 2019 14:23:48 -0400
Subject: <i18n dev> [14] RFR: 8228465: HOST locale provider holds wrong
 era name for GregorianCalendar in US locale
In-Reply-To: <896001db-ee9f-b5c6-09ff-a605f2429c4f@oracle.com>
References: <896001db-ee9f-b5c6-09ff-a605f2429c4f@oracle.com>
Message-ID: <11C84D42-898B-43D2-AB51-724349F00339@oracle.com>

Hi Naoto,

This looks good

> On Jul 26, 2019, at 2:03 PM, naoto.sato at oracle.com wrote:
> 
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8228465
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8228465/webrev.00/
> 
> Similar issue was reported with JDK-8039301, in which Calendar.getDisplayName() method was modified. The same fix needs to be applied to Calendar.getDisplayNames().
> 
> Naoto

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From TAKIGUC at jp.ibm.com  Mon Jul 29 12:44:46 2019
From: TAKIGUC at jp.ibm.com (Ichiroh Takiguchi)
Date: Mon, 29 Jul 2019 21:44:46 +0900
Subject: <i18n dev> <AWT Dev> RFR [13] 8227919: 8213232 causes crashes
	on solaris sparc64
In-Reply-To: <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com>
References: <fd2d79ac2d59baaa5863b49c866ed51b@linux.vnet.ibm.com>
 <D223AEFF-F430-40A3-B4BF-C81EB2058818@azul.com>
 <af09bfec3f9e21c4a051b4f72eb55282@linux.vnet.ibm.com>
 <AF7A9AFF-3563-41EF-B283-8AF57AFEFAAD@azul.com>
 <ebba94e9ea7db4230c340a76ec34160d@linux.vnet.ibm.com>
 <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com>
 <aa86f9adad81cb26853c645a82951410@linux.vnet.ibm.com>
 <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com>
Message-ID: <OF69A9A2E1.CAEB5230-ON00258446.0044A9B6-49258446.0046037D@notes.na.collabserv.com>

Hello Vladimir.
I appreciate your suggestion.

And I'm very sorry for bad response.
Our mail server for external mailing list is downed in these days.
So I'd like to use another email address.

Please see following 2 outputs.
> $ XMODIFIERS=@im=local ./xim_root
......
> ButtonPress:
> [1]w=0x2000002
> [2]w=0x2000002
> [1]state=0x2
> [2]state=0x2

> $ XMODIFIERS=@im=kinput2 ./xim_root
......
> ButtonPress:
> [1]w=0x200000200000000
> [2]w=0x2000002
> [1]state=0x200000000
> [2]state=0x2

These mean
@im=local is used low 32bit on 64bit long  <= The data comes from Xlib
@im=kinput2 is used high 32bit on 64bit long  <= The data comes from XIM 
protocol

So following code changes is required on Linux s390x, it was my mistake.
if (w > 0xffffffffUL) w = w >> 32;

I created another fix, could you review it ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8227919
Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/

It changes:
* 0xffffffffL is changed to 0xffffffffUL
* defined(__linux__) is added into defined(_LP64) line

Thanks,
------
Ichiro Takiguchi 
    IBM Japan Ltd.

"awt-dev" <awt-dev-bounces at openjdk.java.net> wrote on 2019/07/26 21:59:59:

> From: Vladimir Kempik <vkempik at azul.com>
> To: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
> Cc: "awt-dev at openjdk.java.net" <awt-dev at openjdk.java.net>, "i18n-
> dev at openjdk.java.net" <i18n-dev at openjdk.java.net>
> Date: 2019/07/26 22:01
> Subject: [EXTERNAL] Re: <AWT Dev> RFR [13] 8227919: 8213232 causes 
> crashes on solaris sparc64
> Sent by: "awt-dev" <awt-dev-bounces at openjdk.java.net>
> 
> Hello
> 
> what still bothers me is this:
> 
> The first Big Endian block:
> 
> 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN)
> 1630         // On 64bit BigEndian,
> 1631         // Window value may be stored on high 32bit by 
> XGetICValues via XIM
> 1632         if (w > 0xffffffffL) w = w >> 32;
> 1633 #endif
> 
> is inside linux&macos block
> 
> 1622 #if defined(__linux__) || defined(MACOSX)

> 
> however the second Big Endian block is for every platform:
> 
> 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN)
> 1699     // On 64bit BigEndian,
> 1700     // XIMPreeditState value may be stored on high 32bit by 
> XGetICValues via XIM
> 1701     if (state > 0xffffffffL) state = state >> 32;
> 1702 #endif
> I?m not sure if it?s ok or not.
> 
> Also, since XIMPreeditState is unsigned 64-bit int, I think we need 
> to compare it against 0xffffffffUL instead of 0xffffffffL
> 
> typedef unsigned long int XIMPreeditState;

> 
> Thanks, Vladimir
> 
> 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com
> > ???????(?):
> 
> Hello.
> 
> Could you review the fix ?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8227919
> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/
> 
> It's crash issue for Solaris SPARC platform.
> If possible, please push this fix into 13.
> 
> XIMPreditState is changed to unsigned long instead of unsigned int 
> on 64bit Big endian.
> It's same as Java8.
> I think Solaris SPARC's issue can be fixed by this fix.
> 
> Vladimir,
> I appreciate your great help.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2019-07-23 20:00, Vladimir Kempik wrote:
> Hello
> it still crashes with  "Bus Error"
> I guess I may miss something on X server side.
> Thanks, Vladimir.
> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com
> > ???????(?):
> Hello Vladimir.
> I really appreciate your help.
> "XMODIFIERS=@im=local" is related Multi key Compose feature [1]
> One of document said "XMODIFIERS=@im=none" [2]
> Could you try "XMODIFIERS=@im=none" ?
> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml <
> https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml>
> [2] https://fedoraproject.org/wiki/I18N/InputMethods <https://
> fedoraproject.org/wiki/I18N/InputMethods>
> Thanks,
> Ichiroh Takiguchi
> On 2019-07-22 23:58, Vladimir Kempik wrote:
> Hello
> I?m getting Bus Error on startup with
> XMODIFIERS=@im=local ./xim_root
> nothing yet in log at that moment.
> Thanks, Vladimir
> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com
> > ???????(?):
> Hello Vladimir.
> I appreciate your reply.
> I did not expect "[1]w=0x0", it means xim_root could not receive 
> focus window via XIC.
> I checked ibus XIM server on Linux s390x platform again, it also 
> returned "[1]w=0" ...
> I was confused.
> I'd like to add new instruction
> 5. Run xim_root with XMODIFIERS=@im=local environment variable on 
> desktop, like
> $ XMODIFIERS=@im=local ./xim_root
> 6. Move input focus to XIM demo window
> 7. Press Ctrl key and Press Right mouse button
> I tested xim_root on Linux s390x platform.
> $ XMODIFIERS=@im=ibus ./xim_root
> fevent = 0x3
> topwindow = 0x1e00001, window = 0x1e00002
> ClientMessage is received
> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945
> XSetInputFocus() is called
> FocusOut: window=0x1e00002(Internal Window)
> XUnsetICFocus
> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x1e00002(Internal Window)
> XSetICFocus
> KeyPress:
> ButtonPress:
> [1]w=0x0
> [2]w=0x0
> [1]state=0x0
> [2]state=0x0
> State: Unknown
> ClientMessage is received
> I tried it with XMODIFIERS=@im=local
> $ XMODIFIERS=@im=local ./xim_root
> fevent = 0
> topwindow = 0x2000001, window = 0x2000002
> ClientMessage is received
> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372
> XSetInputFocus() is called
> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x2000002(Internal Window)
> XSetICFocus
> KeyPress:
> ButtonPress:
> [1]w=0x2000002
> [2]w=0x2000002
> [1]state=0x2
> [2]state=0x2
> State: IM Off
> ClientMessage is received
> I was expected this result.
> $ XMODIFIERS=@im=kinput2 ./xim_root
> fevent = 0x3
> topwindow = 0x2000001, window = 0x2000002
> ClientMessage is received
> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128
> XSetInputFocus() is called
> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x2000002(Internal Window)
> XSetICFocus
> KeyPress:
> ButtonPress:
> [1]w=0x200000200000000
> [2]w=0x2000002
> [1]state=0x200000000
> [2]state=0x2
> State: IM Off
> ClientMessage is received
> I'm sorry, it seemed current code did not work on even if Linux 
> s390x platform.
> Thanks,
> Ichiroh Takiguchi
> On 2019-07-19 23:29, Vladimir Kempik wrote:
> Hello
> I?m probably missing something about XIM on X side here, using ssh
> -X from ubuntu(with Xserver) to solaris11 sparc64 machine
> the output is
> fevent = 0x3
> topwindow = 0x3800001, window = 0x3800002
> ClientMessage is received
> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503
> XSetInputFocus() is called
> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x3800002(Internal Window)
> XSetICFocus
> FocusOut: window=0x3800002(Internal Window)
> XUnsetICFocus
> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit)
> ClientMessage is received
> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238
> XSetInputFocus() is called
> ButtonPress:
> [1]w=0x0
> [2]w=0x0
> [1]state=0x0
> [2]state=0x0
> State: Unknown
> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit)
> FocusIn: window=0x3800002(Internal Window)
> I also had to press left button, not right one.
> I think when you initialy created 8213232 you were targeting linux
> ppc64 BE system in your patch and simply forgot about another 64-bit
> BE system - solaris sparc64
> I would propose this fix for 8227919
> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
> @@ -1671,7 +1671,7 @@
> {
>   X11InputMethodData *pX11IMData = NULL;
>   char * ret = NULL;
> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN)
> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN)
>   // XIMPreeditState value which is used for XGetICValues must be
> 32bit on BigEndian XOrg's xlib
>   unsigned int state = XIMPreeditUnKnown;
> #else
> Such change already allowed to pass our internal tests on solaris 
sparc64
> if you think it?s ok then let me take over and finish with 8227919
> Thanks, Vladimir
> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi
> <takiguc at linux.vnet.ibm.com <mailto:takiguc at linux.vnet.ibm.com> <
> mailto:takiguc at linux.vnet.ibm.com <mailto:takiguc at linux.vnet.ibm.com>><
> mailto:takiguc at linux.vnet.ibm.com <mailto:takiguc at linux.vnet.ibm.com><
> mailto:takiguc at linux.vnet.ibm.com <mailto:takiguc at linux.vnet.ibm.com>>>>
> ???????(?):
> Hello.
> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1]
> Please follow the steps:
> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC
> 2. Run xim_root on desktop
> 3. Move input focus to XIM demo window
> 4. Press Ctrl key and Press Right mouse button
> Please put the output into JDK-8227919 [1] or post it into mailing list.
> I really appreciate if you are using XIM like IIIMF.
> [1] https://bugs.openjdk.java.net/browse/JDK-8227919
> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c
> Thanks,
> Ichiroh Takiguchi


From thejasvi.v.voniadka at oracle.com  Tue Jul 30 12:54:27 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Tue, 30 Jul 2019 05:54:27 -0700 (PDT)
Subject: <i18n dev> RFR: 8160225: java.time.format.DateTimeFormatter issues
 for month-of-year
Message-ID: <c165994d-23d6-4209-8eec-cc48680c014a@default>

Hi,

Request your review of this simple change.

JBS:    https://bugs.openjdk.java.net/browse/JDK-8160225 (java.time.format.DateTimeFormatter issues for month-of-year)

Description:    It is a simple documentation change. The DateTimeFormatter expects the month format to be represented by "L" for number and "M" for text (eg: "Jul" may be accepted by a format string "MMM"; "07" may be accepted by a format string "LL", and so on). However, the documentation lists this somewhat confusingly:

"M/L month-of-year number/text 7; 07; Jul; July; J"

A casual reader may interpret "M" as the numeric representation and "L" as the textual representation of the month-of-year, whereas the actual behavior of the API is the other way around. This patch fixes it.


Webrev:    http://cr.openjdk.java.net/~vagarwal/8160225/webrev.0/





From naoto.sato at oracle.com  Tue Jul 30 16:09:26 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 30 Jul 2019 09:09:26 -0700
Subject: <i18n dev> RFR: 8160225: java.time.format.DateTimeFormatter
 issues for month-of-year
In-Reply-To: <c165994d-23d6-4209-8eec-cc48680c014a@default>
References: <c165994d-23d6-4209-8eec-cc48680c014a@default>
Message-ID: <59eda23b-dcfe-ef25-d3c1-26e7e3c8ded7@oracle.com>

Hi Thejasvi,

M/L does not designate textual nor numeric. Thus I don't think that the 
suggested documentation fix is correct. Furthermore, although the 
exception in JDK8 looks like a bug, the test result with JDK9 looks 
correct to me. The month displayed as "04" is the result of 
ZonedDateTime.toString() so should not be localized.

Naoto

On 7/30/19 5:54 AM, Thejasvi Voniadka wrote:
> Hi,
> 
> Request your review of this simple change.
> 
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8160225 (java.time.format.DateTimeFormatter issues for month-of-year)
> 
> Description:    It is a simple documentation change. The DateTimeFormatter expects the month format to be represented by "L" for number and "M" for text (eg: "Jul" may be accepted by a format string "MMM"; "07" may be accepted by a format string "LL", and so on). However, the documentation lists this somewhat confusingly:
> 
> "M/L month-of-year number/text 7; 07; Jul; July; J"
> 
> A casual reader may interpret "M" as the numeric representation and "L" as the textual representation of the month-of-year, whereas the actual behavior of the API is the other way around. This patch fixes it.
> 
> 
> Webrev:    http://cr.openjdk.java.net/~vagarwal/8160225/webrev.0/
> 
> 
> 
> 

From thejasvi.v.voniadka at oracle.com  Wed Jul 31 05:29:21 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Tue, 30 Jul 2019 22:29:21 -0700 (PDT)
Subject: <i18n dev> RFR: 8160225: java.time.format.DateTimeFormatter
 issues for month-of-year
In-Reply-To: <59eda23b-dcfe-ef25-d3c1-26e7e3c8ded7@oracle.com>
References: <c165994d-23d6-4209-8eec-cc48680c014a@default>
 <59eda23b-dcfe-ef25-d3c1-26e7e3c8ded7@oracle.com>
Message-ID: <da239f50-3057-4bd8-a3b5-8b8c34aad1e0@default>

Hi Naoto,

Thank you for the response. You are correct. I ran the reproducer against JDK13 and JDK9, and they appear not to differentiate between L and M as long as the input is consistent. I will update the bug and revise the effort accordingly. Thanks!!



-----Original Message-----
From: Naoto Sato 
Sent: Tuesday, July 30, 2019 9:39 PM
To: Thejasvi Voniadka <thejasvi.v.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year

Hi Thejasvi,

M/L does not designate textual nor numeric. Thus I don't think that the suggested documentation fix is correct. Furthermore, although the exception in JDK8 looks like a bug, the test result with JDK9 looks correct to me. The month displayed as "04" is the result of
ZonedDateTime.toString() so should not be localized.

Naoto

On 7/30/19 5:54 AM, Thejasvi Voniadka wrote:
> Hi,
> 
> Request your review of this simple change.
> 
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8160225 (java.time.format.DateTimeFormatter issues for month-of-year)
> 
> Description:    It is a simple documentation change. The DateTimeFormatter expects the month format to be represented by "L" for number and "M" for text (eg: "Jul" may be accepted by a format string "MMM"; "07" may be accepted by a format string "LL", and so on). However, the documentation lists this somewhat confusingly:
> 
> "M/L month-of-year number/text 7; 07; Jul; July; J"
> 
> A casual reader may interpret "M" as the numeric representation and "L" as the textual representation of the month-of-year, whereas the actual behavior of the API is the other way around. This patch fixes it.
> 
> 
> Webrev:    http://cr.openjdk.java.net/~vagarwal/8160225/webrev.0/
> 
> 
> 
>