From kravikumar at openjdk.java.net  Tue Feb  2 17:28:50 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 2 Feb 2021 17:28:50 GMT
Subject: <i18n dev> RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a
Message-ID: <nBNTh3B4mxEmonP7TqWR9YL9uJ5t4JoUObdqy7lfjgE=.cddf0c33-df60-4529-9938-cf72bea68737@github.com>

Hi Guys,

Please review integrating tzdata2021a to JDK.

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

The fix has passed the regression and JCK tests. More information can be viewed at - https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html

Thanks,
Kiran

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

Commit messages:
 - 8260356: (tz) Upgrade time-zone data to tzdata2021a

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

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

From naoto at openjdk.java.net  Tue Feb  2 18:01:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 2 Feb 2021 18:01:40 GMT
Subject: <i18n dev> RFR: 8260356: (tz) Upgrade time-zone data to
 tzdata2021a
In-Reply-To: <nBNTh3B4mxEmonP7TqWR9YL9uJ5t4JoUObdqy7lfjgE=.cddf0c33-df60-4529-9938-cf72bea68737@github.com>
References: <nBNTh3B4mxEmonP7TqWR9YL9uJ5t4JoUObdqy7lfjgE=.cddf0c33-df60-4529-9938-cf72bea68737@github.com>
Message-ID: <-0c4hj6JmNjRxa9spH1rQIsWtz6VFgngx3bgInZEljg=.35ff4b24-b0e8-4421-9667-f172cc860e66@github.com>

On Tue, 2 Feb 2021 17:22:18 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review integrating tzdata2021a to JDK.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8260356
> 
> The fix has passed the regression and JCK tests. More information can be viewed at - https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html
> 
> Thanks,
> Kiran

Marked as reviewed by naoto (Reviewer).

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

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

From igraves at openjdk.java.net  Wed Feb  3 22:47:09 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 3 Feb 2021 22:47:09 GMT
Subject: <i18n dev> RFR: 8261004: java.util.Formatter throws wrong exception
 for mismatched flags in %% conversion
Message-ID: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com>

Updating the specification to reflect well-established behavior in Formatter when incorrect flags used for `%`.

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

Commit messages:
 - Changing docs to reflect behavior

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

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

From kravikumar at openjdk.java.net  Thu Feb  4 17:51:40 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Thu, 4 Feb 2021 17:51:40 GMT
Subject: <i18n dev> Integrated: 8260356: (tz) Upgrade time-zone data to
 tzdata2021a
In-Reply-To: <nBNTh3B4mxEmonP7TqWR9YL9uJ5t4JoUObdqy7lfjgE=.cddf0c33-df60-4529-9938-cf72bea68737@github.com>
References: <nBNTh3B4mxEmonP7TqWR9YL9uJ5t4JoUObdqy7lfjgE=.cddf0c33-df60-4529-9938-cf72bea68737@github.com>
Message-ID: <0_Tpw4xuL-jbkLel66ymgrUl-P3Uu_Pl8kjJ7MJmEOo=.c5d43be2-756d-4029-8d9a-5b1f4421df56@github.com>

On Tue, 2 Feb 2021 17:22:18 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review integrating tzdata2021a to JDK.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8260356
> 
> The fix has passed the regression and JCK tests. More information can be viewed at - https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: d9aefa36
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d9aefa36
Stats:     12 lines in 3 files changed: 6 ins; 0 del; 6 mod

8260356: (tz) Upgrade time-zone data to tzdata2021a

Reviewed-by: naoto

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

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

From naoto at openjdk.java.net  Thu Feb  4 22:54:51 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 4 Feb 2021 22:54:51 GMT
Subject: <i18n dev> =?utf-8?q?RFR=3A_8261179=3A_Norwegian_Bokm=C3=A5l_Loc?=
 =?utf-8?q?ale_fallback_issue?=
Message-ID: <idXIgFPSLB8ViAcxM8e5U3TSkimWxkTN5AqDkkBDIQU=.8d46e439-3d02-49e1-95ed-233979028ab1@github.com>

Please review this fix. The bug was revealed while porting CLDR v39 into the JDK, where they switch the Norwegian Bokmal from "nb" to "no". [1] Some regression tests started failing with it because COMPAT provider's "nb" resource was used according to the incorrect candidate locale order.

[1] https://unicode-org.atlassian.net/browse/CLDR-2698

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

Commit messages:
 - 8261179: Norwegian Bokm?l Locale fallback issue

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

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

From joehw at openjdk.java.net  Fri Feb  5 01:24:40 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 5 Feb 2021 01:24:40 GMT
Subject: <i18n dev> 
 =?utf-8?q?RFR=3A_8261179=3A_Norwegian_Bokm=C3=A5l_Loc?=
 =?utf-8?q?ale_fallback_issue?=
In-Reply-To: <idXIgFPSLB8ViAcxM8e5U3TSkimWxkTN5AqDkkBDIQU=.8d46e439-3d02-49e1-95ed-233979028ab1@github.com>
References: <idXIgFPSLB8ViAcxM8e5U3TSkimWxkTN5AqDkkBDIQU=.8d46e439-3d02-49e1-95ed-233979028ab1@github.com>
Message-ID: <1YfjO2GD2mVWgOf9c_Atmtu0qHmp8Ynp-qQw3Gi5J_g=.ea3f1b78-a552-40a6-bb1a-94a36117ebd1@github.com>

On Thu, 4 Feb 2021 22:17:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this fix. The bug was revealed while porting CLDR v39 into the JDK, where they switch the Norwegian Bokmal from "nb" to "no". [1] Some regression tests started failing with it because COMPAT provider's "nb" resource was used according to the incorrect candidate locale order.
> 
> [1] https://unicode-org.atlassian.net/browse/CLDR-2698

