From claes.redestad at oracle.com  Sat Jun  1 00:13:35 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 1 Jun 2019 02:13:35 +0200
Subject: <i18n dev> RFR: 8225061: Performance regression in Regex
Message-ID: <4f665c8c-5afa-3121-4671-3cc92f8b1a48@oracle.com>

Hi,

recent Unicode 12.1 updates caused a noticeable regression to Mac OS X
build times.

Quoting Naoto:
"The regression was caused by the call to Grapheme.nextBoundary() in
NFCCharProperty.match() method, which got slower with the fix to
JDK-8221431 / JDK-8222978 (Unicode 12.1 / Grapheme 12.0 support). The
purpose of issuing nextBoundary() is to detect whether to call (much
heavy weight) Normalizer.normalize() call or not. Since this fast check
does not require fully fledged boundary detection, including stateful
segmentation check such as Emoji sequence, simply checking the break
possibility between two code points as before should suffice. Suggested
fix is to bring back the isBoundary(cp1, cp2) method from the previous
revision in Grapheme.java, and issue it only from
NFCCharProperty.match() method for the fast check."

Bug:    https://bugs.openjdk.java.net/browse/JDK-8225061
Webrev: http://cr.openjdk.java.net/~redestad/8225061/open.01/

While narrowing this down, I created a couple of microbenchmarks and
experimented with a sequence of optimizations that got the regression of
using the heavier nextBoundary() check down from about 300x to just
about 2x as costly as before JDK-8221431. These improvements were then
bypassed by reverting to isBoundary in some micros, but still helps a
lot in other cases that has taken a toll from making the grapheme logic
more complete/correct, so I'd like to leave them in.

Testing: tier1-3, verified a 300x speedup in the complex
Pattern.CANON_EQ micro, and a 2x speedup on the simpler Grapheme/\\b{g}
micro.

Thanks!

/Claes

From naoto.sato at oracle.com  Sat Jun  1 00:23:08 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 31 May 2019 17:23:08 -0700
Subject: <i18n dev> RFR: 8225061: Performance regression in Regex
In-Reply-To: <4f665c8c-5afa-3121-4671-3cc92f8b1a48@oracle.com>
References: <4f665c8c-5afa-3121-4671-3cc92f8b1a48@oracle.com>
Message-ID: <4ebb190d-aa71-650f-c74f-5f77da72c2bd@oracle.com>

Hi Claes,

Looks good to me. Thanks for catching this on so quickly!

Naoto

On 5/31/19 5:13 PM, Claes Redestad wrote:
> Hi,
> 
> recent Unicode 12.1 updates caused a noticeable regression to Mac OS X
> build times.
> 
> Quoting Naoto:
> "The regression was caused by the call to Grapheme.nextBoundary() in
> NFCCharProperty.match() method, which got slower with the fix to
> JDK-8221431 / JDK-8222978 (Unicode 12.1 / Grapheme 12.0 support). The
> purpose of issuing nextBoundary() is to detect whether to call (much
> heavy weight) Normalizer.normalize() call or not. Since this fast check
> does not require fully fledged boundary detection, including stateful
> segmentation check such as Emoji sequence, simply checking the break
> possibility between two code points as before should suffice. Suggested
> fix is to bring back the isBoundary(cp1, cp2) method from the previous
> revision in Grapheme.java, and issue it only from
> NFCCharProperty.match() method for the fast check."
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8225061
> Webrev: http://cr.openjdk.java.net/~redestad/8225061/open.01/
> 
> While narrowing this down, I created a couple of microbenchmarks and
> experimented with a sequence of optimizations that got the regression of
> using the heavier nextBoundary() check down from about 300x to just
> about 2x as costly as before JDK-8221431. These improvements were then
> bypassed by reverting to isBoundary in some micros, but still helps a
> lot in other cases that has taken a toll from making the grapheme logic
> more complete/correct, so I'd like to leave them in.
> 
> Testing: tier1-3, verified a 300x speedup in the complex
> Pattern.CANON_EQ micro, and a 2x speedup on the simpler Grapheme/\\b{g}
> micro.
> 
> Thanks!
> 
> /Claes