Marked as reviewed by joehw (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Feb  5 18:19:39 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 5 Feb 2021 18:19:39 GMT
Subject: <i18n dev> =?utf-8?q?Integrated=3A_8261179=3A_Norwegian_Bokm?=
 =?utf-8?q?=C3=A5l_Locale_fallback_issue?=
In-Reply-To: <idXIgFPSLB8ViAcxM8e5U3TSkimWxkTN5AqDkkBDIQU=.8d46e439-3d02-49e1-95ed-233979028ab1@github.com>
References: <idXIgFPSLB8ViAcxM8e5U3TSkimWxkTN5AqDkkBDIQU=.8d46e439-3d02-49e1-95ed-233979028ab1@github.com>
Message-ID: <n0wKtaEIwQozxCfOBGBjJWHpmGVYdwJJB3ady2cw56Y=.7b7b5255-fd8c-4084-8673-af216a5aabc4@github.com>

On Thu, 4 Feb 2021 22:17:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this fix. The bug was revealed while porting CLDR v39 into the JDK, where they switch the Norwegian Bokmal from "nb" to "no". [1] Some regression tests started failing with it because COMPAT provider's "nb" resource was used according to the incorrect candidate locale order.
> 
> [1] https://unicode-org.atlassian.net/browse/CLDR-2698

This pull request has now been integrated.

Changeset: 4a1814cb
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4a1814cb
Stats:     43 lines in 2 files changed: 22 ins; 1 del; 20 mod

8261179: Norwegian Bokm?l Locale fallback issue

Reviewed-by: joehw

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

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

From redestad at openjdk.java.net  Sun Feb  7 19:36:53 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 7 Feb 2021 19:36:53 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
Message-ID: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>

This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.

Testing: tier1-3

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

Commit messages:
 - Merge branch 'master' into lazy_charsets
 - More finals, copyrights
 - Improve finality
 - Initialize charset mapping data lazily

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

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

From redestad at openjdk.java.net  Sun Feb  7 19:36:53 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 7 Feb 2021 19:36:53 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
Message-ID: <eLSK8l4nKR2IXzaxDpiFYQwfFk_JTNtLpO344heaV6E=.3c782cc6-e196-4256-a664-313dc010b872@github.com>

On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
> 
> Testing: tier1-3

Applications calling `Charset.availableCharsets()` might see a decent startup improvement (125-190ms -> 57-95ms first call overhead).

All `DoubleByte`-derived charsets can see a throughput improvement on benchmarks thanks to removing DCL initialization checks with a Holder pattern implementation, which allows static data to be declared final and be more amenable to optimizations:

Before:
Benchmark                                   (charsetName)  Mode  Cnt    Score    Error  Units
StringDecode.WithCharset.decodeCharset              MS932  avgt   15  280.072 ? 17.217  ns/op
StringDecode.WithCharset.decodeCharsetName          MS932  avgt   15  289.368 ? 18.174  ns/op

After:
Benchmark                                   (charsetName)  Mode  Cnt    Score    Error  Units
StringDecode.WithCharset.decodeCharset              MS932  avgt   15  254.906 ? 15.095  ns/op
StringDecode.WithCharset.decodeCharsetName          MS932  avgt   15  268.241 ? 15.725  ns/op

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

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

From alanb at openjdk.java.net  Mon Feb  8 08:38:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 8 Feb 2021 08:38:40 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
Message-ID: <jyYKmYsVLUj6Z1R5xhhgAQbTPWGs7hnlJ_ZAxQWnlWw=.75e74aed-21cb-4f72-9b3f-2cf7422caf9d@github.com>

On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
> 
> Testing: tier1-3

I wouldn't expect enumerating all charsets with Charset::availableCharsets to be too common but moving the data to holder class looks okay. The missing "final" in a few places was an oversight.  The replacement of the foreach and method ref in getServicesCatalog with imperative code is disappointment but okay here.

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

Marked as reviewed by alanb (Reviewer).

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

From redestad at openjdk.java.net  Mon Feb  8 11:33:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Feb 2021 11:33:46 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <jyYKmYsVLUj6Z1R5xhhgAQbTPWGs7hnlJ_ZAxQWnlWw=.75e74aed-21cb-4f72-9b3f-2cf7422caf9d@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
 <jyYKmYsVLUj6Z1R5xhhgAQbTPWGs7hnlJ_ZAxQWnlWw=.75e74aed-21cb-4f72-9b3f-2cf7422caf9d@github.com>
Message-ID: <AFCSpkAuBxdZNiMnsINqNyaVLuAsYvG0OcCmIHEywB8=.4147b59d-721b-443b-bd7a-4d4d26009dd6@github.com>

On Mon, 8 Feb 2021 08:36:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
>> 
>> Testing: tier1-3
>
> I wouldn't expect enumerating all charsets with Charset::availableCharsets to be too common but moving the data to holder class looks okay. The missing "final" in a few places was an oversight.  The replacement of the foreach and method ref in getServicesCatalog with imperative code is disappointment but okay here.

I spotted usage of this in a real application. While they could work around it and remove the usage to gain an even larger startup win I figured I should do those that can't do so a favor, too.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Feb  8 11:44:47 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 8 Feb 2021 11:44:47 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
Message-ID: <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com>

On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
> 
> Testing: tier1-3

src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java line 75:

> 73: 
> 74:     protected AbstractCharsetProvider(String pkgPrefixName) {
> 75:         packagePrefix = pkgPrefixName.concat(".");

Hm, I wonder why not just `pkgPrefixName + '.'` here and below?

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

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

From jkuhn at openjdk.java.net  Mon Feb  8 12:18:43 2021
From: jkuhn at openjdk.java.net (Johannes Kuhn)
Date: Mon, 8 Feb 2021 12:18:43 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
Message-ID: <T9kZkYn1cNdkve9D8bTAAk90qHGim6wTkwi99pY_9wc=.2b9007ac-0f61-4c40-b4ca-97089cfc6e43@github.com>

On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
> 
> Testing: tier1-3

Looks good to me.

src/java.base/share/classes/java/lang/ModuleLayer.java line 936:

> 934:                 for (Module m : nameToModule.values()) {
> 935:                     servicesCatalog.register(m);
> 936:                 }

Seems to be unrelated, but it's not a bad change.

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

Marked as reviewed by jkuhn (Author).

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

From redestad at openjdk.java.net  Mon Feb  8 12:18:45 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Feb 2021 12:18:45 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
 <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com>
Message-ID: <899QAkFNi0wQHE33c5OBIBX00zriHM2Am4sEh25lmL4=.b2c3093e-1bfc-4c1e-b7b1-50570f55f8a0@github.com>

On Mon, 8 Feb 2021 11:42:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
>> 
>> Testing: tier1-3
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java line 75:
> 
>> 73: 
>> 74:     protected AbstractCharsetProvider(String pkgPrefixName) {
>> 75:         packagePrefix = pkgPrefixName.concat(".");
> 
> Hm, I wonder why not just `pkgPrefixName + '.'` here and below? Is it something about early init of `StringConcatFactory`?

Yes, I wanted to measure the overhead of `Charset` class initialization done by `Charset.availableCharsets()` and the `StringConcatFactory` bootstraps was a reasonable chunk of the cost so I moved them out of the picture. I didn't mind what I ended up with, but if you prefer I can move back to `pkgPrefixName + '.'` here.

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

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

From redestad at openjdk.java.net  Mon Feb  8 12:21:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Feb 2021 12:21:42 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <T9kZkYn1cNdkve9D8bTAAk90qHGim6wTkwi99pY_9wc=.2b9007ac-0f61-4c40-b4ca-97089cfc6e43@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
 <T9kZkYn1cNdkve9D8bTAAk90qHGim6wTkwi99pY_9wc=.2b9007ac-0f61-4c40-b4ca-97089cfc6e43@github.com>
Message-ID: <DmVwtndgTo48XwIXYZ9BksoCZIJzT7MghqPevTxZ5R4=.1b3c5528-66b5-41ce-9ce0-07f207e030cf@github.com>

On Sun, 7 Feb 2021 19:44:41 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
>> 
>> Testing: tier1-3
>
> src/java.base/share/classes/java/lang/ModuleLayer.java line 936:
> 
>> 934:                 for (Module m : nameToModule.values()) {
>> 935:                     servicesCatalog.register(m);
>> 936:                 }
> 
> Seems to be unrelated, but it's not a bad change.

As with the `StringConcatFactory` changes @stsypanov commented on, I did this to reduce noise when zooming in on the cost of `Charset` class initialization stemming from `Charset.availableCharsets()`. I ended up preferring the desugared version, so I left it in.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Feb  8 12:50:41 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 8 Feb 2021 12:50:41 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <899QAkFNi0wQHE33c5OBIBX00zriHM2Am4sEh25lmL4=.b2c3093e-1bfc-4c1e-b7b1-50570f55f8a0@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
 <61sBATGdV_lFLxmvERtgoipT0393haZFWyPN7eHgcyA=.bdde5a8f-8006-4f13-ade0-93e7e6466200@github.com>
 <899QAkFNi0wQHE33c5OBIBX00zriHM2Am4sEh25lmL4=.b2c3093e-1bfc-4c1e-b7b1-50570f55f8a0@github.com>
Message-ID: <tIBNj20tZa3Egv-2e6JlQQs_f-ysUQpi_8i3y2tn36A=.f22ec4c4-32a2-42b3-8fe5-c05306fb70d3@github.com>

On Mon, 8 Feb 2021 12:16:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java line 75:
>> 
>>> 73: 
>>> 74:     protected AbstractCharsetProvider(String pkgPrefixName) {
>>> 75:         packagePrefix = pkgPrefixName.concat(".");
>> 
>> Hm, I wonder why not just `pkgPrefixName + '.'` here and below? Is it something about early init of `StringConcatFactory`?
>
> Yes, I wanted to measure the overhead of `Charset` class initialization done by `Charset.availableCharsets()` and the `StringConcatFactory` bootstraps was a reasonable chunk of the cost so I moved them out of the picture. I didn't mind what I ended up with, but if you prefer I can move back to `pkgPrefixName + '.'` here.

Let's keep it as is, to me it's a readable as concatenation via `+`

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

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

From naoto at openjdk.java.net  Mon Feb  8 17:42:42 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Feb 2021 17:42:42 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
Message-ID: <-kXym4OZ3sjVrTA4PhCR19GZq4s0mdSO9_YZAo_Fu50=.8d3ef6dd-9d03-47cc-83a0-ab67fb0f0c89@github.com>

On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
> 
> Testing: tier1-3

Looks good to me. I initially thought of the same impression as Alan's, i.e., enumerating all charsets is not that common (in fact, same applies to Locale, and I once explored usages and it ended all up in test cases), but if real apps are using it, this is the right way to do so.

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

Marked as reviewed by naoto (Reviewer).

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

From redestad at openjdk.java.net  Mon Feb  8 18:48:45 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Feb 2021 18:48:45 GMT
Subject: <i18n dev> Integrated: 8261254: Initialize charset mapping data
 lazily
In-Reply-To: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
Message-ID: <ebGLTssVOBbJNy8nRZIjsmn9VDKMgfUdBgutztjvI2M=.2fd63881-2a6f-4157-8b76-31245b1bf38b@github.com>

On Sun, 7 Feb 2021 19:08:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: 92c6e6df
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92c6e6df
Stats:     274 lines in 21 files changed: 24 ins; 59 del; 191 mod

8261254: Initialize charset mapping data lazily

Reviewed-by: alanb, jkuhn, naoto

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

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

From redestad at openjdk.java.net  Mon Feb  8 18:48:43 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Feb 2021 18:48:43 GMT
Subject: <i18n dev> RFR: 8261254: Initialize charset mapping data lazily
In-Reply-To: <-kXym4OZ3sjVrTA4PhCR19GZq4s0mdSO9_YZAo_Fu50=.8d3ef6dd-9d03-47cc-83a0-ab67fb0f0c89@github.com>
References: <Z8Q8Rc6h_p9MhogYt1MiIE6gq3VuZY808Z8y8sUegTY=.542e2753-daa9-42f5-8a7e-3de0b798a653@github.com>
 <-kXym4OZ3sjVrTA4PhCR19GZq4s0mdSO9_YZAo_Fu50=.8d3ef6dd-9d03-47cc-83a0-ab67fb0f0c89@github.com>
Message-ID: <Mla1rGcU_qvl7PPqzqipXiVjcrHEeTYKbntbKrBL10o=.b1539818-7e3c-4167-a3ef-d178de6875c8@github.com>

On Mon, 8 Feb 2021 17:40:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This patch refactor JDK internal charsets to initialize charset mapping data lazily when needed via holder classes. This means both a startup improvement in some cases, and possible throughput improvements for all DoubleByte-based Charsets.
>> 
>> Testing: tier1-3
>
> Looks good to me. I initially thought of the same impression as Alan's, i.e., enumerating all charsets is not that common (in fact, same applies to Locale, and I once explored usages and it ended all up in test cases), but if real apps are using it, this is the right way to do so.

Thanks for reviewing!

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

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

From naoto at openjdk.java.net  Mon Feb  8 21:47:53 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Feb 2021 21:47:53 GMT
Subject: <i18n dev> RFR: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
Message-ID: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>

Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out.

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

Commit messages:
 - 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out

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

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

From lancea at openjdk.java.net  Mon Feb  8 21:55:42 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 8 Feb 2021 21:55:42 GMT
Subject: <i18n dev> RFR: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
In-Reply-To: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
References: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
Message-ID: <TZ3QJsexPtvlHfxDOf5TSfCUdr8iJM3PNWQTYt4Rb8g=.929083ba-ffa4-496c-8fc3-192f4f071581@github.com>

On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out.

Marked as reviewed by lancea (Reviewer).

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

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

From bpb at openjdk.java.net  Mon Feb  8 21:55:42 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Feb 2021 21:55:42 GMT
Subject: <i18n dev> RFR: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
In-Reply-To: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
References: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
Message-ID: <6Ks856fd96fiprHkzJ-4CzDpdfhSBMvTw0D8TngJ7SY=.b5678a91-b11a-4ee5-94ac-c7797aac2479@github.com>

On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out.

Marked as reviewed by bpb (Reviewer).

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

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

From joehw at openjdk.java.net  Mon Feb  8 23:44:41 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 8 Feb 2021 23:44:41 GMT
Subject: <i18n dev> RFR: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
In-Reply-To: <TZ3QJsexPtvlHfxDOf5TSfCUdr8iJM3PNWQTYt4Rb8g=.929083ba-ffa4-496c-8fc3-192f4f071581@github.com>
References: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
 <TZ3QJsexPtvlHfxDOf5TSfCUdr8iJM3PNWQTYt4Rb8g=.929083ba-ffa4-496c-8fc3-192f4f071581@github.com>
Message-ID: <GnZvXyXFgAOayDIF_4apZGpA-8jJSedGvr5Hvb_ydok=.960cfacc-6e81-4c70-aec8-6d423aca16f5@github.com>

On Mon, 8 Feb 2021 21:52:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out.
>
> Marked as reviewed by lancea (Reviewer).

The fix looks ok to me. Just an interesting note that this test took such a long time to run. Given the amount of locales, limit(30) would reduce the time to approximately 1/5 of the time, that would still be about 100,000ms according to the bug report. That feels pretty long for a single test case that, outside of the test environment, takes only 1s (my local test took 5s without limit(30)). 

Also, there are a bunch of other tests that also run through all of the available locales, I wonder if they also take a long time to run.

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

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

From naoto at openjdk.java.net  Tue Feb  9 00:07:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 9 Feb 2021 00:07:41 GMT
Subject: <i18n dev> RFR: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
In-Reply-To: <GnZvXyXFgAOayDIF_4apZGpA-8jJSedGvr5Hvb_ydok=.960cfacc-6e81-4c70-aec8-6d423aca16f5@github.com>
References: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
 <TZ3QJsexPtvlHfxDOf5TSfCUdr8iJM3PNWQTYt4Rb8g=.929083ba-ffa4-496c-8fc3-192f4f071581@github.com>
 <GnZvXyXFgAOayDIF_4apZGpA-8jJSedGvr5Hvb_ydok=.960cfacc-6e81-4c70-aec8-6d423aca16f5@github.com>
Message-ID: <JuuFTV1HNik0r-El_w4iwW1687AZzsgny7amwn84rIc=.cc2ffc08-6ec7-47d0-8c82-125d6a5b17e4@github.com>

On Mon, 8 Feb 2021 23:42:04 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Marked as reviewed by lancea (Reviewer).
>
> The fix looks ok to me. Just an interesting note that this test took such a long time to run. Given the amount of locales, limit(30) would reduce the time to approximately 1/5 of the time, that would still be about 100,000ms according to the bug report. That feels pretty long for a single test case that, outside of the test environment, takes only 1s (my local test took 5s without limit(30)). 
> 
> Also, there are a bunch of other tests that also run through all of the available locales, I wonder if they also take a long time to run.

As of JDK15, there are more than 800 locales, so reducing the samples down to 30 makes it less than 4% of the original (~20,000ms on that machine). But I agree that the test took too long than my environment too. Could be a very slow machine.
As to other tests calling available locales,  the reason this test took a long time is that the loop multiplies with the number of time zones which is also huge (600+), so it would be less likely that other locale tests cause timeouts.

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

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

From joehw at openjdk.java.net  Tue Feb  9 01:40:43 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 9 Feb 2021 01:40:43 GMT
Subject: <i18n dev> RFR: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
In-Reply-To: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
References: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
Message-ID: <zqIabNVu_CgIhCvEfn-LyFNh8y20kDm4mt2JZHdpXic=.59f9c603-41da-4dbc-aa83-4f44318e881a@github.com>

On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out.

Marked as reviewed by joehw (Reviewer).

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

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

From joehw at openjdk.java.net  Tue Feb  9 01:40:43 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 9 Feb 2021 01:40:43 GMT
Subject: <i18n dev> RFR: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
In-Reply-To: <JuuFTV1HNik0r-El_w4iwW1687AZzsgny7amwn84rIc=.cc2ffc08-6ec7-47d0-8c82-125d6a5b17e4@github.com>
References: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
 <TZ3QJsexPtvlHfxDOf5TSfCUdr8iJM3PNWQTYt4Rb8g=.929083ba-ffa4-496c-8fc3-192f4f071581@github.com>
 <GnZvXyXFgAOayDIF_4apZGpA-8jJSedGvr5Hvb_ydok=.960cfacc-6e81-4c70-aec8-6d423aca16f5@github.com>
 <JuuFTV1HNik0r-El_w4iwW1687AZzsgny7amwn84rIc=.cc2ffc08-6ec7-47d0-8c82-125d6a5b17e4@github.com>
Message-ID: <gsOj3PS9hA2l5E-TkbMv2-3Bzf-j3uorvfyZfCI8ZkA=.5633228a-1d1f-4005-8975-f1fb5a4dd5ec@github.com>

On Tue, 9 Feb 2021 00:04:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix looks ok to me. Just an interesting note that this test took such a long time to run. Given the amount of locales, limit(30) would reduce the time to approximately 1/5 of the time, that would still be about 100,000ms according to the bug report. That feels pretty long for a single test case that, outside of the test environment, takes only 1s (my local test took 5s without limit(30)). 
>> 
>> Also, there are a bunch of other tests that also run through all of the available locales, I wonder if they also take a long time to run.
>
> As of JDK15, there are more than 800 locales, so reducing the samples down to 30 makes it less than 4% of the original (~20,000ms on that machine). But I agree that the test took too long than my environment too. Could be a very slow machine.
> As to other tests calling available locales,  the reason this test took a long time is that the loop multiplies with the number of time zones which is also huge (600+), so it would be less likely that other locale tests cause timeouts.

I see. I didn't know locales had gone from 160 to 800! All the more reason to set a limit. Rerun with jdk 16, limit(30) does make it a breeze comparing to that without (which made my machine start to spin). 20,000ms is reasonable on a slower machine with a debug build.

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

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

From redestad at openjdk.java.net  Tue Feb  9 13:27:12 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 9 Feb 2021 13:27:12 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets
In-Reply-To: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
Message-ID: <MtrDUSfh8Pce7itjyzOf8mVJE9RSUgZM9H1eR-hJN08=.6144b4d9-8a49-4648-bed1-6d3fb6a4087a@github.com>

On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
> 
> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
> 
> Testing: tier1-3, manual runs of sun.nio.cs tests

`StringDecode.WithCharset.decodeCharsetName` microbenchmark runs

pre-JDK-8259842:
Benchmark                                           (charsetName)     Mode  Cnt     Score     Error   Units
decodeCharsetName                                   x-ISO-2022-CN-GB  avgt    5   756.293 ?  56.082   ns/op
decodeCharsetName:?gc.alloc.rate.norm               x-ISO-2022-CN-GB  avgt    5   488.040 ?   0.013    B/op
decodeCharsetName                                   ISO-2022-KR       avgt    5  1076.745 ? 299.789   ns/op
decodeCharsetName:?gc.alloc.rate.norm               ISO-2022-KR       avgt    5   808.068 ?   0.022    B/op
Current:
Benchmark                                           (charsetName)     Mode  Cnt     Score     Error   Units
decodeCharsetName                                   x-ISO-2022-CN-GB  avgt    5   906.281 ? 109.035   ns/op
decodeCharsetName:?gc.alloc.rate.norm               x-ISO-2022-CN-GB  avgt    5   920.077 ?   0.025    B/op
decodeCharsetName                                   ISO-2022-KR       avgt    5  1175.228 ? 144.509   ns/op
decodeCharsetName:?gc.alloc.rate.norm               ISO-2022-KR       avgt    5  1256.105 ?   0.043    B/op
Patched:
Benchmark                                           (charsetName)     Mode  Cnt    Score     Error   Units
decodeCharsetName                                   x-ISO-2022-CN-GB  avgt    5  783.385 ? 255.048   ns/op
decodeCharsetName:?gc.alloc.rate.norm               x-ISO-2022-CN-GB  avgt    5  584.050 ?   0.016    B/op
decodeCharsetName                                   ISO-2022-KR       avgt    5  814.654 ? 196.860   ns/op
decodeCharsetName:?gc.alloc.rate.norm               ISO-2022-KR       avgt    5  584.050 ?   0.024    B/op

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

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

From redestad at openjdk.java.net  Tue Feb  9 13:27:05 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 9 Feb 2021 13:27:05 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets
Message-ID: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>

This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)

Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.

Testing: tier1-3, manual runs of sun.nio.cs tests

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

Commit messages:
 - Minor cleanup
 - Reduce decoder creation overheads for sun.nio.cs.ext Charsets

Changes: https://git.openjdk.java.net/jdk/pull/2480/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2480&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261418
  Stats: 761 lines in 15 files changed: 258 ins; 411 del; 92 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2480/head:pull/2480

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

From naoto at openjdk.java.net  Tue Feb  9 17:12:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 9 Feb 2021 17:12:40 GMT
Subject: <i18n dev> Integrated: 8261279:
 sun/util/resources/cldr/TimeZoneNamesTest.java timed out
In-Reply-To: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
References: <nQLQDlI1lByKD-GNeVEBTNUrow0MgNeEwS0m_lfLVBI=.d89cefd6-9918-43ec-a821-c634fc345a7d@github.com>
Message-ID: <31EQg4pClcfWArGzgA-plSQB8un0d5J9lDTurXK2cPs=.e6a3461b-8773-43ac-8456-014e96b8a5d4@github.com>

On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple test case fix. By sampling locales to test, it reduces the possibility of the time out.

This pull request has now been integrated.

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

8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out

Reviewed-by: bpb, lancea, joehw

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

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

From naoto at openjdk.java.net  Tue Feb  9 19:24:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 9 Feb 2021 19:24:40 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets
In-Reply-To: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
Message-ID: <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>

On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
> 
> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
> 
> Testing: tier1-3, manual runs of sun.nio.cs tests

Thanks, Claes, for making the performance improvement. I have a few comments/questions.

src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 116:

> 114:             int sp = src.arrayOffset() + src.position();
> 115:             int sl = src.arrayOffset() + src.limit();
> 116: 

I see these are removed from encode/decodeArrayLoop(s). Any reason behind those?

src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64:

> 62: 
> 63:         protected final byte maximumDesignatorLength = 4;
> 64: 

This implementation moved to KR concrete implementation class. IIUC, this is the default impl for generic ISO2022 spec, so I believe the code being here is more reasonable. Any performance gain by moving this to KR specific class?

src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022_CN.java line 88:

> 86:         private byte currentSODesig;
> 87: 
> 88:         private static final DoubleByte.Decoder gb2312Decoder =

Since this is a shared constant, I'd use all caps field name.

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

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

From redestad at openjdk.java.net  Tue Feb  9 19:45:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 9 Feb 2021 19:45:42 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets
In-Reply-To: <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
 <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
Message-ID: <Da3HmpYx86zDhDPc0T6_9e5C_lnZxqNrC8v3X477uvk=.41bde955-d471-4a7c-81ff-bfcc60938029@github.com>

On Tue, 9 Feb 2021 19:14:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
>> 
>> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
>> 
>> Testing: tier1-3, manual runs of sun.nio.cs tests
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 116:
> 
>> 114:             int sp = src.arrayOffset() + src.position();
>> 115:             int sl = src.arrayOffset() + src.limit();
>> 116: 
> 
> I see these are removed from encode/decodeArrayLoop(s). Any reason behind those?

My IDE was marking the next line as redundant since `sp <= sl` will always be true. `buffer.position() <= buffer.limit()` is an invariant that I don't think we need to assert against here, and I think it's just been copy-pasted around mindlessly.

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

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

From naoto at openjdk.java.net  Tue Feb  9 19:52:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 9 Feb 2021 19:52:40 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets
In-Reply-To: <Da3HmpYx86zDhDPc0T6_9e5C_lnZxqNrC8v3X477uvk=.41bde955-d471-4a7c-81ff-bfcc60938029@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
 <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
 <Da3HmpYx86zDhDPc0T6_9e5C_lnZxqNrC8v3X477uvk=.41bde955-d471-4a7c-81ff-bfcc60938029@github.com>
Message-ID: <oTaKSDpMK5sxawwmy_nAUh_k5oKGiKaN2XMzqt55Vcg=.d1b45042-6923-40ca-ad67-20ab6d8c164d@github.com>

On Tue, 9 Feb 2021 19:43:06 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 116:
>> 
>>> 114:             int sp = src.arrayOffset() + src.position();
>>> 115:             int sl = src.arrayOffset() + src.limit();
>>> 116: 
>> 
>> I see these are removed from encode/decodeArrayLoop(s). Any reason behind those?
>
> My IDE was marking the next line as redundant since `sp <= sl` will always be true. `buffer.position() <= buffer.limit()` is an invariant that I don't think we need to assert against here, and I think it's just been copy-pasted around mindlessly.

Thanks, got it. I was wondering any possibility of sp > sl case.

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

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

From redestad at openjdk.java.net  Tue Feb  9 21:05:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 9 Feb 2021 21:05:41 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets
In-Reply-To: <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
 <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
Message-ID: <YU662rIEifnDiW8aqjZcEchMR7qC7SI_rdpErml1nLQ=.02ead05e-cab6-45b0-987a-dc6c2ffa6af7@github.com>

On Tue, 9 Feb 2021 19:19:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
>> 
>> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
>> 
>> Testing: tier1-3, manual runs of sun.nio.cs tests
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022_CN.java line 88:
> 
>> 86:         private byte currentSODesig;
>> 87: 
>> 88:         private static final DoubleByte.Decoder gb2312Decoder =
> 
> Since this is a shared constant, I'd use all caps field name.

Will fix.

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

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

From redestad at openjdk.java.net  Tue Feb  9 21:14:56 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 9 Feb 2021 21:14:56 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets [v2]
In-Reply-To: <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
 <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
Message-ID: <di-Dl_AVWF6seMmZLvw1ils18G9QmvoA1Ovsw5rOERI=.d2e7a8e3-9ddd-4c9b-846a-1e9292df4559@github.com>

On Tue, 9 Feb 2021 19:18:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64:
> 
>> 62: 
>> 63:         protected final byte maximumDesignatorLength = 4;
>> 64: 
> 
> This implementation moved to KR concrete implementation class. IIUC, this is the default impl for generic ISO2022 spec, so I believe the code being here is more reasonable. Any performance gain by moving this to KR specific class?

The KR concrete impl is the only instantiation of this default impl - all other were already implementing specialized `Decoders` that does not inherit from `ISO2022.Decoder`, which is actually rather inefficient. The concrete KR class uses a `DoubleByte.Decoder` that can now be created statically and used directly in the `decode` method - bypassing the `tmpDecoder` indirection and using tiny array+buffers which added quite a bit of overhead. So the performance gain here was significant, and is the explanation `ISO2022_KR` is now significantly ahead of the baseline on the `StringDecode` micro.

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

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

From redestad at openjdk.java.net  Tue Feb  9 21:14:55 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 9 Feb 2021 21:14:55 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets [v2]
In-Reply-To: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
Message-ID: <O4EYAe-54DHy7SvgEvXfnsrI66k8gj07hOhs_SfowfY=.fa6e4b67-ba78-4563-b767-5c9920815202@github.com>

> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
> 
> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
> 
> Testing: tier1-3, manual runs of sun.nio.cs tests

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

  Review fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2480/files
  - new: https://git.openjdk.java.net/jdk/pull/2480/files/9ed39a90..aa24f031

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

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

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

From naoto at openjdk.java.net  Tue Feb  9 21:38:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 9 Feb 2021 21:38:41 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets [v2]
In-Reply-To: <di-Dl_AVWF6seMmZLvw1ils18G9QmvoA1Ovsw5rOERI=.d2e7a8e3-9ddd-4c9b-846a-1e9292df4559@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
 <baAQuHX1DfDHYelQGYcbXxMiVIYuS6WW91AciqDaLGk=.e65cafd9-8402-46dd-815d-c5ab392c9429@github.com>
 <di-Dl_AVWF6seMmZLvw1ils18G9QmvoA1Ovsw5rOERI=.d2e7a8e3-9ddd-4c9b-846a-1e9292df4559@github.com>
Message-ID: <2GUT8vaOuE8qT3FnKWh36blfv_Vdgr3eiUt770NNRbU=.1cc4df4d-5729-4702-bd99-7f542633d473@github.com>

On Tue, 9 Feb 2021 21:10:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64:
>> 
>>> 62: 
>>> 63:         protected final byte maximumDesignatorLength = 4;
>>> 64: 
>> 
>> This implementation moved to KR concrete implementation class. IIUC, this is the default impl for generic ISO2022 spec, so I believe the code being here is more reasonable. Any performance gain by moving this to KR specific class?
>
> The KR concrete impl is the only instantiation of this default impl - all other were already implementing specialized `Decoders` that does not inherit from `ISO2022.Decoder`, which is actually rather inefficient. The concrete KR class uses a `DoubleByte.Decoder` that can now be created statically and used directly in the `decode` method - bypassing the `tmpDecoder` indirection and using tiny array+buffers which added quite a bit of overhead. So the performance gain here was significant, and is the explanation `ISO2022_KR` is now significantly ahead of the baseline on the `StringDecode` micro.

OK. I don't think any more new ISO2022 charset would be added, so personally I still prefer the default impl in the ISO2022 itself, but I am ok with the code, as it improves the performance. Would you please add a comment explaining it?

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

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

From redestad at openjdk.java.net  Wed Feb 10 23:35:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 10 Feb 2021 23:35:54 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets [v3]
In-Reply-To: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
Message-ID: <zkJY-79AChfoEXQTSFFyy7ANrc9k-FX1FryNTvTDGTA=.6ceeaa62-812f-4717-b0b9-2c43eaa3bfc2@github.com>

> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
> 
> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
> 
> Testing: tier1-3, manual runs of sun.nio.cs tests

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

  Add comment about removing the generic ISO2022.Decoder

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2480/files
  - new: https://git.openjdk.java.net/jdk/pull/2480/files/aa24f031..fa593915

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

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

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

From naoto at openjdk.java.net  Wed Feb 10 23:41:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Feb 2021 23:41:41 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets [v3]
In-Reply-To: <zkJY-79AChfoEXQTSFFyy7ANrc9k-FX1FryNTvTDGTA=.6ceeaa62-812f-4717-b0b9-2c43eaa3bfc2@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
 <zkJY-79AChfoEXQTSFFyy7ANrc9k-FX1FryNTvTDGTA=.6ceeaa62-812f-4717-b0b9-2c43eaa3bfc2@github.com>
Message-ID: <MzXW8lydZzNUwvgj0Ff3LuRl8e8o8vrcBINU6HK0MrY=.187c43f5-fc54-4f3a-b7cf-4f6107bc0156@github.com>

On Wed, 10 Feb 2021 23:35:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
>> 
>> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
>> 
>> Testing: tier1-3, manual runs of sun.nio.cs tests
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about removing the generic ISO2022.Decoder

Thanks. The newly added comment to ISO2022 is helpful.

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

Marked as reviewed by naoto (Reviewer).

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

From redestad at openjdk.java.net  Thu Feb 11 10:46:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Feb 2021 10:46:41 GMT
Subject: <i18n dev> RFR: 8261418: Reduce decoder creation overheads for
 sun.nio.cs.ext Charsets [v3]
In-Reply-To: <MzXW8lydZzNUwvgj0Ff3LuRl8e8o8vrcBINU6HK0MrY=.187c43f5-fc54-4f3a-b7cf-4f6107bc0156@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
 <zkJY-79AChfoEXQTSFFyy7ANrc9k-FX1FryNTvTDGTA=.6ceeaa62-812f-4717-b0b9-2c43eaa3bfc2@github.com>
 <MzXW8lydZzNUwvgj0Ff3LuRl8e8o8vrcBINU6HK0MrY=.187c43f5-fc54-4f3a-b7cf-4f6107bc0156@github.com>
Message-ID: <42EyMaVpYDWoZJnJ9gMAiQ8jVo3Kr4OJ6uHVe6DPi68=.2ef23ae7-9dcd-4e18-abe5-a4458ac04691@github.com>

On Wed, 10 Feb 2021 23:38:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment about removing the generic ISO2022.Decoder
>
> Thanks. The newly added comment to ISO2022 is helpful.

Thanks Naoto!

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

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

From redestad at openjdk.java.net  Thu Feb 11 10:46:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Feb 2021 10:46:42 GMT
Subject: <i18n dev> Integrated: 8261418: Reduce decoder creation overheads
 for sun.nio.cs.ext Charsets
In-Reply-To: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
References: <Yu67-ZzVm5ZFNRvVn5Dg9_AnGrGRkKbHKLXpUZev244=.4fd034f4-83ac-438d-8cd3-91c4479226de@github.com>
Message-ID: <L40TswEw5Cz15DHvj3vSHJZcDcjTLcgRwkhjSDb_1X8=.1422390c-a04f-41f2-be51-83d0e0cd26b3@github.com>

On Tue, 9 Feb 2021 12:54:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
> 
> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
> 
> Testing: tier1-3, manual runs of sun.nio.cs tests

This pull request has now been integrated.

Changeset: 8b6ab31d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8b6ab31d
Stats:     761 lines in 15 files changed: 257 ins; 404 del; 100 mod

8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets

Reviewed-by: naoto

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

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

From naoto at openjdk.java.net  Fri Feb 12 02:55:57 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 12 Feb 2021 02:55:57 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character
Message-ID: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>

Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.

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

Commit messages:
 - 8261621: Delegate Unicode history from JLS to j.l.Character

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

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

From bpb at openjdk.java.net  Fri Feb 12 03:07:39 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 12 Feb 2021 03:07:39 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character
In-Reply-To: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
Message-ID: <EC-atNPaw7uz3IvxyoW0aLA7ZBHa5KqvirNvZyqYNb0=.60f2af00-d2d8-4002-9ffc-71ab4bb73bc2@github.com>

On Fri, 12 Feb 2021 02:50:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.

Looks fine to me.

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

Marked as reviewed by bpb (Reviewer).

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

From naoto at openjdk.java.net  Fri Feb 12 04:06:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 12 Feb 2021 04:06:55 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
Message-ID: <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>

> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.

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

  Removed empty <p> tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2538/files
  - new: https://git.openjdk.java.net/jdk/pull/2538/files/5560a4cf..b026b5eb

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

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

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

From joehw at openjdk.java.net  Fri Feb 12 06:47:44 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 12 Feb 2021 06:47:44 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
Message-ID: <AG6NwlnrCJ8jyISYphurbTSbaoHm4lAcH4H88vALFac=.e6e6c529-7a3f-4a39-be0d-944fab7034bd@github.com>

On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed empty <p> tag

Marked as reviewed by joehw (Reviewer).

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

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

From smarks at openjdk.java.net  Fri Feb 12 07:52:39 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 12 Feb 2021 07:52:39 GMT
Subject: <i18n dev> RFR: 8260221: java.util.Formatter throws wrong
 exception for mismatched flags in %% conversion
In-Reply-To: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com>
References: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com>
Message-ID: <SDg0-aQeBZ_5dQCkaJjU_CMaqFZHyfEGxJJVHyXxA5c=.ff906231-e881-4507-9dec-5358febe1204@github.com>

On Wed, 3 Feb 2021 22:42:00 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Updating the specification to reflect well-established behavior in Formatter when incorrect flags used for `%`.

Marked as reviewed by smarks (Reviewer).

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

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

From rriggs at openjdk.java.net  Fri Feb 12 15:24:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 12 Feb 2021 15:24:41 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
Message-ID: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com>

On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed empty <p> tag

The table is informative and should not be construed as specification.
The wording "has supported" should be sufficient.

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

Marked as reviewed by rriggs (Reviewer).

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

From igraves at openjdk.java.net  Fri Feb 12 16:09:42 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 12 Feb 2021 16:09:42 GMT
Subject: <i18n dev> Integrated: 8260221: java.util.Formatter throws wrong
 exception for mismatched flags in %% conversion
In-Reply-To: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com>
References: <5TNvaTS1s4MMBmT7oZveQjKZqN6LnYvsBIAN3F0xJy0=.683c7478-7505-43b9-a338-4e9ddcc2e898@github.com>
Message-ID: <sNLbREbEmokus8AJBRhIWBNSfA8Kcpa1YjXkqTQWrMY=.1254e444-474d-42f9-a809-afe6e4c11b38@github.com>

On Wed, 3 Feb 2021 22:42:00 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Updating the specification to reflect well-established behavior in Formatter when incorrect flags used for `%`.

This pull request has now been integrated.

Changeset: 350303d4
Author:    Ian Graves <igraves at openjdk.org>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/350303d4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8260221: java.util.Formatter throws wrong exception for mismatched flags in %% conversion

Reviewed-by: smarks

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

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

From alanb at openjdk.java.net  Fri Feb 12 16:15:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 12 Feb 2021 16:15:41 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
Message-ID: <zkNf3Nh8jC05mGIzgkGJwVJ5CsspE3SE0bbybwk7N0U=.f9384007-6da8-45d4-9ea4-34fce3fa1498@github.com>

On Fri, 12 Feb 2021 04:06:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed empty <p> tag

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

> 84:  *     <td>Unicode 10.0</td></tr>
> 85:  * <tr><td>Java SE 9</td>
> 86:  *     <td>Unicode 8.0</td></tr>

Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release?

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

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

From naoto at openjdk.java.net  Fri Feb 12 17:06:44 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 12 Feb 2021 17:06:44 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <zkNf3Nh8jC05mGIzgkGJwVJ5CsspE3SE0bbybwk7N0U=.f9384007-6da8-45d4-9ea4-34fce3fa1498@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
 <zkNf3Nh8jC05mGIzgkGJwVJ5CsspE3SE0bbybwk7N0U=.f9384007-6da8-45d4-9ea4-34fce3fa1498@github.com>
Message-ID: <r3TDbb1FwJTQRnlth0Tgp4E9fkh_-kEaQcaHQAMjeCk=.24640944-9b26-4c53-b5d1-61e67c5083b4@github.com>

On Fri, 12 Feb 2021 16:13:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed empty <p> tag
>
> src/java.base/share/classes/java/lang/Character.java line 86:
> 
>> 84:  *     <td>Unicode 10.0</td></tr>
>> 85:  * <tr><td>Java SE 9</td>
>> 86:  *     <td>Unicode 8.0</td></tr>
> 
> Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release?

This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here.

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

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

From jason_mehrens at hotmail.com  Fri Feb 12 17:24:35 2021
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 12 Feb 2021 17:24:35 +0000
Subject: <i18n dev> java.util.Fomatter precision and surrogate pairs
Message-ID: <SN7PR18MB40162D8849E94249B6A5B64D838B9@SN7PR18MB4016.namprd18.prod.outlook.com>

Hello i18n-dev,

In the documentation for java.util.Formatter, precision is allowed for 's' general conversions but not 'c' conversions.  What is the rationale for this requirement?

When using surrogate pairs the general conversion will tear surrogate pairs, which seems correct given the type of conversion.
However, if you want to limit the precision and not tear surrogate pairs there no out of the box way to do this.
My understanding is that you have to implement a Formattable which is not ideal.

Reading the docs it looks like 'c' deals with Unicode but doesn't allow setting a precision (substring).
Would it make sense to allow precision for character conversions and enforce a precision limit based on the code point count and not the length?  
I think it would be helpful for java.util.logging.SimpleFormatter and alike where a user wants to limit the max line size but not see garbage characters in the logs.

Thanks,

Jason

====
public class FormatterTester {

	public static void main(String[] args) {
		String nb = "\ud83c\udf09\ud83c\udf09";
		//'s', 'S'	general	If arg implements Formattable, 
		///then arg.formatTo is invoked. 
		//Otherwise, the result is obtained by invoking arg.toString().
		println("s", nb); 
		
		//'c', 'C'|character|The result is a Unicode character
		//For general argument types, the precision is the 
		//maximum number of characters to be written to the output.
		//... if a precision is provided, an exception will be thrown.
		println("c", nb); 
	}
	
	private static void println(String conversion, String arg) {
		System.err.println("len=" + arg.length() 
			+ " count=" + arg.codePointCount(0, arg.length()));
		for (int i = 1, p = arg.length() + 4; i < p; ++i) {
			try {
				System.err.println(String.format("%1$."+ i + conversion, arg));
			} catch (IllegalArgumentException iae) {
				System.err.println("p=" + i + ' ' + iae);
			}
		}
	}
}
====

From darcy at openjdk.java.net  Fri Feb 12 20:32:38 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 12 Feb 2021 20:32:38 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <r3TDbb1FwJTQRnlth0Tgp4E9fkh_-kEaQcaHQAMjeCk=.24640944-9b26-4c53-b5d1-61e67c5083b4@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
 <zkNf3Nh8jC05mGIzgkGJwVJ5CsspE3SE0bbybwk7N0U=.f9384007-6da8-45d4-9ea4-34fce3fa1498@github.com>
 <r3TDbb1FwJTQRnlth0Tgp4E9fkh_-kEaQcaHQAMjeCk=.24640944-9b26-4c53-b5d1-61e67c5083b4@github.com>
Message-ID: <1T9kC0BivWooWIypWLvHnUgOrK8uHRy61EQtJFd1deE=.be9bada9-4766-472c-9ba9-380a7e982d92@github.com>

On Fri, 12 Feb 2021 17:03:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 86:
>> 
>>> 84:  *     <td>Unicode 10.0</td></tr>
>>> 85:  * <tr><td>Java SE 9</td>
>>> 86:  *     <td>Unicode 8.0</td></tr>
>> 
>> Do we really need the history in the API docs? Will will update this table if there is a MR of the JSR for Java 8 that moves to a new Unicode release?
>
> This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here.

Should some acknowledgement be made to the changes in Unicode support done by the Java SE 8 and Java SE 11 MRs with respect to extensions of the base Unicode version?

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

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

From naoto at openjdk.java.net  Fri Feb 12 21:46:39 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 12 Feb 2021 21:46:39 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <1T9kC0BivWooWIypWLvHnUgOrK8uHRy61EQtJFd1deE=.be9bada9-4766-472c-9ba9-380a7e982d92@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
 <zkNf3Nh8jC05mGIzgkGJwVJ5CsspE3SE0bbybwk7N0U=.f9384007-6da8-45d4-9ea4-34fce3fa1498@github.com>
 <r3TDbb1FwJTQRnlth0Tgp4E9fkh_-kEaQcaHQAMjeCk=.24640944-9b26-4c53-b5d1-61e67c5083b4@github.com>
 <1T9kC0BivWooWIypWLvHnUgOrK8uHRy61EQtJFd1deE=.be9bada9-4766-472c-9ba9-380a7e982d92@github.com>
Message-ID: <ZIbl4l5R7-pvhRCxvOcnd4_ngDXI5TwS5tdKdyt52rw=.89a8010a-b2b7-4ab7-b583-aa8108c9142d@github.com>

On Fri, 12 Feb 2021 20:29:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This was requested by Alex, and I thought it sounded reasonable and informative. I think if an MR upgrades the supported Unicode version, it should be listed here.
>
> Should some acknowledgement be made to the changes in Unicode support done by the Java SE 8 and Java SE 11 MRs with respect to extensions of the base Unicode version?

I thought about that but decided not to include them here because the changes made in those MRs were not Unicode version upgrades (i.e., version stayed the same). Let me know if you think otherwise.

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

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

From naoto.sato at oracle.com  Fri Feb 12 23:40:48 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 12 Feb 2021 15:40:48 -0800
Subject: <i18n dev> java.util.Fomatter precision and surrogate pairs
In-Reply-To: <SN7PR18MB40162D8849E94249B6A5B64D838B9@SN7PR18MB4016.namprd18.prod.outlook.com>
References: <SN7PR18MB40162D8849E94249B6A5B64D838B9@SN7PR18MB4016.namprd18.prod.outlook.com>
Message-ID: <0d427a7b-93e5-76d5-2273-6460e257d13f@oracle.com>

Hi Jason,

On 2/12/21 9:24 AM, Jason Mehrens wrote:
> Hello i18n-dev,
> 
> In the documentation for java.util.Formatter, precision is allowed for 's' general conversions but not 'c' conversions.  What is the rationale for this requirement?

Although the error message may be confusing, 'c' conversion cannot be 
used for a String argument (like in your example). It simply converts 
numeric value into a single character, thus no need for output 
"precision." I am not the designer of the class, so might be wrong.

> 
> When using surrogate pairs the general conversion will tear surrogate pairs, which seems correct given the type of conversion.
> However, if you want to limit the precision and not tear surrogate pairs there no out of the box way to do this.
> My understanding is that you have to implement a Formattable which is not ideal.
> 
> Reading the docs it looks like 'c' deals with Unicode but doesn't allow setting a precision (substring).
> Would it make sense to allow precision for character conversions and enforce a precision limit based on the code point count and not the length?
> I think it would be helpful for java.util.logging.SimpleFormatter and alike where a user wants to limit the max line size but not see garbage characters in the logs.

I cannot think of any good solutions off the top of my head, other than 
customizing your own.

Naoto

> 
> Thanks,
> 
> Jason
> 
> ====
> public class FormatterTester {
> 
> 	public static void main(String[] args) {
> 		String nb = "\ud83c\udf09\ud83c\udf09";
> 		//'s', 'S'	general	If arg implements Formattable,
> 		///then arg.formatTo is invoked.
> 		//Otherwise, the result is obtained by invoking arg.toString().
> 		println("s", nb);
> 		
> 		//'c', 'C'|character|The result is a Unicode character
> 		//For general argument types, the precision is the
> 		//maximum number of characters to be written to the output.
> 		//... if a precision is provided, an exception will be thrown.
> 		println("c", nb);
> 	}
> 	
> 	private static void println(String conversion, String arg) {
> 		System.err.println("len=" + arg.length()
> 			+ " count=" + arg.codePointCount(0, arg.length()));
> 		for (int i = 1, p = arg.length() + 4; i < p; ++i) {
> 			try {
> 				System.err.println(String.format("%1$."+ i + conversion, arg));
> 			} catch (IllegalArgumentException iae) {
> 				System.err.println("p=" + i + ' ' + iae);
> 			}
> 		}
> 	}
> }
> ====
> 

From jason_mehrens at hotmail.com  Sun Feb 14 00:09:26 2021
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Sun, 14 Feb 2021 00:09:26 +0000
Subject: <i18n dev> java.util.Fomatter precision and surrogate pairs
Message-ID: <SN7PR18MB40165500919F0CACC6F960CD838A9@SN7PR18MB4016.namprd18.prod.outlook.com>

Hi Naoto,

Sorry for the off thread reply.  I didn't have the mail replies setup on the list and I seem to be unable to add a in-reply-to header via web email.

> Although the error message may be confusing, 'c' conversion cannot be 
> used for a String argument (like in your example). It simply converts 
> numeric value into a single character, thus no need for output 
> "precision." I am not the designer of the class, so might be wrong.

Yes I totally missed that.  I dug up the relevant source:

https://github.com/openjdk/jdk/blob/350303d4f0c71f77fa784a92d13522a380e3b2fe/src/java.base/share/classes/java/util/Formatter.java#L3006
https://github.com/openjdk/jdk/blob/c709e1cbf030e7129fa34815b150097ba6f6840c/test/jdk/java/util/Formatter/Basic-X.java.template#L432

So this code doesn't deal with CharSequence and therefore the precision is implicitly one.  With the exception if null getting converted to 4 chars.

Is it worth me filing an RFE to allow 'c' to accept a CharSequence and allow precision to be set?

Thanks,

Jason

From naoto.sato at oracle.com  Sun Feb 14 18:00:02 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Sun, 14 Feb 2021 10:00:02 -0800
Subject: <i18n dev> java.util.Fomatter precision and surrogate pairs
In-Reply-To: <SN7PR18MB40165500919F0CACC6F960CD838A9@SN7PR18MB4016.namprd18.prod.outlook.com>
References: <SN7PR18MB40165500919F0CACC6F960CD838A9@SN7PR18MB4016.namprd18.prod.outlook.com>
Message-ID: <6d0331a8-7947-1d79-e02c-fba82c8d1628@oracle.com>

Hi Jason,

On 2/13/21 4:09 PM, Jason Mehrens wrote:
> Hi Naoto,
> 
> Sorry for the off thread reply.  I didn't have the mail replies setup on the list and I seem to be unable to add a in-reply-to header via web email.
> 
>> Although the error message may be confusing, 'c' conversion cannot be
>> used for a String argument (like in your example). It simply converts
>> numeric value into a single character, thus no need for output
>> "precision." I am not the designer of the class, so might be wrong.
> 
> Yes I totally missed that.  I dug up the relevant source:
> 
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/350303d4f0c71f77fa784a92d13522a380e3b2fe/src/java.base/share/classes/java/util/Formatter.java*L3006__;Iw!!GqivPVa7Brio!JREncVIBVl3dT2Md_OG5ooK5zYJ9KbJCW8B4Y_9ZyRSXHRlZxda9ZBCpwC9pyV4u$
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/c709e1cbf030e7129fa34815b150097ba6f6840c/test/jdk/java/util/Formatter/Basic-X.java.template*L432__;Iw!!GqivPVa7Brio!JREncVIBVl3dT2Md_OG5ooK5zYJ9KbJCW8B4Y_9ZyRSXHRlZxda9ZBCpwERFw-xy$
> 
> So this code doesn't deal with CharSequence and therefore the precision is implicitly one.  With the exception if null getting converted to 4 chars.
> 
> Is it worth me filing an RFE to allow 'c' to accept a CharSequence and allow precision to be set?

Again, 'c' is for a single character, so I don't think taking 
CharSequence as an argument is the right choice. Rather, I would fix the 
current spec/behavior of 's', which bisects a supplementary character at 
the end. To me, it is just supplementary characters are not handled 
correctly in 's' conversion.

Naoto

From naoto at openjdk.java.net  Tue Feb 16 17:59:51 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 16 Feb 2021 17:59:51 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v3]
In-Reply-To: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
Message-ID: <Y-2JBj0SNzTjuLVmeJTO8iKjaMO0h41vD6xgU-DxezY=.2ea02ae0-9dbe-412a-a58b-55c22d0592d7@github.com>

> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Removed empty <p> tag
 - 8261621: Delegate Unicode history from JLS to j.l.Character

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

Changes: https://git.openjdk.java.net/jdk/pull/2538/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2538&range=02
  Stats: 36 lines in 1 file changed: 34 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2538.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2538/head:pull/2538

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

From rriggs at openjdk.java.net  Tue Feb 16 22:20:51 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 16 Feb 2021 22:20:51 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v3]
In-Reply-To: <Y-2JBj0SNzTjuLVmeJTO8iKjaMO0h41vD6xgU-DxezY=.2ea02ae0-9dbe-412a-a58b-55c22d0592d7@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <Y-2JBj0SNzTjuLVmeJTO8iKjaMO0h41vD6xgU-DxezY=.2ea02ae0-9dbe-412a-a58b-55c22d0592d7@github.com>
Message-ID: <YdL9msMR_jUiA16JXpMW7k--IBRVZ7EiwNJSl3RJ9ug=.aed688d0-b570-4825-869c-26bde99141ce@github.com>

On Tue, 16 Feb 2021 17:59:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Removed empty <p> tag
>  - 8261621: Delegate Unicode history from JLS to j.l.Character

Marked as reviewed by rriggs (Reviewer).

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

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

From naoto at openjdk.java.net  Wed Feb 17 17:39:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 17 Feb 2021 17:39:00 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v4]
In-Reply-To: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
Message-ID: <e8vrH3xjV3Gdq6ckOn6FjpyoLcOZCG3wKN27zwIMmIU=.0e8a8e28-3a0e-4894-9ab4-1a6c03b4f13c@github.com>

> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.

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

  Added a text about the variations from the base Unicode versions.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2538/files
  - new: https://git.openjdk.java.net/jdk/pull/2538/files/b94b41c8..c90cd663

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

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

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

From darcy at openjdk.java.net  Wed Feb 17 18:46:42 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Feb 2021 18:46:42 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v4]
In-Reply-To: <e8vrH3xjV3Gdq6ckOn6FjpyoLcOZCG3wKN27zwIMmIU=.0e8a8e28-3a0e-4894-9ab4-1a6c03b4f13c@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <e8vrH3xjV3Gdq6ckOn6FjpyoLcOZCG3wKN27zwIMmIU=.0e8a8e28-3a0e-4894-9ab4-1a6c03b4f13c@github.com>
Message-ID: <vtWTHvtujEEMbQ2MATDEXNFXnhyeKqsxQUSp7XE04vs=.5b5c57b6-5b4e-4256-9d1e-64fd393d46c9@github.com>

On Wed, 17 Feb 2021 17:39:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a text about the variations from the base Unicode versions.

Marked as reviewed by darcy (Reviewer).

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

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

From naoto at openjdk.java.net  Wed Feb 17 19:39:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 17 Feb 2021 19:39:50 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter
Message-ID: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>

Please review this simple doc fix. A CSR will be filed accordingly.

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