From claes.redestad at oracle.com  Sat Jun  1 00:58:59 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 1 Jun 2019 02:58:59 +0200
Subject: <i18n dev> RFR: 8225061: Performance regression in Regex
In-Reply-To: <4ebb190d-aa71-650f-c74f-5f77da72c2bd@oracle.com>
References: <4f665c8c-5afa-3121-4671-3cc92f8b1a48@oracle.com>
 <4ebb190d-aa71-650f-c74f-5f77da72c2bd@oracle.com>
Message-ID: <f9101d90-689e-9b0f-111d-dc5d7334b968@oracle.com>

Hi Naoto,

thanks for reviewing!

/Claes

On 2019-06-01 02:23, naoto.sato at oracle.com wrote:
> Hi Claes,
> 
> Looks good to me. Thanks for catching this on so quickly!
> 
> Naoto
> 
> On 5/31/19 5:13 PM, Claes Redestad wrote:
>> Hi,
>>
>> recent Unicode 12.1 updates caused a noticeable regression to Mac OS X
>> build times.
>>
>> Quoting Naoto:
>> "The regression was caused by the call to Grapheme.nextBoundary() in
>> NFCCharProperty.match() method, which got slower with the fix to
>> JDK-8221431 / JDK-8222978 (Unicode 12.1 / Grapheme 12.0 support). The
>> purpose of issuing nextBoundary() is to detect whether to call (much
>> heavy weight) Normalizer.normalize() call or not. Since this fast check
>> does not require fully fledged boundary detection, including stateful
>> segmentation check such as Emoji sequence, simply checking the break
>> possibility between two code points as before should suffice. Suggested
>> fix is to bring back the isBoundary(cp1, cp2) method from the previous
>> revision in Grapheme.java, and issue it only from
>> NFCCharProperty.match() method for the fast check."
>>
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8225061
>> Webrev: http://cr.openjdk.java.net/~redestad/8225061/open.01/
>>
>> While narrowing this down, I created a couple of microbenchmarks and
>> experimented with a sequence of optimizations that got the regression of
>> using the heavier nextBoundary() check down from about 300x to just
>> about 2x as costly as before JDK-8221431. These improvements were then
>> bypassed by reverting to isBoundary in some micros, but still helps a
>> lot in other cases that has taken a toll from making the grapheme logic
>> more complete/correct, so I'd like to leave them in.
>>
>> Testing: tier1-3, verified a 300x speedup in the complex
>> Pattern.CANON_EQ micro, and a 2x speedup on the simpler Grapheme/\\b{g}
>> micro.
>>
>> Thanks!
>>
>> /Claes

From naoto.sato at oracle.com  Tue Jun 18 19:37:44 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 18 Jun 2019 12:37:44 -0700
Subject: <i18n dev> [14]RFR: 8220229: Timezone pattern "OOOO" does not
 result in the full "GMT+00:00" substring
Message-ID: <e25a14cd-fb6f-2a48-00ad-d72280336f79@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset and CSR are located at:

https://cr.openjdk.java.net/~naoto/8220229/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8226308

This is to simply clarify the cases for zero offset.

Naoto

From lance.andersen at oracle.com  Tue Jun 18 19:44:28 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 18 Jun 2019 15:44:28 -0400
Subject: <i18n dev> [14]RFR: 8220229: Timezone pattern "OOOO" does not
 result in the full "GMT+00:00" substring
In-Reply-To: <e25a14cd-fb6f-2a48-00ad-d72280336f79@oracle.com>
References: <e25a14cd-fb6f-2a48-00ad-d72280336f79@oracle.com>
Message-ID: <FDAA63E7-F542-4EB0-BB4B-54860BCC3B82@oracle.com>