Commit messages:
 - 8261728: SimpleDateFormat should link to DateTimeFormatter

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

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

From bpb at openjdk.java.net  Wed Feb 17 19:48:38 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 17 Feb 2021 19:48:38 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter
In-Reply-To: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
Message-ID: <LWtBhdByhuBKivxghrOQqiYKkwWSDpQ-9Sqc4THSmqM=.4c9d1696-c8fe-4ce3-af32-c1475307ed12@github.com>

On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix. A CSR will be filed accordingly.

LGTM

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

Marked as reviewed by bpb (Reviewer).

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

From rriggs at openjdk.java.net  Wed Feb 17 20:07:39 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Feb 2021 20:07:39 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter
In-Reply-To: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
Message-ID: <Br9GjMYmDAubYT0E-CdyckPl_Iw84hY_JxzXdzRDjsY=.9edcb709-2deb-4b94-98ae-5949119769df@github.com>

On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix. A CSR will be filed accordingly.

Marked as reviewed by rriggs (Reviewer).

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

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

From lancea at openjdk.java.net  Wed Feb 17 20:07:39 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 17 Feb 2021 20:07:39 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter
In-Reply-To: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
Message-ID: <6kXdnOqEAAZaZszfjoH4OfToRHuUbvu61Lcwb-oP5Ds=.f01982e4-d2a4-4987-b01a-a9ce54e259c1@github.com>