Hi Naoto,

It reads OK.  I will add myself as a CSR reviewer also

> On Jun 18, 2019, at 3:37 PM, naoto.sato at oracle.com wrote:
> 
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8220229
> 
> The proposed changeset and CSR are located at:
> 
> https://cr.openjdk.java.net/~naoto/8220229/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8226308
> 
> This is to simply clarify the cases for zero offset.
> 
> 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 gnu.andrew at redhat.com  Fri Jun 21 15:46:07 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 21 Jun 2019 16:46:07 +0100
Subject: <i18n dev> RFR: [8u] JDK-8218781: Localized names for Japanese Era
 Reiwa in COMPAT provider
Message-ID: <0e093fe1-2bc5-c1ba-0f69-3e1754ebdef4@redhat.com>

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.

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").

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)

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 christoph.langer at sap.com  Thu Jun 27 08:51:21 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Jun 2019 08:51:21 +0000
Subject: <i18n dev> RFR(S): 8226869: Test
 java/util/Locale/LocaleProvidersRun.java should enable assertions (and
 reporting an issue that's unveiled by this)
Message-ID: <DB7PR02MB5193A59F0A2EFD3B303C24A78AFD0@DB7PR02MB5193.eurprd02.prod.outlook.com>

Hi,

Please, first of all, review a little test fix. Java level assertions should be enabled in test java/util/Locale/LocaleProvidersRun.java. It was (probably inadvertently) removed by refactoring the test with JDK-8210403 (Refactor java.util.Locale:i18n shell tests to plain java tests).

Resolving this bug will unveil a regression on Windows caused by JDK-8218960 (CONFIG level logging statements printed in CLDRCalendarDataProviderImpl.java even when default log Level is INFO) for which I just created a bug report: https://bugs.openjdk.java.net/browse/JDK-8226876. I discovered this because I backported JDK-8218960 to JDK11u and encountered the assertion in the old test.

Since this test fix will open up a new test failure, I?m not sure whether it should be pushed to JDK13. If JDK-8226876 could be resolved quickly, the fix for this issue could be pushed after it. Or I add a temporary exclusion for Windows to the test list ? however that would probably disable other important regression tests. Please advise.

That said, please assign JDK-8226876 to the right engineer - it?s not my area of expertise ??

Bug: https://bugs.openjdk.java.net/browse/JDK-8226869
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226869.0/

Thanks
Christoph


From naoto.sato at oracle.com  Thu Jun 27 16:03:20 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 27 Jun 2019 09:03:20 -0700
Subject: <i18n dev> RFR(S): 8226869: Test
 java/util/Locale/LocaleProvidersRun.java should enable assertions (and
 reporting an issue that's unveiled by this)
In-Reply-To: <DB7PR02MB5193A59F0A2EFD3B303C24A78AFD0@DB7PR02MB5193.eurprd02.prod.outlook.com>
References: <DB7PR02MB5193A59F0A2EFD3B303C24A78AFD0@DB7PR02MB5193.eurprd02.prod.outlook.com>
Message-ID: <e2fc9c17-ede6-4890-338e-bacb359473ee@oracle.com>

Hi Christoph,

Thanks for discovering the issue and resolving it. Your change looks 
good to me. We will work on the actual issue you raised shortly.

Naoto

On 6/27/19 1:51 AM, Langer, Christoph wrote:
> Hi,
> 
> Please, first of all, review a little test fix. Java level assertions 
> should be enabled in test java/util/Locale/LocaleProvidersRun.java. It 
> was (probably inadvertently) removed by refactoring the test with 
> JDK-8210403 (Refactor java.util.Locale:i18n shell tests to plain java 
> tests).
> 
> Resolving this bug will unveil a regression on Windows caused by 
> JDK-8218960 (CONFIG level logging statements printed in 
> CLDRCalendarDataProviderImpl.java even when default log Level is INFO) 
> for which I just created a bug report: 
> https://bugs.openjdk.java.net/browse/JDK-8226876. I discovered this 
> because I backported JDK-8218960 to JDK11u and encountered the assertion 
> in the old test.
> 
> Since this test fix will open up a new test failure, I?m not sure 
> whether it should be pushed to JDK13. If JDK-8226876 could be resolved 
> quickly, the fix for this issue could be pushed after it. Or I add a 
> temporary exclusion for Windows to the test list ? however that would 
> probably disable other important regression tests. Please advise.
> 
> That said, please assign JDK-8226876 to the right engineer - it?s not my 
> area of expertise ??
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226869
> 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226869.0/
> 
> Thanks
> 
> Christoph
> 

From naoto.sato at oracle.com  Thu Jun 27 20:21:58 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 27 Jun 2019 13:21:58 -0700
Subject: <i18n dev> [13] RFR: 8226876: Assertion in
 sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
Message-ID: <8172c65e-b4ff-bba1-97b5-9558b2dcb3cd@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

This is an issue discovered on fixing a test case refactoring. [1] The 
fix is to simply provide the default values to the first-day-of-week and 
minimal-days-in-first-week, if the underlying providers cannot provide them.

Naoto

[1] https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002868.html

From christoph.langer at sap.com  Thu Jun 27 20:52:19 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Jun 2019 20:52:19 +0000
Subject: <i18n dev> [13] RFR: 8226876: Assertion in
 sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
In-Reply-To: <8172c65e-b4ff-bba1-97b5-9558b2dcb3cd@oracle.com>
References: <8172c65e-b4ff-bba1-97b5-9558b2dcb3cd@oracle.com>
Message-ID: <AM6PR02MB5192F6A4C1C1FBB9A9B231A98AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Naoto,

thanks for providing a fix so quickly.

The change looks good to me. But I would say the assertion in CalendarDataUtility in line 266 is pointless now, isn't it?

Best regards
Christoph

> -----Original Message-----
> From: i18n-dev <i18n-dev-bounces at openjdk.java.net> On Behalf Of
> naoto.sato at oracle.com
> Sent: Donnerstag, 27. Juni 2019 22:22
> To: i18n-dev at openjdk.java.net; core-libs-dev <core-libs-
> dev at openjdk.java.net>
> Subject: <i18n dev> [13] RFR: 8226876: Assertion in
> sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
> 
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8226876
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8226876/webrev.00/
> 
> This is an issue discovered on fixing a test case refactoring. [1] The
> fix is to simply provide the default values to the first-day-of-week and
> minimal-days-in-first-week, if the underlying providers cannot provide them.
> 
> Naoto
> 
> [1] https://mail.openjdk.java.net/pipermail/i18n-dev/2019-
> June/002868.html

From naoto.sato at oracle.com  Thu Jun 27 21:00:58 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 27 Jun 2019 14:00:58 -0700
Subject: <i18n dev> [13] RFR: 8226876: Assertion in
 sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
In-Reply-To: <AM6PR02MB5192F6A4C1C1FBB9A9B231A98AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <8172c65e-b4ff-bba1-97b5-9558b2dcb3cd@oracle.com>
 <AM6PR02MB5192F6A4C1C1FBB9A9B231A98AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <8579e7bc-9c59-68f2-336e-bc24d030eee7@oracle.com>

On 6/27/19 1:52 PM, Langer, Christoph wrote:
> Hi Naoto,
> 
> thanks for providing a fix so quickly.
> 
> The change looks good to me. But I would say the assertion in CalendarDataUtility in line 266 is pointless now, isn't it?

Yes, but would not hurt leaving it. It would catch error if yet another 
case is installed (and it forgot to provide a default value) in the 
switch statement. So I just left it.

Naoto

> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: i18n-dev <i18n-dev-bounces at openjdk.java.net> On Behalf Of
>> naoto.sato at oracle.com
>> Sent: Donnerstag, 27. Juni 2019 22:22
>> To: i18n-dev at openjdk.java.net; core-libs-dev <core-libs-
>> dev at openjdk.java.net>
>> Subject: <i18n dev> [13] RFR: 8226876: Assertion in
>> sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
>>
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8226876
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8226876/webrev.00/
>>
>> This is an issue discovered on fixing a test case refactoring. [1] The
>> fix is to simply provide the default values to the first-day-of-week and
>> minimal-days-in-first-week, if the underlying providers cannot provide them.
>>
>> Naoto
>>
>> [1] https://mail.openjdk.java.net/pipermail/i18n-dev/2019-
>> June/002868.html

From christoph.langer at sap.com  Thu Jun 27 21:05:01 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Jun 2019 21:05:01 +0000
Subject: <i18n dev> [13] RFR: 8226876: Assertion in
 sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
In-Reply-To: <8579e7bc-9c59-68f2-336e-bc24d030eee7@oracle.com>
References: <8172c65e-b4ff-bba1-97b5-9558b2dcb3cd@oracle.com>
 <AM6PR02MB5192F6A4C1C1FBB9A9B231A98AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8579e7bc-9c59-68f2-336e-bc24d030eee7@oracle.com>
Message-ID: <AM6PR02MB519289BB441970E00ED93A508AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>

> > The change looks good to me. But I would say the assertion in
> CalendarDataUtility in line 266 is pointless now, isn't it?
> 
> Yes, but would not hurt leaving it. It would catch error if yet another
> case is installed (and it forgot to provide a default value) in the
> switch statement. So I just left it.

Ok, sounds reasonable.

What's your target for pushing this? I'd like to backport it to OpenJDK 11.0.4 to fix the regression there...

/Christoph


From christoph.langer at sap.com  Thu Jun 27 21:09:08 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Jun 2019 21:09:08 +0000
Subject: <i18n dev> RFR(S): 8226869: Test
 java/util/Locale/LocaleProvidersRun.java should enable assertions (and
 reporting an issue that's unveiled by this)
In-Reply-To: <e2fc9c17-ede6-4890-338e-bacb359473ee@oracle.com>
References: <DB7PR02MB5193A59F0A2EFD3B303C24A78AFD0@DB7PR02MB5193.eurprd02.prod.outlook.com>
 <e2fc9c17-ede6-4890-338e-bacb359473ee@oracle.com>
Message-ID: <AM6PR02MB51927C16179564F0976ACC778AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Thanks Naoto.

I'll hold back the push (in JDK13) until JDK-8226876 is in.

/Christoph

> -----Original Message-----
> From: naoto.sato at oracle.com <naoto.sato at oracle.com>
> Sent: Donnerstag, 27. Juni 2019 18:03
> To: Langer, Christoph <christoph.langer at sap.com>; i18n-
> dev at openjdk.java.net; Java Core Libs <core-libs-dev at openjdk.java.net>
> Cc: Ying Zhou <ying.z.zhou at oracle.com>
> Subject: Re: RFR(S): 8226869: Test java/util/Locale/LocaleProvidersRun.java
> should enable assertions (and reporting an issue that's unveiled by this)
> 
> Hi Christoph,
> 
> Thanks for discovering the issue and resolving it. Your change looks
> good to me. We will work on the actual issue you raised shortly.
> 
> Naoto
> 
> On 6/27/19 1:51 AM, Langer, Christoph wrote:
> > Hi,
> >
> > Please, first of all, review a little test fix. Java level assertions
> > should be enabled in test java/util/Locale/LocaleProvidersRun.java. It
> > was (probably inadvertently) removed by refactoring the test with
> > JDK-8210403 (Refactor java.util.Locale:i18n shell tests to plain java
> > tests).
> >
> > Resolving this bug will unveil a regression on Windows caused by
> > JDK-8218960 (CONFIG level logging statements printed in
> > CLDRCalendarDataProviderImpl.java even when default log Level is INFO)
> > for which I just created a bug report:
> > https://bugs.openjdk.java.net/browse/JDK-8226876. I discovered this
> > because I backported JDK-8218960 to JDK11u and encountered the
> assertion
> > in the old test.
> >
> > Since this test fix will open up a new test failure, I?m not sure
> > whether it should be pushed to JDK13. If JDK-8226876 could be resolved
> > quickly, the fix for this issue could be pushed after it. Or I add a
> > temporary exclusion for Windows to the test list ? however that would
> > probably disable other important regression tests. Please advise.
> >
> > That said, please assign JDK-8226876 to the right engineer - it?s not my
> > area of expertise ??
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8226869
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226869.0/
> >
> > Thanks
> >
> > Christoph
> >

From naoto.sato at oracle.com  Thu Jun 27 21:15:55 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 27 Jun 2019 14:15:55 -0700
Subject: <i18n dev> [13] RFR: 8226876: Assertion in
 sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
In-Reply-To: <AM6PR02MB519289BB441970E00ED93A508AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <8172c65e-b4ff-bba1-97b5-9558b2dcb3cd@oracle.com>
 <AM6PR02MB5192F6A4C1C1FBB9A9B231A98AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8579e7bc-9c59-68f2-336e-bc24d030eee7@oracle.com>
 <AM6PR02MB519289BB441970E00ED93A508AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <c615a005-0242-5b08-42b2-15a53ed94f66@oracle.com>

Thanks for the review, Christoph.

I'll wait for a whole day so that everyone sees the fix. Planning to 
push it tomorrow.

Naoto

On 6/27/19 2:05 PM, Langer, Christoph wrote:
>>> The change looks good to me. But I would say the assertion in
>> CalendarDataUtility in line 266 is pointless now, isn't it?
>>
>> Yes, but would not hurt leaving it. It would catch error if yet another
>> case is installed (and it forgot to provide a default value) in the
>> switch statement. So I just left it.
> 
> Ok, sounds reasonable.
> 
> What's your target for pushing this? I'd like to backport it to OpenJDK 11.0.4 to fix the regression there...
> 
> /Christoph
> 

From christoph.langer at sap.com  Thu Jun 27 21:18:01 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 27 Jun 2019 21:18:01 +0000
Subject: <i18n dev> [13] RFR: 8226876: Assertion in
 sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
In-Reply-To: <c615a005-0242-5b08-42b2-15a53ed94f66@oracle.com>
References: <8172c65e-b4ff-bba1-97b5-9558b2dcb3cd@oracle.com>
 <AM6PR02MB5192F6A4C1C1FBB9A9B231A98AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <8579e7bc-9c59-68f2-336e-bc24d030eee7@oracle.com>
 <AM6PR02MB519289BB441970E00ED93A508AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <c615a005-0242-5b08-42b2-15a53ed94f66@oracle.com>
Message-ID: <AM6PR02MB519220B8BB24290A35DF23D68AFD0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Sounds great. Thank you.

> -----Original Message-----
> From: naoto.sato at oracle.com <naoto.sato at oracle.com>
> Sent: Donnerstag, 27. Juni 2019 23:16
> To: Langer, Christoph <christoph.langer at sap.com>; i18n-
> dev at openjdk.java.net; core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: <i18n dev> [13] RFR: 8226876: Assertion in
> sun/util/locale/provider/CalendarDataUtility on Windows after JDK-8218960
> 
> Thanks for the review, Christoph.
> 
> I'll wait for a whole day so that everyone sees the fix. Planning to
> push it tomorrow.
> 
> Naoto
> 
> On 6/27/19 2:05 PM, Langer, Christoph wrote:
> >>> The change looks good to me. But I would say the assertion in
> >> CalendarDataUtility in line 266 is pointless now, isn't it?
> >>
> >> Yes, but would not hurt leaving it. It would catch error if yet another
> >> case is installed (and it forgot to provide a default value) in the
> >> switch statement. So I just left it.
> >
> > Ok, sounds reasonable.
> >
> > What's your target for pushing this? I'd like to backport it to OpenJDK 11.0.4
> to fix the regression there...
> >
> > /Christoph
> >

From thejasvi.v.voniadka at oracle.com  Fri Jun 28 12:59:56 2019
From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka)
Date: Fri, 28 Jun 2019 05:59:56 -0700 (PDT)
Subject: <i18n dev> RFR: 8154520: java.time: appendLocalizedOffset() should
 return the localized "GMT" string
Message-ID: <8ec24050-0c2a-4f2d-88e6-a3fba5d40e12@default>

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 gnu.andrew at redhat.com  Fri Jun 28 20:30:10 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 28 Jun 2019 21:30:10 +0100
Subject: <i18n dev> RFR: [8u] Re-examine closed i18n tests to see it they
 can be moved to the jdk repository
Message-ID: <7e6f8bde-2bc5-0f09-021b-320357fabed3@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8031145 (not accessible)
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8031145/webrev.01/

This changeset adds a slew of tests for outputting internationalised
data. This is a pre-requisite for "8210153: localized currency symbol of
VES" which updates the CurrencyFormat.java test added by this set.

For such a large set, the number of failures is quite small:

FAILED: java/util/TimeZone/HongKong.java
FAILED: java/util/Calendar/CalendarRegression.java
FAILED: sun/text/IntHashtable/Bug4170614Test.sh
FAILED: java/text/BreakIterator/BreakIteratorTest.java
FAILED: java/text/Format/DateFormat/DateFormatTest.java
FAILED: java/text/Format/DateFormat/NonGregorianFormatTest.java
FAILED: java/text/Format/MessageFormat/LargeMessageFormat.java
FAILED: java/text/Format/NumberFormat/NumberRegression.java
FAILED: java/text/Format/NumberFormat/NumberTest.java

Most of these appear to be down to outdated locale data, as also
mentioned in my RFR for JDK-8218781 [0] (e.g. the HongKong failure is
due to the HK locale returning English values). JDK-7094818 also looks
like a potential backport candidate.

Other than minor context changes in TEST.groups (the only file modified
rather than added), a fix to test/java/text/testlib/HexDumpReader.java
was required as Java 8 does not have Integer.parseInt(CharSequence s,
int begin, int end, int radix). This is easily replaced by supplying the
substring as the original argument:

-+                    bab.put((byte)Integer.parseInt(line, i, i + 2, 16));
++                    bab.put((byte)Integer.parseInt(line.substring(i, i
+ 2), 16));

I also included changes from the 11u version of JDK-8151876, which
weren't part of the version in 8u because these tests were absent. This
includes the removal of test/java/util/TimeZone/CheckDisplayNames.java,
and adding 8151876 to the bug ID list of
test/java/util/TimeZone/TimeZoneTest.java.

Ok for 8u?

This was also need critical approval here, as I can't tag the bug itself.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009667.html
-- 
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  Fri Jun 28 21:46:08 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 28 Jun 2019 22:46:08 +0100
Subject: <i18n dev> [8u] Re-examine closed i18n tests to see it they can
 be moved to the jdk repository
In-Reply-To: <120038D4-D605-405D-9328-6F31E77331AD@amazon.com>
References: <7e6f8bde-2bc5-0f09-021b-320357fabed3@redhat.com>
 <120038D4-D605-405D-9328-6F31E77331AD@amazon.com>
Message-ID: <efdef4d6-2e44-7a42-5af3-01f3dc8acd5a@redhat.com>



On 28/06/2019 22:20, Hohensee, Paul wrote:
> I'm ok with it: more tests are a good thing.
> 
> Thanks,
> 
> Paul

Thanks, Paul. Pushed:

https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/66a0979b0557

-- 
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