On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix. A CSR will be filed accordingly.

Hi Naoto,

Looks good.  

Any thoughts to making the new wording stick out more perhaps via a something like  "Note: Consider...." and bolding "Note:" 


Not sure if it is @apiNote worthy but I guess that is an option also?

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

Marked as reviewed by lancea (Reviewer).

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

From naoto at openjdk.java.net  Wed Feb 17 20:21:57 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 17 Feb 2021 20:21:57 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter [v2]
In-Reply-To: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
Message-ID: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>

> Please review this simple doc fix. A CSR will be filed accordingly.

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

  Made the additional text an @apiNote

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2616/files
  - new: https://git.openjdk.java.net/jdk/pull/2616/files/d840b562..c93badb4

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

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

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

From bpb at openjdk.java.net  Wed Feb 17 20:21:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 17 Feb 2021 20:21:58 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter [v2]
In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
 <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
Message-ID: <TLj4VvJyiJiIjGhA8XUXAjEh3JGj5RF--oLHfhEfWNA=.cb48a65a-2df7-4947-b239-bf34760054a5@github.com>

On Wed, 17 Feb 2021 20:18:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this simple doc fix. A CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the additional text an @apiNote

Marked as reviewed by bpb (Reviewer).

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

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

From lancea at openjdk.java.net  Wed Feb 17 20:21:58 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 17 Feb 2021 20:21:58 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter [v2]
In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
 <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
Message-ID: <IhlztBFGm5zEjv23OMvCtoF-HH73kZFWn4F4-ptFDYw=.ab7fe6b4-556e-44de-9570-9e3279fc17d7@github.com>

On Wed, 17 Feb 2021 20:18:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this simple doc fix. A CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the additional text an @apiNote

Marked as reviewed by lancea (Reviewer).

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

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

From naoto at openjdk.java.net  Wed Feb 17 20:21:59 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 17 Feb 2021 20:21:59 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter [v2]
In-Reply-To: <6kXdnOqEAAZaZszfjoH4OfToRHuUbvu61Lcwb-oP5Ds=.f01982e4-d2a4-4987-b01a-a9ce54e259c1@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
 <6kXdnOqEAAZaZszfjoH4OfToRHuUbvu61Lcwb-oP5Ds=.f01982e4-d2a4-4987-b01a-a9ce54e259c1@github.com>
Message-ID: <USJDSnPLFBC15NVhnqzq4UdzpECNczw6v8gHENFRyLA=.b1c57708-a6da-47f4-b77d-c3377c8e6873@github.com>

On Wed, 17 Feb 2021 20:04:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made the additional text an @apiNote
>
> Hi Naoto,
> 
> Looks good.  
> 
> Any thoughts to making the new wording stick out more perhaps via a something like  "Note: Consider...." and bolding "Note:" 
> 
> 
> Not sure if it is @apiNote worthy but I guess that is an option also?

> Not sure if it is @APinote worthy but I guess that is an option also?

Good point. Modified.

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

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

From naoto at openjdk.java.net  Wed Feb 17 22:13:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 17 Feb 2021 22:13:40 GMT
Subject: <i18n dev> Integrated: 8261621: Delegate Unicode history from JLS
 to j.l.Character
In-Reply-To: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
Message-ID: <zUbgFQcVxndq5EKoHROEX-ke-o6r6q237m0HR49UJeU=.c3936ff8-bdf7-42f1-b71e-e159560955ca@github.com>

On Fri, 12 Feb 2021 02:50:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this doc fix to j.l.Character, which now includes the table of the history of supported Unicode versions. A corresponding CSR will be filed accordingly.

This pull request has now been integrated.

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

8261621: Delegate Unicode history from JLS to j.l.Character

Reviewed-by: bpb, joehw, rriggs, darcy

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

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

From iris at openjdk.java.net  Thu Feb 18 00:07:41 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 18 Feb 2021 00:07:41 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter [v2]
In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
 <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
Message-ID: <HFshom7PY3xbg686kEyczTlbWtpucDERHWq0-jHoCCo=.11b80f25-30d1-455d-8573-e1bb659d05d5@github.com>

On Wed, 17 Feb 2021 20:21:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this simple doc fix. A CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the additional text an @apiNote

Marked as reviewed by iris (Reviewer).

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

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

From dholmes at openjdk.java.net  Thu Feb 18 03:59:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 18 Feb 2021 03:59:41 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
 <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com>
Message-ID: <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com>

On Fri, 12 Feb 2021 15:22:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 
> 
> The table is informative and should not be construed as specification.
> The wording "has supported" should be sufficient.

If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification?

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

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

From rriggs at openjdk.java.net  Thu Feb 18 14:51:46 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 18 Feb 2021 14:51:46 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
 <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com>
 <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com>
Message-ID: <e4XUq1r0_qooat4JH7j1QYPGM0Wttl957w875xMXvS8=.0e55fa3b-47b3-4259-8539-7461affc8170@github.com>

On Thu, 18 Feb 2021 03:56:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The table is informative and should not be construed as specification.
>> The wording "has supported" should be sufficient.
>
>> 
>> 
>> The table is informative and should not be construed as specification.
>> The wording "has supported" should be sufficient.
> 
> If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification?

The current version of Unicode is specified in a normative statement just before the table.
"Character information is based on the Unicode Standard, version 13.0."

The table is not a specification of past revisions.

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

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

From rriggs at openjdk.java.net  Thu Feb 18 14:57:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 18 Feb 2021 14:57:41 GMT
Subject: <i18n dev> RFR: 8261728: SimpleDateFormat should link to
 DateTimeFormatter [v2]
In-Reply-To: <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
 <4Q2jHJC0srF_pZfjRjIANZYxnQW-bZIDVL1XSr6bdB4=.c49a75c8-89d6-414c-ad78-40a0553de8b2@github.com>
Message-ID: <XmC58B-o5eIE6K9P2Ji36apaKSv6BQrsczw_uEHrFqU=.b55832f9-1cd1-4101-9320-caf8541eaff0@github.com>

On Wed, 17 Feb 2021 20:21:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this simple doc fix. A CSR will be filed accordingly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the additional text an @apiNote

Marked as reviewed by rriggs (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Feb 19 14:00:18 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Feb 2021 14:00:18 GMT
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <e4XUq1r0_qooat4JH7j1QYPGM0Wttl957w875xMXvS8=.0e55fa3b-47b3-4259-8539-7461affc8170@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
 <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com>
 <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com>
 <e4XUq1r0_qooat4JH7j1QYPGM0Wttl957w875xMXvS8=.0e55fa3b-47b3-4259-8539-7461affc8170@github.com>
Message-ID: <qscui0On7WiTrX364AXzNQMXLPTKT891aYduucbqc10=.8c8071f8-417e-4f8d-bbb3-91265baad0a9@github.com>

On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> 
>>> 
>>> The table is informative and should not be construed as specification.
>>> The wording "has supported" should be sufficient.
>> 
>> If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification?
>
> The current version of Unicode is specified in a normative statement just before the table.
> "Character information is based on the Unicode Standard, version 13.0."
> 
> The table is not a specification of past revisions.

RIght. And each Java SE release's spec has the same sentence with the version replaced. In fact, vendors cannot incorporate arbitrary Unicode versions as it would involve API changes. If they wanted to do so, an MR should have to be released.

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

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

From naoto at openjdk.java.net  Fri Feb 19 16:47:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Feb 2021 16:47:41 GMT
Subject: <i18n dev> Integrated: 8261728: SimpleDateFormat should link to
 DateTimeFormatter
In-Reply-To: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
References: <EYt_LcqsU6W8mfjFAJeeiGNjik-aFgKsw-JmItVPa90=.06b760f2-430f-481b-a41f-72c047d9e69c@github.com>
Message-ID: <3Oe9KvrW3YQktepmERb0V4JuOQs-mWHBeecVELn3cH4=.4987bf1c-6eba-4afa-ad10-b10d5b380940@github.com>

On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this simple doc fix. A CSR will be filed accordingly.

This pull request has now been integrated.

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

8261728: SimpleDateFormat should link to DateTimeFormatter

Reviewed-by: bpb, rriggs, lancea, iris

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

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

From naoto at openjdk.java.net  Sat Feb 20 00:50:54 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 20 Feb 2021 00:50:54 GMT
Subject: <i18n dev> RFR: 8262066: ProblemList
 java/util/Locale/LocaleProvidersRun.java
Message-ID: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>

The subject test case is failing under the JMS-enabled environment.

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

Commit messages:
 - 8262066: ProblemList java/util/Locale/LocaleProvidersRun.java

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

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

From dcubed at openjdk.java.net  Sat Feb 20 02:19:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 20 Feb 2021 02:19:41 GMT
Subject: <i18n dev> RFR: 8262066: ProblemList
 java/util/Locale/LocaleProvidersRun.java
In-Reply-To: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
Message-ID: <EJeRdc9kkuCwLFSFRQ-FCYBCutOYgfWK4TJT4UzdCdQ=.be0cbe63-1f6e-4fee-9ae2-96da488b891b@github.com>

On Sat, 20 Feb 2021 00:44:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The subject test case is failing under the JMS-enabled environment.

Changes requested by dcubed (Reviewer).

test/jdk/ProblemList.txt line 799:

> 797: # jdk_util
> 798: 
> 799: java/util/Locale/LocaleProvidersRun.java                        8261919 generic-all

This only needs to be ProblemListed on linux-x64.

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

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

From naoto at openjdk.java.net  Sat Feb 20 02:37:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 20 Feb 2021 02:37:41 GMT
Subject: <i18n dev> RFR: 8262066: ProblemList
 java/util/Locale/LocaleProvidersRun.java
In-Reply-To: <EJeRdc9kkuCwLFSFRQ-FCYBCutOYgfWK4TJT4UzdCdQ=.be0cbe63-1f6e-4fee-9ae2-96da488b891b@github.com>
References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
 <EJeRdc9kkuCwLFSFRQ-FCYBCutOYgfWK4TJT4UzdCdQ=.be0cbe63-1f6e-4fee-9ae2-96da488b891b@github.com>
Message-ID: <2j_x1T04h9QPiS0G2N8bsZloaEW55b1fk-7KkUPEHcs=.0177ef38-5d74-4f58-9a4e-940c362f2553@github.com>

On Sat, 20 Feb 2021 02:16:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The subject test case is failing under the JMS-enabled environment.
>
> test/jdk/ProblemList.txt line 799:
> 
>> 797: # jdk_util
>> 798: 
>> 799: java/util/Locale/LocaleProvidersRun.java                        8261919 generic-all
> 
> This only needs to be ProblemListed on linux-x64.

It's not platform specific, but specific to the environment that is usage tracker enabled. Thus I put it as 'generic'.

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

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

From david.holmes at oracle.com  Mon Feb 22 04:17:52 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 22 Feb 2021 14:17:52 +1000
Subject: <i18n dev> RFR: 8261621: Delegate Unicode history from JLS to
 j.l.Character [v2]
In-Reply-To: <qscui0On7WiTrX364AXzNQMXLPTKT891aYduucbqc10=.8c8071f8-417e-4f8d-bbb3-91265baad0a9@github.com>
References: <ys52qS9VouOlXH63MFUhbzJTbeqKnG0Zd7veDZLOMQA=.5dbcdcaa-260c-47b0-9329-ad096d2eaf50@github.com>
 <a_mZhyMMz3TZG6NKy1oB1096Aeh4-l8C3Cq3Y25Yh7w=.30b39a10-5ae1-497b-b757-4a9de3113441@github.com>
 <24HhlkSKVVYGhsBRDnbbS87zSlG9ToH7fyeICQ-dq1E=.0a4f7a26-6de8-4ba8-8158-579f534909e3@github.com>
 <7wUSWNNgJzfV3IlX-oUL-Jm43hTY4EeWxxTmGxqHnQ8=.cc622e33-b1d9-457f-ad78-73e70586f04c@github.com>
 <e4XUq1r0_qooat4JH7j1QYPGM0Wttl957w875xMXvS8=.0e55fa3b-47b3-4259-8539-7461affc8170@github.com>
 <qscui0On7WiTrX364AXzNQMXLPTKT891aYduucbqc10=.8c8071f8-417e-4f8d-bbb3-91265baad0a9@github.com>
Message-ID: <d58894e4-99ab-bb02-2c97-cff12d19186c@oracle.com>

On 20/02/2021 12:00 am, Naoto Sato wrote:
> On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
> 
>>>>
>>>>
>>>> The table is informative and should not be construed as specification.
>>>> The wording "has supported" should be sufficient.
>>>
>>> If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free to support, or not, whatever version of Unicode that they chose? Surely a minimum supported version must be part of the platform specification?
>>
>> The current version of Unicode is specified in a normative statement just before the table.
>> "Character information is based on the Unicode Standard, version 13.0."
>>
>> The table is not a specification of past revisions.
> 
> RIght. And each Java SE release's spec has the same sentence with the version replaced. In fact, vendors cannot incorporate arbitrary Unicode versions as it would involve API changes. If they wanted to do so, an MR should have to be released.

Roger and Naoto, thanks for clarifying. I took Roger's original comment 
out of context.

David

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

From naoto at openjdk.java.net  Mon Feb 22 17:03:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 22 Feb 2021 17:03:05 GMT
Subject: <i18n dev> RFR: 8262066: ProblemList
 java/util/Locale/LocaleProvidersRun.java [v2]
In-Reply-To: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
Message-ID: <ccb3_KFNsRGs0Cd7zK3pJ8iDYfZFAica2ZH9RklI224=.00d0ff21-3d6c-42a6-b8c9-4cd6d2eeaadd@github.com>

> The subject test case is failing under the JMS-enabled environment.

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

  Limit the exclustion to linux-x64

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2657/files
  - new: https://git.openjdk.java.net/jdk/pull/2657/files/7c9cf40e..6a6bc241

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

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

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

From naoto at openjdk.java.net  Tue Feb 23 02:13:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 23 Feb 2021 02:13:46 GMT
Subject: <i18n dev> RFR: 8261919: java/util/Locale/LocaleProvidersRun.java
 failed with "RuntimeException: Expected log was not emitted. LogRecord:
 null"
Message-ID: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>

Please review the fix to this test case failure that occurs with the usage tracker enabled JRE.

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

Commit messages:
 - 8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null"

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

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

From joehw at openjdk.java.net  Tue Feb 23 07:31:38 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 23 Feb 2021 07:31:38 GMT
Subject: <i18n dev> RFR: 8261919:
 java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException:
 Expected log was not emitted. LogRecord: null"
In-Reply-To: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
References: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
Message-ID: <bgmveg3fdf5cp7Wti6xGtx0R8OqUEcJfRakYPHmfjoE=.cc78a6c3-6dcf-4e0c-a58e-572768b3e887@github.com>

On Tue, 23 Feb 2021 02:09:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE.

Marked as reviewed by joehw (Reviewer).

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

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

From dfuchs at openjdk.java.net  Tue Feb 23 09:53:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 23 Feb 2021 09:53:40 GMT
Subject: <i18n dev> RFR: 8261919:
 java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException:
 Expected log was not emitted. LogRecord: null"
In-Reply-To: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
References: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
Message-ID: <d0mfvBh6EJo_ouF9qmELEBIhov7l_LbyR0tefvwRpjM=.79cd44f5-67b8-44a5-a927-85d7b7f3e65c@github.com>

On Tue, 23 Feb 2021 02:09:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE.

test/jdk/java/util/Locale/LocaleProviders.java line 416:

> 414:     // Set the root logger on loading the logging class
> 415:     public static class LogConfig {
> 416:         final static LogRecord[] lra = new LogRecord[1];

I would suggest to use some multi-thread safe container rather than a simple array to store the LogRecord. For instance - a CopyOnWriteArrayList - or something like that. Also you may want to harden the test by allowing for the possibility that some other logging might have occurred, and search the list for the record you expect rather than assuming it will be the first and only one.
Otherwise looks good!

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

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

From naoto at openjdk.java.net  Tue Feb 23 18:42:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 23 Feb 2021 18:42:41 GMT
Subject: <i18n dev> RFR: 8261919:
 java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException:
 Expected log was not emitted. LogRecord: null"
In-Reply-To: <d0mfvBh6EJo_ouF9qmELEBIhov7l_LbyR0tefvwRpjM=.79cd44f5-67b8-44a5-a927-85d7b7f3e65c@github.com>
References: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
 <d0mfvBh6EJo_ouF9qmELEBIhov7l_LbyR0tefvwRpjM=.79cd44f5-67b8-44a5-a927-85d7b7f3e65c@github.com>
Message-ID: <hpOI-JdkjUvscpRLeIQ4Sfm67Q_TUU9l5HO-um_gGPQ=.7c4721d1-090b-4fa2-bfea-392ccfd82e37@github.com>

On Tue, 23 Feb 2021 09:49:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE.
>
> test/jdk/java/util/Locale/LocaleProviders.java line 416:
> 
>> 414:     // Set the root logger on loading the logging class
>> 415:     public static class LogConfig {
>> 416:         final static LogRecord[] lra = new LogRecord[1];
> 
> I would suggest to use some multi-thread safe container rather than a simple array to store the LogRecord. For instance - a CopyOnWriteArrayList - or something like that. Also you may want to harden the test by allowing for the possibility that some other logging might have occurred, and search the list for the record you expect rather than assuming it will be the first and only one.
> Otherwise looks good!

Thanks, Daniel. Will update the fix as you suggested.

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

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

From naoto at openjdk.java.net  Tue Feb 23 19:35:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 23 Feb 2021 19:35:55 GMT
Subject: <i18n dev> RFR: 8261919:
 java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException:
 Expected log was not emitted. LogRecord: null" [v2]
In-Reply-To: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
References: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
Message-ID: <9Qi49DBn5Y1YWqCKBwXfJIB6CGdRT1grXYhHHSHPsUk=.cb341f03-4ed0-4795-806a-73135b9aeb77@github.com>

> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE.

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

  Reflecting review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2683/files
  - new: https://git.openjdk.java.net/jdk/pull/2683/files/bfa3a8e5..4d82e8aa

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

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

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

From dfuchs at openjdk.java.net  Tue Feb 23 19:50:41 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 23 Feb 2021 19:50:41 GMT
Subject: <i18n dev> RFR: 8261919:
 java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException:
 Expected log was not emitted. LogRecord: null" [v2]
In-Reply-To: <9Qi49DBn5Y1YWqCKBwXfJIB6CGdRT1grXYhHHSHPsUk=.cb341f03-4ed0-4795-806a-73135b9aeb77@github.com>
References: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
 <9Qi49DBn5Y1YWqCKBwXfJIB6CGdRT1grXYhHHSHPsUk=.cb341f03-4ed0-4795-806a-73135b9aeb77@github.com>
Message-ID: <QvvOHVoUZNV13anH5Vbs8A4vlvHtJI3rYy26SDq2svk=.1f0ad349-a244-4e9b-83b5-f300c09b347d@github.com>

On Tue, 23 Feb 2021 19:35:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments.

LGTM!

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

Marked as reviewed by dfuchs (Reviewer).

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

From naoto at openjdk.java.net  Wed Feb 24 16:26:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Feb 2021 16:26:41 GMT
Subject: <i18n dev> Integrated: 8261919:
 java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException:
 Expected log was not emitted. LogRecord: null"
In-Reply-To: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
References: <bQWYtLbztkuTgd3FeDBsciLzLoAQx3md9Q8ebrrPztE=.522f22a4-02ad-4932-a1b5-606ed607da58@github.com>
Message-ID: <utTZbtPfbWQ5fpEBL-QwpXvVZFIrCApeE0Ua-MYYm30=.9d9dade2-ff8d-44c4-8975-7065598975c1@github.com>

On Tue, 23 Feb 2021 02:09:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to this test case failure that occurs with the usage tracker enabled JRE.

This pull request has now been integrated.

Changeset: 9d9ad969
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d9ad969
Stats:     31 lines in 2 files changed: 16 ins; 7 del; 8 mod

8261919: java/util/Locale/LocaleProvidersRun.java failed with "RuntimeException: Expected log was not emitted. LogRecord: null"

Reviewed-by: joehw, dfuchs

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

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

From naoto at openjdk.java.net  Wed Feb 24 16:32:45 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Feb 2021 16:32:45 GMT
Subject: <i18n dev> RFR: 8262066: ProblemList
 java/util/Locale/LocaleProvidersRun.java [v2]
In-Reply-To: <EJeRdc9kkuCwLFSFRQ-FCYBCutOYgfWK4TJT4UzdCdQ=.be0cbe63-1f6e-4fee-9ae2-96da488b891b@github.com>
References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
 <EJeRdc9kkuCwLFSFRQ-FCYBCutOYgfWK4TJT4UzdCdQ=.be0cbe63-1f6e-4fee-9ae2-96da488b891b@github.com>
Message-ID: <bZP3ZlOc3Bnn81eryltHV2JYjAobgZLxVmmMXnSYxjc=.565442a7-1db2-4b5e-afd4-7d86931f1124@github.com>

On Sat, 20 Feb 2021 02:16:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Limit the exclustion to linux-x64
>
> Changes requested by dcubed (Reviewer).

As the original issue was resolved, no need to problem list this.

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

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

From naoto at openjdk.java.net  Wed Feb 24 16:32:45 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Feb 2021 16:32:45 GMT
Subject: <i18n dev> Withdrawn: 8262066: ProblemList
 java/util/Locale/LocaleProvidersRun.java
In-Reply-To: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
References: <1Jdw1x5AqDZpzD_Z3vsp-JDY-3x3PcngIMUnq_CBOMs=.14114c0a-08ab-495f-ab96-5c2dc7cc0dd2@github.com>
Message-ID: <DVdL9xdTsdDFws_RlYpfCh5xR9EuaMqyy5PGqNWZFR8=.4e2e74ae-4270-4beb-a522-def15b4884ad@github.com>

On Sat, 20 Feb 2021 00:44:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The subject test case is failing under the JMS-enabled environment.

This pull request has been closed without being integrated.

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

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

From cgo at openjdk.java.net  Fri Feb 26 17:56:03 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 26 Feb 2021 17:56:03 GMT
Subject: <i18n dev> RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
Message-ID: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>

Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java

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

Commit messages:
 - Fixes coding style.

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

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

From alanb at openjdk.java.net  Sat Feb 27 08:06:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 27 Feb 2021 08:06:39 GMT
Subject: <i18n dev> RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
Message-ID: <zYXYhx46bm8g_dYCTXxlnrIIoOldQwc7giadIrKOxao=.22da3a8e-6349-473f-8015-a64488572469@github.com>

On Fri, 26 Feb 2021 17:50:19 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java

Looks fine. This source file was a .template until a few weeks ago, probably should have fixed the indentation issues when moving it to a .java file.

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

Marked as reviewed by alanb (Reviewer).

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