Re: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17]

[Naoto Sato]

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess  wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   do it as naotoj said

Reviewed i18n-related changes and they look good. One minor suggestion in 
`Calendar`, but that can be applied later.

src/java.base/share/classes/java/util/Calendar.java line 2648:

> 2646: set.add("gregory");
> 2647: set.add("buddhist");
> 2648: set.add("japanese");

This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base

[Naoto Sato]

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: 
> a/the, an?/an?, the/the…
> 
> Also, I fixed a couple of spelling mistakes.

LGTM for i18n changes.

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8286378: Address possibly lossy conversions in java.base

[Naoto Sato]

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs  wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy 
> conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not 
> assignment compatible with the type of the variable, a cast is implied and 
> possible lossy conversion may silently occur. While similar situations are 
> resolved as compilation errors for primitive assignments, there are no 
> similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the 
> implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of 
> the compound assignment.
> Since these casts are truncating the value, there might be a different 
> refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Looks good. Assuming copyright years will be updated.

src/java.base/share/classes/java/time/es line 1:

> 1: X

Looks like a random file was added by accident?

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8284893: Fix typos in java.base [v4]

[Naoto Sato]

On Tue, 19 Apr 2022 16:50:12 GMT, Magnus Ihse Bursie  wrote:

>> I ran `codespell` on the `src/java.base` directory, and accepted those 
>> changes where it indeed discovered real typos.
>> 
>> (Due to false positives this can unfortunately not be run automatically) 
>> 
>> The majority of fixes are in comments. A handful is in strings, one in a 
>> local variable name, and a couple in parameter declarations.
>> 
>> Annoyingly, there are several instances of "childs" (instead of "children") 
>> in the source code, but they were not local and I dared not change them. 
>> Someone braver than me might take a stab at it, perhaps..
>
> Magnus Ihse Bursie has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - Update Oracle copyrights
>  - Also revert changes in ASM (3rd party code)

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]

[Naoto Sato]

On Thu, 14 Apr 2022 18:32:03 GMT, Naoto Sato  wrote:

>>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
>> 
>> @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But 
>> usually we only solve 1 issue in 1 pr, so I think it's better to wait after 
>> this.
>
> Thanks. Will fix it myself, as I want to eliminate that immediate value in 
> the code.

PR opened, based on this PR.
https://github.com/openjdk/jdk/pull/8253

-

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

Re: RFR: 8284893: Fix typos in java.base

[Naoto Sato]

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie  wrote:

> I ran `codespell` on the `src/java.base` directory, and accepted those 
> changes where it indeed discovered real typos.
> 
> (Due to false positives this can unfortunately not be run automatically) 
> 
> The majority of fixes are in comments. A handful is in strings, one in a 
> local variable name, and a couple in parameter declarations.
> 
> Annoyingly, there are several instances of "childs" (instead of "children") 
> in the source code, but they were not local and I dared not change them. 
> Someone braver than me might take a stab at it, perhaps..

src/java.base/share/classes/jdk/internal/icu/impl/NormalizerImpl.java line 2002:

> 2000: }
> 2001: 
> 2002: // this is where we are right now with all these 
> indices:

Although these are actual typos, they come from upstream ICU code. Changing 
them locally would make merging complicated, so please exclude ICU related 
changes from the PR. I guess fixes in other 3rd party libraries are in the same 
boat.

-

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

Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]

[Naoto Sato]

On Thu, 14 Apr 2022 17:06:53 GMT, XenoAmess  wrote:

>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
>
>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
> 
> @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually 
> we only solve 1 issue in 1 pr, so I think it's better to wait after this.

Thanks. Will fix it myself, as I want to eliminate that immediate value in the 
code.

-

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

Re: RFR: 8186958: Need method to create pre-sized HashMap [v16]

[Naoto Sato]

On Wed, 13 Apr 2022 23:48:06 GMT, Stuart Marks  wrote:

> but I suspect the cleanup may simply be removing them entirely.

+1 for removing it.

-

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

Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]

[Naoto Sato]

On Wed, 13 Apr 2022 22:40:38 GMT, Stuart Marks  wrote:

>> XenoAmess has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   update LastModified
>
> src/java.base/share/classes/java/lang/Character.java line 8574:
> 
>> 8572: private static final HashMap 
>> aliases;
>> 8573: static {
>> 8574: aliases = HashMap.newHashMap(162);
> 
> @naotoj Seems like this magic number is likely to go out of date. Should 
> there be a test for it like the one you updated for NUM_ENTITIES? 
> [JDK-8283465](https://bugs.openjdk.java.net/browse/JDK-8283465).

Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856

-

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

Re: RFR: 8186958: Need method to create pre-sized HashMap [v16]

[Naoto Sato]

On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess  wrote:

>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   revert changes in:
>   src/java.desktop
>   src/java.management
>   src/jdk.internal.vm.ci
>   src/jdk.jfr
>   src/jdk.management.jfr
>   src/jdk.management
>   src/utils/IdealGraphVisualizer

Looks good for changes in i18n related call sites, assuming that the copyright 
years will be updated.

Should we need some additions/modifications to the hashmap optimal capacity 
utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`?

-

Marked as reviewed by naoto (Reviewer).

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

Integrated: 8283698: Refactor Locale constructors used in src/test

[Naoto Sato]

On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato  wrote:

> This is a follow-on task after deprecating the Locale constructors 
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are 
> simple replacements to Locale constructors with `Locale.of()` or Locale 
> constants, such as `Locale.US`.

This pull request has now been integrated.

Changeset: d6b4693c
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/d6b4693c0527385f8999089b3f8b2120548efecb
Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod

8283698: Refactor Locale constructors used in src/test

Reviewed-by: iris, joehw

-

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

Re: RFR: 8283698: Refactor Locale constructors used in src/test

[Naoto Sato]

On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang  wrote:

>> This is a follow-on task after deprecating the Locale constructors 
>> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are 
>> simple replacements to Locale constructors with `Locale.of()` or Locale 
>> constants, such as `Locale.US`.
>
> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
> 
>> 79: 
>> 80: /**
>> 81:  * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
> 
> Locale.France?

The test code parses the input string (eg. "fr_FR") into 3 elements, `name`, 
`country`, and `variant`, then create a `Locale` using those 3 elements. 
Changing it to `Locale.FRANCE` does not seem right here.

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
> 
>> 61: Locale.of("it", "IT", "EURO"),
>> 62: Locale.forLanguageTag("de-AT"),
>> 63: Locale.forLanguageTag("fr-CH"),
> 
> Use the new factory? Ok not to change as these are tests and there are too 
> many of them. It's not deprecated anyways.

`Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it 
validates the input language tag, while `Locale.of()` doesn't as well as Locale 
constructors.

> test/jdk/java/text/Format/common/Bug6215962.java line 58:
> 
>> 56: check(mf1, mf2, false);
>> 57: 
>> 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
> 
> Locale.JAPAN?

The test intends to compare the generated `MessageFormat` objects (`mf2` & 
`mf1`) from using a constant `Locale.JAPAN` and the factory method. So I 
believe leaving it as `Locale.of()` makes sense.

-

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

RFR: 8283698: Refactor Locale constructors used in src/test

[Naoto Sato]

This is a follow-on task after deprecating the Locale constructors 
(https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are 
simple replacements to Locale constructors with `Locale.of()` or Locale 
constants, such as `Locale.US`.

-

Commit messages:
 - 8283698: Refactor Locale constructors used in src/test

Changes: https://git.openjdk.java.net/jdk/pull/8130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8130=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283698
  Stats: 750 lines in 182 files changed: 3 ins; 3 del; 744 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8130/head:pull/8130

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

Re: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10

[Naoto Sato]

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung  wrote:

> redo of 8280400

I believe 
`src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties`
 and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to 
the l10n changes.

-

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

Re: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10

[Naoto Sato]

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung  wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

LGTM

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8282819: Deprecate Locale class constructors

[Naoto Sato]

On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs  wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. 
>> There is already a factory method and a builder to return singletons, so 
>> there is no need to have constructors anymore unless one purposefully wants 
>> to create `ill-formed` Locale objects, which is discouraged. We cannot 
>> terminally deprecate those constructors for the compatibility to serialized 
>> objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/java/util/Locale.java line 245:
> 
>> 243:  * Factory Method
>> 244:  *
>> 245:  * The method {@link #forLanguageTag} obtains a {@code Locale}
> 
> The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like 
> the best name for the factory.
> Yes, it already exists and does what's required but you might get better 
> uptake with a more natural name.
> 
> Some alternatives:
>  - `Locale.of("en_US")` - short and conventional
>  - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
>  - `Locale.forLanguage("en_US")` - natural but less conventional

I was thinking of a *new* factory method, along the line with Stuart's 
suggestion, something like this:

Locale.of(String... elements)

where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or 
`(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot 
be null. These elements are *not* language tags, but conventional arguments to 
constructors, so it is compatible (and works as a stop-gap) to the old 
constructors. This way third parties will not have to deal with the boilerplate 
code mentioned above on migration.

-

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

Re: RFR: 8282819: Deprecate Locale class constructors

[Naoto Sato]

On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks  wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. 
>> There is already a factory method and a builder to return singletons, so 
>> there is no need to have constructors anymore unless one purposefully wants 
>> to create `ill-formed` Locale objects, which is discouraged. We cannot 
>> terminally deprecate those constructors for the compatibility to serialized 
>> objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
>  line 375:
> 
>> 373: (locale.getLanguage().isEmpty() ? "und" : 
>> locale.getLanguage()) +
>> 374: (locale.getCountry().isEmpty() ? "" : "-" + 
>> locale.getCountry()) +
>> 375: (locale.getVariant().isEmpty() ? "" : 
>> "-x-lvariant-" + locale.getVariant()));
> 
> It seems like this snippet (and ones very similar to it) are repeated several 
> times throughout the JDK code as replacements for the two- and three-arg 
> constructors. This seems like a fair increase in complexity, and the use of 
> "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third 
> party code that uses the Locale constructors replace them with this snippet? 
> Is there something better that we can provide?

True. One solution could be to expose `Locale.getInstance()`, which is 
currently a package-private static method, for this purpose. Though that means 
promoting `ill-formed` locale objects which defy some part of the deprecation 
cause.

-

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

RFR: 8282819: Deprecate Locale class constructors

[Naoto Sato]

Proposing to deprecate the constructors in the `java.util.Locale` class. There 
is already a factory method and a builder to return singletons, so there is no 
need to have constructors anymore unless one purposefully wants to create 
`ill-formed` Locale objects, which is discouraged. We cannot terminally 
deprecate those constructors for the compatibility to serialized objects 
created with older JDKs. Please see the draft CSR for more detail.

-

Commit messages:
 - 8282819: Deprecate Locale class constructors

Changes: https://git.openjdk.java.net/jdk/pull/7947/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7947=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282819
  Stats: 904 lines in 196 files changed: 74 ins; 22 del; 808 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

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

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

[Naoto Sato]

On Wed, 16 Mar 2022 21:56:53 GMT, Magnus Ihse Bursie  wrote:

>> make/modules/jdk.charsets/Gensrc.gmk line 32:
>> 
>>> 30: # Generate files using the charsetmapping tool
>>> 31: #
>>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping
>> 
>> Is it intentional to leave `java.base` literal here, or should it be 
>> replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' 
>> `gensrc.gmk` too
>
> This is part of the weirdness of charsetmapping that Alan talks about. The 
> charsetmapping data is shared between java.base and jdk.charsets in a way 
> that makes it non-trivial to disentangle. 
> 
> So this reference to java.base is quite intentional -- replacing it with 
> $(MODULE_SRC) would have pointed to src/jdk.charsets instead of 
> src/java.base, which would have been incorrect.

Thanks for reminding me. Then yes, I'd agree with Alan. It'd be much simpler to 
exclude this from this PR.

-

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

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]

[Naoto Sato]

On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung  wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   removed incorrect translation of compiler configuration file

LGTM. Thanks for the change.

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

[Naoto Sato]

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie  wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. 
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by 
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by 
>> make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after 
>> all, "source code" for that module that is "compiler" into resulting 
>> deliverables, for that module. (But the "source code" language is not Java 
>> or C, but typically a highly domain specific language or data format, and 
>> the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. 
>> When such data is changed, most of the time build-dev (or the new build 
>> label) is involved, even though this has nothing to do with the build. While 
>> this is annoying, a worse problem is if the actual team that needs to review 
>> the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to 
> a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>
>Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: 
> https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

Looks good, with minor comments. Also I am assuming you will modify the 
copyright year for these files before the merge.

make/modules/jdk.charsets/Gensrc.gmk line 32:

> 30: # Generate files using the charsetmapping tool
> 31: #
> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping

Is it intentional to leave `java.base` literal here, or should it be replaced 
with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3]

[Naoto Sato]

On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung  wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   removed repeated lines from ROOT bundle in CurrencyNames

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties 
line 1:

> 1: #

The change to this file (moving ct.properties to ct_ja.properties) does look 
suspicious. Looks like this is not a translation file, but some kind of a 
configuration for `javac`. If so, it should not be translated (and translation 
configuration in the closed repository should exclude this file)

-

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

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

[Naoto Sato]

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung  wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties
 line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

No need for these lines in each localized files, as English bundle contains 
them.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties
 line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

Same here with `de` bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties
 line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

and here.

-

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

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10

[Naoto Sato]

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung  wrote:

> msg drop for jdk19, Mar 9, 2022

IIRC, localized resource files should have the same copyright year as the base 
English one. That's what I was told by the l10n engineer when I had the same 
comment.

-

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

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10

[Naoto Sato]

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung  wrote:

> msg drop for jdk19, Mar 9, 2022

`src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties`

These are part of `jdk.localedata` module. Should be excluded from `java.base` 
module and apply the diffs to 
`src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties`
 manually. (Note that the first half of it is not necessary when merging).

-

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

Re: RFR: JDK-8281082: Improve javadoc references to JOSS

[Naoto Sato]

On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy  wrote:

> The references to JOSS, the Java Object Serialization Specification, are not 
> done consistently in the API javadoc. This should be improved.
> 
> I'll update copyright years before pushing.

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8279918: Fix various doc typos [v2]

[Naoto Sato]

On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo  wrote:

>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, 
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant 
>> formatting artefact and thus can be removed.
>> - `` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Additional typos

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8279918: Fix various doc typos [v2]

[Naoto Sato]

On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo  wrote:

>> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
>> 
>>> 71:  * will be transparent to the BreakIterator. A sequence of 
>>> characters will break the
>>> 72:  * same way it would if any ignore characters it contains are taken 
>>> out. Break
>>> 73:  * positions never occur before ignore characters.
>> 
>> "before ignored characters"
>
> I believe it's the name of a concept, so I will leave it as is:
> 
>> There is one special substitution.  If the description defines a 
>> substitution called "", the expression must be a [] expression, and 
>> the expression defines a set of characters (the "ignore characters") that 
>> will be transparent to the BreakIterator.

Yes, that is correct.

-

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

Re: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes [v2]

[Naoto Sato]

On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov  wrote:

>> StringBuffer is a legacy synchronized class. There are more modern 
>> alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally 
>> have better performance
>> 
>> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I 
>> migrated only usages which were automatically detected by IDEA. It turns out 
>> there are more usages which can be migrated.
>
> Andrey Turbanov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8274879: Replace uses of StringBuffer with StringBuilder within java.base 
> classes
>   revert changes in spec to avoid CSR

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes [v2]

[Naoto Sato]

On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov  wrote:

>> src/java.base/share/classes/java/lang/Character.java line 123:
>> 
>>> 121:  * than U+ are called supplementary characters.  The Java
>>> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
>>> 123:  * in the {@code String} and {@code StringBuilder} classes. In
>> 
>> Not sure simple replacement applies here, as `StringBuffer` still uses 
>> `UTF-16` representation. You may add `StringBuilder` as well here, but I 
>> think you might want to file a CSR to clarify.
>
> reverted changes in this spec.

Did you modify the PR? I am unable to locate the revert.

-

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

Re: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes

[Naoto Sato]

On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov 
 wrote:

> StringBuffer is a legacy synchronized class. There are more modern 
> alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have 
> better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I 
> migrated only usages which were automatically detected by IDEA. It turns out 
> there are more usages which can be migrated.

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

> 121:  * than U+ are called supplementary characters.  The Java
> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
> 123:  * in the {@code String} and {@code StringBuilder} classes. In

Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` 
representation. You may add `StringBuilder` as well here, but I think you might 
want to file a CSR to clarify.

-

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

Re: RFR: 8274835: Remove unnecessary castings in java.base

[Naoto Sato]

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov 
 wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't 
> touch primitive types casts.

Calendar-related changes look good to me.

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Naoto Sato]

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov 
 wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method 
> directly.

java.time changes look good.

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8272805: Avoid looking up standard charsets [v2]

[Naoto Sato]

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov  wrote:

>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>> 
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>> 
>> This could be done more efficiently(up to x20 time faster) with use of 
>> java.nio.charset.StandardCharsets:
>> absolutePath.getBytes(StandardCharsets.UTF_8);
>> 
>> The later variant also makes the code cleaner, as it is known not to throw 
>> UnsupportedEncodingException in contrary to the former variant.
>> 
>> This change includes:
>>  * demo/utils
>>  * jdk.xx packages
>>  * Some places were missed in the previous changes. I have found it by 
>> tracing the calls to the Charset.forName() by executing tier1,2,3 and 
>> desktop tests.
>> 
>> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
>> 
>> Code excluded in this fix: the Xerces library(should be fixed upstream), 
>> J2DBench(should be compatible to 1.4), some code in the network(the change 
>> there are not straightforward, will do it later).
>> 
>> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains 14 additional 
> commits since the last revision:
> 
>  - Update the usage of Files.readAllLines()
>  - Update datatransfer
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Fix related imports
>  - Merge branch 'master' into standard-encodings-in-non-public-modules
>  - Cleanup UnsupportedEncodingException
>  - Update PacketStream.java
>  - Rollback TextTests, should be compatible with jdk1.4
>  - Rollback TextRenderTests, should be compatible with jdk1.4
>  - ... and 4 more: 
> https://git.openjdk.java.net/jdk/compare/c262b06f...e7127644

Looks good.

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

[Naoto Sato]

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

[Naoto Sato]

On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov  wrote:

> This is the continuation of JDK-8233884 and JDK-8271456. This change affects 
> fewer cases so I fix all "java." modules at once.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of 
> java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw 
> UnsupportedEncodingException in contrary to the former variant.
> 
> tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

+1

-

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

Re: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

[Naoto Sato]

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names 
> you like to use.

LGTM.

-

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/152

Re: RFR: 8267110: Update java.util to use instanceof pattern variable

[Naoto Sato]

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon  
wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` 
> package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Classes in the i18n area look good.

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

[Naoto Sato]

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 
> 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. 
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>  The essential change for this JEP, including the `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system 
> property is now "disallow", most of the tests calling 
> `System.setSecurityManager()` need to launched with 
> `-Djava.security.manager=allow`. This is covered in a different PR at 
> https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

-

Marked as reviewed by naoto (Reviewer).

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

Integrated: 8264208: Console charset API

[Naoto Sato]

On Fri, 9 Apr 2021 16:47:55 GMT, Naoto Sato  wrote:

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

This pull request has now been integrated.

Changeset: bebfae48
Author:Naoto Sato 
URL:   https://git.openjdk.java.net/jdk/commit/bebfae48
Stats: 214 lines in 10 files changed: 184 ins; 12 del; 18 mod

8264208: Console charset API

Reviewed-by: joehw, rriggs, alanb

-

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

Re: RFR: 8264208: Console charset API [v12]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Revived charset() in JavaIOAccess interface.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/e585d16f..2d90f8df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=10-11

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

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

Re: RFR: 8264208: Console charset API [v11]

[Naoto Sato]

On Thu, 22 Apr 2021 16:29:35 GMT, Roger Riggs  wrote:

>> Then `charset()` in the shared secret would return `null`. Would that 
>> suffice your case?
>
> I read lines 575-587 as initializing CHARSET regardless of whether the 
> Console was created.

OK, revived the charset() method.

-

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

Re: RFR: 8264208: Console charset API [v11]

[Naoto Sato]

On Thu, 22 Apr 2021 16:03:12 GMT, Roger Riggs  wrote:

>> Would the singleton `Console.cons` be instantiated in your use case? It is 
>> created only when isatty() (or Windows' equivalent) in the native code 
>> returns true.
>
> Not always, for example, if stderr was redirected to a terminal but not stdin 
> and stdout.
> The istty check is only true if both stdin and stdout are ttys.

Then `charset()` in the shared secret would return `null`. Would that suffice 
your case?

-

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

Re: RFR: 8264208: Console charset API [v11]

[Naoto Sato]

On Thu, 22 Apr 2021 15:18:11 GMT, Roger Riggs  wrote:

>> 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 13 additional 
>> commits since the last revision:
>> 
>>  - Refined the test case.
>>  - Merge branch 'master' into JDK-8264208
>>  - Changed shell based test into java based
>>  - Added link to Charset#defaultChaset() in InputStreamReader.
>>  - Modified javadocs per suggestions.
>>  - Added @see links.
>>  - Added Console::charset() relation with System.in
>>  - Added comment to System.out/err init.
>>  - Reflected further review comments.
>>  - Reverted PrintStream changes
>>  - ... and 3 more: 
>> https://git.openjdk.java.net/jdk/compare/51627555...e585d16f
>
> src/java.base/share/classes/java/io/Console.java line 597:
> 
>> 595: return null;
>> 596: }
>> 597: });
> 
> Please keep the charset() method and return CHARSET.
> 
> I'm looking at a use case that needs to know the platform charset regardless 
> of whether the console exists.
> When a process is launched it may be redirected to /dev/tty or a pseudo tty 
> and in that case
> a Reader from that stream should be able to use the encoding of the platform.
> Its still a work in progress, but it would save some refactoring or 
> duplication later.

Would the singleton `Console.cons` be instantiated in your use case? It is 
created only when isatty() (or Windows' equivalent) in the native code returns 
true.

-

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

Re: RFR: 8264208: Console charset API [v11]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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 13 additional commits since the 
last revision:

 - Refined the test case.
 - Merge branch 'master' into JDK-8264208
 - Changed shell based test into java based
 - Added link to Charset#defaultChaset() in InputStreamReader.
 - Modified javadocs per suggestions.
 - Added @see links.
 - Added Console::charset() relation with System.in
 - Added comment to System.out/err init.
 - Reflected further review comments.
 - Reverted PrintStream changes
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/8cc07521...e585d16f

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/238dbb42..e585d16f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=09-10

  Stats: 72701 lines in 1955 files changed: 33448 ins; 34099 del; 5154 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

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

Re: RFR: 8264208: Console charset API [v10]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

 - Changed shell based test into java based
 - Added link to Charset#defaultChaset() in InputStreamReader.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/083f6180..238dbb42

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=08-09

  Stats: 88 lines in 3 files changed: 27 ins; 51 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

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

Re: RFR: 8264208: Console charset API [v9]

[Naoto Sato]

On Fri, 16 Apr 2021 18:15:41 GMT, Roger Riggs  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Modified javadocs per suggestions.
>
> src/java.base/share/classes/java/io/InputStreamReader.java line 48:
> 
>> 46:  *  For top efficiency, consider wrapping an InputStreamReader within 
>> a
>> 47:  * BufferedReader.  For example:
>> 48:  *
> 
> Oddly, none of the reference in this class to the default charset are links 
> to Charset.defaultCharset().
> That would be a useful addition, either in the class javadoc or in the 1-arg 
> constructor that uses the default charset.

Thanks, Roger. Both are good suggestions. Will incorporate them into the next 
iteration.

-

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

Re: RFR: 8264208: Console charset API [v8]

[Naoto Sato]

On Thu, 15 Apr 2021 14:17:11 GMT, Alan Bateman  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Added @see links.
>
> src/java.base/share/classes/java/io/Console.java line 397:
> 
>> 395: /**
>> 396:  * Returns the {@link java.nio.charset.Charset Charset} object used 
>> in
>> 397:  * the {@code Console}.
> 
> What would you think about re-phrasing the first sentence to use "for the 
> Console" rather than "in the Console".

Changed to "for the Console", as well as `@return`.

> src/java.base/share/classes/java/lang/System.java line 123:
> 
>> 121:  *
>> 122:  * @see Console#charset()
>> 123:  * @see Console#reader()
> 
> What would you think about changing the example in InputStreamReader class 
> description as part of this?

Replaced `System.in` with generic `anInputStream`, as changing `new 
InputStreamReader` with `Console.reader()` would defy the purpose of the 
example.

-

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

Re: RFR: 8264208: Console charset API [v9]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Modified javadocs per suggestions.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/5988f600..083f6180

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=07-08

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

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

Re: RFR: 8264208: Console charset API [v8]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Added @see links.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/45ab77b3..5988f600

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=06-07

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

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

Re: RFR: 8264208: Console charset API [v7]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Added Console::charset() relation with System.in

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/9e323145..45ab77b3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=05-06

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

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

Re: RFR: 8264208: Console charset API [v6]

[Naoto Sato]

On Wed, 14 Apr 2021 15:03:19 GMT, Alan Bateman  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Added comment to System.out/err init.
>
> src/java.base/share/classes/java/lang/System.java line 166:
> 
>> 164:  * exists, {@link Charset#defaultCharset()} otherwise.
>> 165:  */
>> 166: public static final PrintStream err = null;
> 
> I still think we need something in System.in to link to Console::charset. If 
> someone creates an InputStreamReader(System.in) then it will use the default 
> charset, they should be using Console::reader for these cases.

Added some explanation to it.

-

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

Re: RFR: 8264208: Console charset API [v4]

[Naoto Sato]

On Tue, 13 Apr 2021 19:30:53 GMT, Joe Wang  wrote:

>> Although the code path is different, the logic to determine the encoding is 
>> not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked 
>> from a terminal (in fact, there's a bug where they aren't set even in a 
>> terminal on unix env, which I fixed in this patch) which is the same 
>> condition in which `System.console()` returns the console. And for both 
>> cases, it will default to `Charset.defaultCharset()` if they are not 
>> available.
>> 
>> Having said that, one regression test started to fail with this 
>> implementation change as follows:
>> 
>> Exception in thread "main" java.util.ServiceConfigurationError: Locale 
>> provider adapter "CLDR"cannot be instantiated.
>>  at 
>> java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199)
>>  at 
>> java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287)
>>  at 
>> java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258)
>>  at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960)
>>  at 
>> java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518)
>>  at java.base/java.util.Scanner.useLocale(Scanner.java:1270)
>>  at java.base/java.util.Scanner.(Scanner.java:543)
>>  at java.base/java.util.Scanner.(Scanner.java:554)
>>  at TestConsole.main(TestConsole.java:54)
>> Caused by: java.lang.reflect.InvocationTargetException
>>  at 
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>  Method)
>>  at 
>> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78)
>>  at 
>> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>  at 
>> java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
>>  at 
>> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
>>  at 
>> java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188)
>>  ... 8 more
>> 
>> I haven't looked at it in detail but it seems that calling 
>> `System.console()` in `System.initPhase1()` is not allowed, as the module 
>> system is not there yet. So I reverted the implementation to the original 
>> and simply retained the description in `System.out/err` with a change to 
>> `determined by` to `equivalent to`.
>
> Thanks for the explanation and updates. It's a worthwhile exercise to attempt 
> to align things around the new method. A short note above line 2023 to record 
> this might be useful as well (sth. like it's eq to console != null ? 
> console.charset() : Charset.defaultCharset();). No need to create another 
> update if you decide to add the note.

Thanks. Added some explanations as suggested.

-

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

Re: RFR: 8264208: Console charset API [v6]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Added comment to System.out/err init.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/cafde56a..9e323145

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=04-05

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

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

Re: RFR: 8264208: Console charset API [v4]

[Naoto Sato]

On Tue, 13 Apr 2021 13:04:17 GMT, Alan Bateman  wrote:

> 1. I think method name "charset()" is too short. It's not called frequently. 
> This method name should explain functionality.

As for this one, I am open for suggestions. I thought `consoel()` was concise, 
and analogous to `Charset.defaultCharset()`.

-

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

Re: RFR: 8264208: Console charset API [v4]

[Naoto Sato]

On Tue, 13 Apr 2021 02:34:15 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Reverted PrintStream changes
>
> src/java.base/share/classes/java/lang/System.java line 2020:
> 
>> 2018: setIn0(new BufferedInputStream(fdIn));
>> 2019: setOut0(newPrintStream(fdOut, cs));
>> 2020: setErr0(newPrintStream(fdErr, cs));
> 
> It was getting from sun.stdout.encoding or sun.stderr.encoding. After the 
> change, when there is no console, it would be set with 
> Charset.defaultCharset(). Would that be an incompatible change?

Although the code path is different, the logic to determine the encoding is not 
changed, as `sun.stdout/err.encoding` are only set if the VM is invoked from a 
terminal (in fact, there's a bug where they aren't set even in a terminal on 
unix env, which I fixed in this patch) which is the same condition in which 
`System.console()` returns the console. And for both cases, it will default to 
`Charset.defaultCharset()` if they are not available.

Having said that, one regression test started to fail with this implementation 
change as follows:

Exception in thread "main" java.util.ServiceConfigurationError: Locale provider 
adapter "CLDR"cannot be instantiated.
at 
java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199)
at 
java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287)
at 
java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258)
at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960)
at 
java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518)
at java.base/java.util.Scanner.useLocale(Scanner.java:1270)
at java.base/java.util.Scanner.(Scanner.java:543)
at java.base/java.util.Scanner.(Scanner.java:554)
at TestConsole.main(TestConsole.java:54)
Caused by: java.lang.reflect.InvocationTargetException
at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
at 
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78)
at 
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at 
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at 
java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188)
... 8 more

I haven't looked at it in detail but it seems that calling `System.console()` 
in `System.initPhase1()` is not allowed, as the module system is not there yet. 
So I reverted the implementation to the original and simply retained the 
description in `System.out/err` with a change to `determined by` to `equivalent 
to`.

-

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

Re: RFR: 8264208: Console charset API [v5]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reflected further review comments.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/68db1a79..cafde56a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=03-04

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

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

Re: RFR: 8264208: Console charset API [v2]

[Naoto Sato]

On Mon, 12 Apr 2021 21:12:08 GMT, Naoto Sato  wrote:

>> src/java.base/share/classes/java/io/Console.java line 397:
>> 
>>> 395: /**
>>> 396:  * Returns the {@link java.nio.charset.Charset Charset} object 
>>> used in
>>> 397:  * this {@code Console}.
>> 
>> The Console is a singleton and the existing methods use "the console" so I 
>> think we should do the same here.
>> 
>> We'll need to add to the description of the System.{in,out,err} fields, I 
>> don't mind if we do it as part of this PR or another issue.
>
> Javadoc updated. Instead of modifying System.out/err (System.in is not 
> affected, as it does not convert b2c), I modified PrintStream javadoc.

Reverted the changes to PrintStream, as it defaults to 
Charset.defaultCharset(). Added descriptions to System.out/err instead (and 
modified the impl).

-

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

Re: RFR: 8264208: Console charset API [v4]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reverted PrintStream changes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/c172d0a1..68db1a79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=02-03

  Stats: 50 lines in 2 files changed: 8 ins; 9 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

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

Re: RFR: 8264208: Console charset API [v2]

[Naoto Sato]

On Sun, 11 Apr 2021 13:44:05 GMT, Alan Bateman  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Reflected the review comments.
>
> src/java.base/share/classes/java/io/Console.java line 397:
> 
>> 395: /**
>> 396:  * Returns the {@link java.nio.charset.Charset Charset} object used 
>> in
>> 397:  * this {@code Console}.
> 
> The Console is a singleton and the existing methods use "the console" so I 
> think we should do the same here.
> 
> We'll need to add to the description of the System.{in,out,err} fields, I 
> don't mind if we do it as part of this PR or another issue.

Javadoc updated. Instead of modifying System.out/err (System.in is not 
affected, as it does not convert b2c), I modified PrintStream javadoc.

-

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

Re: RFR: 8264208: Console charset API [v3]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reflecting the review comments.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/8fd8f6e6..c172d0a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=01-02

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

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

Re: RFR: 8264208: Console charset API [v2]

[Naoto Sato]

> Please review the changes for the subject issue.  This has been suggested in 
> a recent discussion thread for the JEP 400 
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>  A CSR has also been drafted, and comments are welcome 
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

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

  Reflected the review comments.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3419/files
  - new: https://git.openjdk.java.net/jdk/pull/3419/files/d6db04bb..8fd8f6e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3419=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3419=00-01

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

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

Re: RFR: 8264208: Console charset API [v2]

[Naoto Sato]

On Fri, 9 Apr 2021 19:25:02 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Reflected the review comments.
>
> src/java.base/share/classes/java/io/Console.java line 404:
> 
>> 402:  *
>> 403:  * @return A {@code Charset} object used in this {@code Console}.
>> 404:  * @since 17
> 
> A couple of minor comments: 
> May replace {@code Charset} with @link;
> Add "the" to the sentence: The returned charset corresponds to "the" input...
> @return: javadoc guide suggests "do not capitalize and do not end with a 
> period" when writing a phrase. But I guess for consistency in this class, 
> it's okay to capitalize.

Thanks, Joe. Modified as suggested.

-

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

RFR: 8264208: Console charset API

[Naoto Sato]

Please review the changes for the subject issue.  This has been suggested in a 
recent discussion thread for the JEP 400 
[[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
 A CSR has also been drafted, and comments are welcome 
[[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].

-

Commit messages:
 - 8264208: Console charset API

Changes: https://git.openjdk.java.net/jdk/pull/3419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3419=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264208
  Stats: 202 lines in 9 files changed: 174 ins; 17 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3419/head:pull/3419

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

Re: RFR: 8263754: HexFormat 'fromHex' methods should be static

[Naoto Sato]

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs  wrote:

> A number of HexFormat methods converting from strings to numbers do not use 
> delimiter, prefix, suffix, and uppercase parameters and would be more 
> convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings 
> in non-JDK source files.
> 
>public boolean isHexDigit(int);
>public int fromHexDigit(int);
>public int fromHexDigits(java.lang.CharSequence);
>public int fromHexDigits(java.lang.CharSequence, int, int);
>public long fromHexDigitsToLong(java.lang.CharSequence);
>public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Looks good (with the suggestions by Claes).

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8263658: Use the blessed modifier order in java.base

[Naoto Sato]

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt 
 wrote:

> Additional changes found in `java.base` of `final private` -> `private 
> final`. Filed with existing bug because it's the same module; can change to a 
> different bug number if required.

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

[Naoto Sato]

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon  
wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, 
> `java.math`, and `java.text` packages to make use of the `instanceof` pattern 
> variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by naoto (Reviewer).

-

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

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v3]

[Naoto Sato]

On Mon, 18 Jan 2021 05:52:57 GMT, Leo Jiang  wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> Leo Jiang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   fix the missing copyright year for standard.properties

Marked as reviewed by naoto (Reviewer).

-

PR: https://git.openjdk.java.net/jdk16/pull/123

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

[Naoto Sato]

On Fri, 15 Jan 2021 01:59:07 GMT, Leo Jiang  wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
>>  line 518:
>> 
>>> 516: doclet.footer_specified=\
>>> 517: The -footer option is no longer supported and will be ignored.\n\
>>> 518: It may be removed in a future release.
>> 
>> I believe this is to fix no newline at the end (unrelated to l10n changes). 
>> Do we need to change the copyright year for this?
>
> Actually I was correcting the L217, changed {) -> {}. But 2 days ago, 
> Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after 
> running the merge. Looks both of us forgot to update the copyright year. Any 
> suggestion? 
> doclet.help.systemProperties.body=\
> The {0} page lists references to system properties.

I believe your PR still contains the fix to add the newline at the end of the 
file (at L518). So I think you can simply change the copyright year in 
`standard.properties` file.

-

PR: https://git.openjdk.java.net/jdk16/pull/123

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]

[Naoto Sato]

On Thu, 14 Jan 2021 14:27:25 GMT, Leo Jiang  wrote:

>> This is the changes for JDK 16 msg drop 10.
>
> Leo Jiang has updated the pull request with a new target base due to a merge 
> or a rebase. The incremental webrev excludes the unrelated changes brought in 
> by the merge/rebase. The pull request contains two additional commits since 
> the last revision:
> 
>  - Merge branch 'master' into msgdrop
>  - JDK-8259732: JDK 16 L10n resource file update - msg drop 10

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
 line 518:

> 516: doclet.footer_specified=\
> 517: The -footer option is no longer supported and will be ignored.\n\
> 518: It may be removed in a future release.

I believe this is to fix no newline at the end (unrelated to l10n changes). Do 
we need to change the copyright year for this?

-

PR: https://git.openjdk.java.net/jdk16/pull/123

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

[Naoto Sato]

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, 
> `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

>I also think that the person most qualified to judge about charsetmapping is 
>@naotoj, which has already accepted this review as it is.

Although I am the current RE for the charsets component, I succeeded it from 
Alan/Sherman, so I would like to hear Alan's opinion on this.

-

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

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

[Naoto Sato]

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie  wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. 
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by 
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by 
>> make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after 
>> all, "source code" for that module that is "compiler" into resulting 
>> deliverables, for that module. (But the "source code" language is not Java 
>> or C, but typically a highly domain specific language or data format, and 
>> the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. 
>> When such data is changed, most of the time build-dev (or the new build 
>> label) is involved, even though this has nothing to do with the build. While 
>> this is annoying, a worse problem is if the actual team that needs to review 
>> the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [ ] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [ ] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, 
`lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

test/jdk/java/util/Locale/LSRDataTest.java line 57:

> 55: // path to the lsr file from the make folder, this test relies on the
> 56: // relative path to the file in the make folder, considering
> 57: // test and make will always exist in the same jdk layout

The comment refers to the "make" folder. (line 55 as well).

-

Marked as reviewed by naoto (Reviewer).

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

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

[Naoto Sato]

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman  wrote:

>> The mapping and nr tables, and the *-X.java.template files in 
>> make/data/charsetmapping are used to generate source code for the java.base 
>> and jdk.charsets modules. The stdcs-$OS files configure the package and 
>> module that each charset go into. If the tables used to generate the source 
>> files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk 
>> will probably need a new home too.
>
>> @AlanBateman The process of modularization was not fully completed with 
>> Project Jigsaw, and a few ugly warts remained. I was under the impression 
>> that these should be addressed in follow-up fixes, but this was 
>> unfortunately never done. Charsets and cldrconverter were both split between 
>> a core portion in java.base and the rest in jdk.charsets and jdk.localedata, 
>> respectively, but the split was never handled properly, but just "duct 
>> taped" in place.
> 
> This is a complicated area of the build, not really a Project Jigsaw issue. 
> It's complicated because the source code for the charsets is generated at 
> build time and the set of non-standard charsets included in java.base varies 
> by platform, e.g. there's are several IBMxxx charsets in java.base when 
> building on AIX that are not interesting to include in java.base on other 
> platforms. This means we can't split up the mapping tables in 
> make/data/charsetmapping and put them in different directories. If you are 
> moving them into the src tree then src/java.base (as you have it) is best but 
> will still have the ugly wart that some of these mapping tables will be used 
> to generate code for the jdk.charsets module.

> @AlanBateman The process of modularization was not fully completed with 
> Project Jigsaw, and a few ugly warts remained. I was under the impression 
> that these should be addressed in follow-up fixes, but this was unfortunately 
> never done. Charsets and cldrconverter were both split between a core portion 
> in java.base and the rest in jdk.charsets and jdk.localedata, respectively, 
> but the split was never handled properly, but just "duct taped" in place.
> 
> I chose to put the data files used for both java.base and the "additional" 
> modules in java.base, based on the comment that Naoto made in 
> https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:
> 
> > As to charsetmapping and cldrconverter, I believe they can reside in
> > java.base, as jdk.charsets and jdk.localedata modules depend on it.
> 
> Of course it would be preferable to make a proper split, but that requires 
> work done by the component teams to break the modules apart.
> 
> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file 
> is more or less duplicated in 
> make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data 
> set is processed twice, once for java.base and once for jdk.charsets. I don't 
> think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any 
> other place.

I still stand by what I wrote above. It's best to put data in java.base for 
charsets/localedata. Otherwise we would have to duplicate some in each modules 
source directory.

-

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

Re: [11]RFR 8196213: sun/security/tools/jarsigner/warnings/NoTimestampTest.java test fails on ar_SA locale.

[Naoto Sato]

Looks good.

Naoto

On 6/25/18 12:04 AM, Dora Zhou wrote:

Hello,

Please help review the fix for JDK-8196213. Thank you.
Set default locale to en-US so that the output display the date using 
Gregorian Calendar and Latn numbering system(0~9).


Bug: https://bugs.openjdk.java.net/browse/JDK-8196213
Webrev: http://cr.openjdk.java.net/~ljiang/8196213/webrev/ 



Regards,
Dora

Re: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale

[Naoto Sato]

Looks good.

Naoto

On 6/25/18 12:37 AM, Dora Zhou wrote:

Hi Naoto,

Thanks a lot for the review.
I have made suggested changes, Kindly have a look at: 
http://cr.openjdk.java.net/~ljiang/8194152/webrev.01/ 



Regards,
Dora


From: naoto.s...@oracle.com
To: dan.z.z...@oracle.com, i18n-...@openjdk.java.net, 
core-libs-...@openjdk.java.net, security-dev@openjdk.java.net
Sent: Saturday, June 23, 2018 1:23:50 AM GMT +08:00 Beijing / 
Chongqing / Hong Kong / Urumqi
Subject: Re:  [11]RFR 8194152: 
sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale


Hi Dora,

You could move those two lines that sets the locale to en-US before the
for-loop, so that if "args" contains -J-Duser.language/country then it
can override the default en-US.

The JIRA issue needs noreg-self label.

Naoto

On 6/22/18 1:26 AM, Dora Zhou wrote:

Hello,

Please help review the fix for JDK-8194152. Thank you.

The test compares output with expected error messages in English, set
locale to en-US so that the output are not translated into other 
languages.


Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/


Regards,
Dora

Re: [11]RFR 8194152: sun/security/tools/jarsigner/AltProvider.java failed on de-DE locale

[naoto . sato]

Hi Dora,

You could move those two lines that sets the locale to en-US before the 
for-loop, so that if "args" contains -J-Duser.language/country then it 
can override the default en-US.


The JIRA issue needs noreg-self label.

Naoto

On 6/22/18 1:26 AM, Dora Zhou wrote:

Hello,

Please help review the fix for JDK-8194152. Thank you.

The test compares output with expected error messages in English, set 
locale to en-US so that the output are not translated into other languages.


Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
Webrev: http://cr.openjdk.java.net/~ljiang/8194152/webrev/ 



Regards,
Dora

Re: -Djava.security.manager=problems for service provider

[Naoto Sato]

Hi Peter/Sean,

It does seem a regression. Thanks for letting me know. I will file an 
issue and work on it.


Naoto

On 3/29/18 10:30 AM, Sean Mullan wrote:

Copying Naoto.

Naoto, the regression mentioned below that is causing the NPE looks to 
be caused by changes to java.util.ResourceBundle in 
https://bugs.openjdk.java.net/browse/JDK-8182601


Can you take a look and file a bug, if so?

Thanks,
Sean

On 3/29/18 4:53 AM, Peter wrote:

Hello Java security people!

It turns out we needed the -Djava.security.manager= option at startup 
after all...


According to our SecurityManager implementation notes, the reason it 
instantiated the policy, was to ensure that the JVM had loaded all 
necessary classes, to prevent recursive errors.  So I worked out we 
didn't actually need an instance of the policy, but instead, just make 
sure it's class is loaded along with other important classes, before 
the security manager is in force.   I've also handed off the logging 
in the policy to an executor...


So I've removed the instantation of policy provider from our security 
manager's constructor.


I've actually got a permission check in the constructor of the 
security manager, if the AccessControlContext is privileged or if an 
AccessControlContext containing ProtectionDomains are privileged, the 
policy is never consulted.  And so, the policy is not consulted or 
instantiated during the security managers construction as you can see 
below.


I have a new problem:

To state it simply, if you have a custom SecurityManager, you cannot 
use the built in sun.security.provider.PolicyFile because the class 
RBClassLoader cannot be initialized, due to a NullPointerException in 
it's static initializer:


[java] Caused by: java.lang.NullPointerException
  [java] at 
java.util.ResourceBundle$RBClassLoader.(ResourceBundle.java:502)


Which is just a null pointer dereference in RBClassLoaders static 
initializer block:


static {
 // Find the extension class loader.
 ClassLoader ld = ClassLoader.getSystemClassLoader();
 ClassLoader parent;
 while ((parent = ld.getParent()) != null) {
 ld = parent;
 }
 loader = ld;
 }

It should be:

static {
 // Find the extension class loader.
 ClassLoader ld = ClassLoader.getSystemClassLoader();
 ClassLoader parent;
 while (ld != null) {
 parent = ld.getParent();
 if (parent == null) break;
 ld = parent;
 }
 loader = ld;
 }

  [java] Error occurred during initialization of VM
  [java] java.lang.ExceptionInInitializerError
  [java] at 
java.util.ResourceBundle.getLoader(ResourceBundle.java:482)
  [java] at 
java.util.ResourceBundle.getBundle(ResourceBundle.java:783)
  [java] at 
sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:47)
  [java] at 
sun.security.util.ResourcesMgr$1.run(ResourcesMgr.java:44)
  [java] at java.security.AccessController.doPrivileged(Native 
Method)
  [java] at 
sun.security.util.ResourcesMgr.getString(ResourcesMgr.java:43)
  [java] at 
sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:888)
  [java] at 
sun.security.provider.PolicyFile.init(PolicyFile.java:626)
  [java] at 
sun.security.provider.PolicyFile.access$400(PolicyFile.java:258)
  [java] at 
sun.security.provider.PolicyFile$3.run(PolicyFile.java:521)
  [java] at 
sun.security.provider.PolicyFile$3.run(PolicyFile.java:495)
  [java] at java.security.AccessController.doPrivileged(Native 
Method)
  [java] at 
sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495)
  [java] at 
sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480)
  [java] at 
sun.security.provider.PolicyFile.init(PolicyFile.java:439)
  [java] at 
sun.security.provider.PolicyFile.(PolicyFile.java:297)
  [java] at 
java.security.Policy.getPolicyNoCheck(Policy.java:196)
  [java] at 
java.security.ProtectionDomain.implies(ProtectionDomain.java:285)

  [java] at java.lang.System$1.run(System.java:316)
  [java] Unexpected exception:
  [java] java.io.IOException: The pipe is being closed
  [java] at java.io.FileOutputStream.writeBytes(Native Method)
  [java] at 
java.io.FileOutputStream.write(FileOutputStream.java:326)
  [java] at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
  [java] at 
java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
  [java] at 
java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877) 

  [java] at 
java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1786) 

  [java] at 

hg: jdk8/tl/jdk: 8028368: There is no description whether or not java.util.ResourceBundle is thread-safe

[naoto . sato]

Changeset: 5b5ee2288306
Author:naoto
Date:  2013-12-02 11:29 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b5ee2288306

8028368: There is no description whether or not java.util.ResourceBundle is 
thread-safe
Reviewed-by: okutsu

! src/share/classes/java/util/ListResourceBundle.java
! src/share/classes/java/util/PropertyResourceBundle.java
! src/share/classes/java/util/ResourceBundle.java

hg: jdk8/tl/jdk: 8016110: Japanese char (MS932) 0x5C cannot be used as an argument when quoted

[naoto . sato]

Changeset: b4c259743371
Author:naoto
Date:  2013-09-30 16:15 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4c259743371

8016110: Japanese char (MS932) 0x5C cannot be used as an argument when quoted
Reviewed-by: ksrini, akhil

! src/windows/bin/cmdtoargs.c
+ test/tools/launcher/I18NArgTest.java

hg: jdk8/tl/jdk: 8024332: sun/util/resources/en split between rt.jar and localedata.jar

[naoto . sato]

Changeset: 7bfe3da4fad6
Author:naoto
Date:  2013-09-11 05:38 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bfe3da4fad6

8024332: sun/util/resources/en split between rt.jar and localedata.jar
Reviewed-by: alanb, erikj

! make/java/java/genlocales.gmk
! make/java/java/localegen.sh
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/java/util/FILES_properties.gmk
! make/sun/text/FILES_java.gmk
! make/sun/text/FILES_properties.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! 
src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template

hg: jdk8/tl/jdk: 6609431: (rb) ResourceBundle.getString() returns incorrect value

[naoto . sato]

Changeset: e34e3ddb3cd8
Author:naoto
Date:  2013-06-27 14:40 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e34e3ddb3cd8

6609431: (rb) ResourceBundle.getString() returns incorrect value
Reviewed-by: okutsu, sherman

! src/share/classes/java/util/Properties.java
+ test/java/util/Properties/Bug6609431.java
+ test/java/util/Properties/Bug6609431.properties

hg: jdk8/tl/jdk: 8017468: typo in javadoc: ResourceBunlde

[naoto . sato]

Changeset: bb2e67628dc0
Author:naoto
Date:  2013-06-24 16:21 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2e67628dc0

8017468: typo in javadoc:  ResourceBunlde 
Reviewed-by: okutsu

! src/share/classes/java/util/spi/LocaleServiceProvider.java

hg: jdk8/tl/jdk: 6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect

[naoto . sato]

Changeset: 8b84d557570c
Author:naoto
Date:  2013-06-21 13:42 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b84d557570c

6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect
Reviewed-by: alanb

! test/java/util/Currency/PropertiesTest.sh
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

hg: jdk8/tl/jdk: 8015960: java/util/Locale/LocaleProviders.java failing again on Windows

[naoto . sato]

Changeset: cadb0ef6e931
Author:naoto
Date:  2013-06-11 11:18 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cadb0ef6e931

8015960: java/util/Locale/LocaleProviders.java failing again on Windows
Reviewed-by: alanb

! test/java/util/Locale/LocaleProviders.java

hg: jdk8/tl/jdk: 8013903: Japanese calendar field names are not displayed with -Djava.locale.providers=HOST on Windows

[naoto . sato]

Changeset: 379e1bcae693
Author:naoto
Date:  2013-06-04 10:33 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/379e1bcae693

8013903: Japanese calendar field names are not displayed with 
-Djava.locale.providers=HOST on Windows
Reviewed-by: okutsu

! src/share/classes/java/util/spi/LocaleServiceProvider.java
! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! 
src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

hg: jdk8/tl/jdk: 6251788: (rb) PropertyResourceBundle doesn't document exceptions

[naoto . sato]

Changeset: b99d56d1aa3f
Author:naoto
Date:  2013-05-28 14:02 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b99d56d1aa3f

6251788: (rb) PropertyResourceBundle doesn't document exceptions
Reviewed-by: okutsu

! src/share/classes/java/util/PropertyResourceBundle.java

hg: jdk8/tl/jdk: 7056126: DateFormatSymbols documentation has incorrect description about DateFormat; ...

[naoto . sato]

Changeset: 50fde3eeb48c
Author:naoto
Date:  2013-05-22 16:43 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50fde3eeb48c

7056126: DateFormatSymbols documentation has incorrect description about 
DateFormat
7083668: Sample code in ListResourceBundle is still not correct
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/util/ListResourceBundle.java

hg: jdk8/tl/jdk: 8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied

[naoto . sato]

Changeset: e30396e22c6f
Author:naoto
Date:  2013-05-07 11:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e30396e22c6f

8013086: NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

hg: jdk8/tl/jdk: 8010666: Implement Currency/LocaleNameProvider in Windows Host LocaleProviderAdapter

[naoto . sato]

Changeset: 62fb9e2b5da1
Author:naoto
Date:  2013-04-22 13:37 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62fb9e2b5da1

8010666: Implement Currency/LocaleNameProvider in Windows Host 
LocaleProviderAdapter
Reviewed-by: okutsu

! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! 
src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh

hg: jdk8/tl/jdk: 7091601: Arabic Locale: can not set type of digit in application level

[naoto . sato]

Changeset: 9a6ef3391f32
Author:naoto
Date:  2013-04-03 10:32 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a6ef3391f32

7091601: Arabic Locale: can not set type of digit in application level
Reviewed-by: okutsu

! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! 
src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

hg: jdk8/tl/jdk: 8008576: Calendar mismatch using Host LocaleProviderAdapter

[naoto . sato]

Changeset: d79503c4c56f
Author:naoto
Date:  2013-03-14 11:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d79503c4c56f

8008576: Calendar mismatch using Host LocaleProviderAdapter
Reviewed-by: okutsu

! make/java/java/FILES_java.gmk
! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/sun/util/locale/LanguageTag.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/CalendarProviderImpl.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
+ src/share/classes/sun/util/spi/CalendarProvider.java
! 
src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c

hg: jdk8/tl/jdk: 8004240: Return value from getAdapterPrefence() can be modified

[naoto . sato]

Changeset: 1a2e59d19d3e
Author:naoto
Date:  2013-03-04 20:46 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a2e59d19d3e

8004240: Return value from getAdapterPrefence() can be modified
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
+ test/java/util/Locale/Bug8004240.java

hg: jdk8/tl/jdk: 7092447: Clarify the default locale used in each locale sensitive operation

[naoto . sato]

Changeset: af396ec087f4
Author:naoto
Date:  2013-02-19 10:34 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af396ec087f4

7092447: Clarify the default locale used in each locale sensitive operation
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/time/format/DateTimeFormatSymbols.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/Scanner.java

hg: jdk8/tl/jdk: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono

[naoto . sato]

Changeset: 79d7595abe95
Author:naoto
Date:  2013-02-08 09:35 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79d7595abe95

8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() 
with JapaneseChrono
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
+ test/java/util/Calendar/Bug8007038.java

hg: jdk8/tl/jdk: 7162007: Clean up i18n related caches

[naoto . sato]

Changeset: 1d7a6adf499f
Author:naoto
Date:  2013-01-14 11:09 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d7a6adf499f

7162007: Clean up i18n related caches
Reviewed-by: okutsu, ohair

! make/java/java/FILES_java.gmk
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java
! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java
! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
+ src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java
! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java
! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java
! test/java/util/PluggableLocale/BreakIteratorProviderTest.java
! test/java/util/PluggableLocale/CollatorProviderTest.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/DateFormatProviderTest.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/LocaleNameProviderTest.java
! test/java/util/PluggableLocale/NumberFormatProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java

hg: jdk8/tl/jdk: 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments

[naoto . sato]

Changeset: c622df692bfb
Author:bchristi
Date:  2013-01-10 10:21 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c622df692bfb

8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain 
environments
Summary: Test script now sets LC_ALL, other small changes, relocate test
Reviewed-by: naoto, alanb

+ test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
+ test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
- test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java
- test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh

hg: jdk8/tl/jdk: 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx]

[naoto . sato]

Changeset: dbc692ea3f0a
Author:bchristi
Date:  2013-01-07 13:19 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dbc692ea3f0a

8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx]
Summary: Hard-code sun.jnu.encoding to UTF-8 on Mac
Reviewed-by: naoto

! src/share/native/java/lang/System.c
! src/solaris/native/java/lang/java_props_md.c
+ test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java
+ test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh

hg: jdk8/tl/jdk: 7199750: Loading sequence of service provider is changed

[naoto . sato]

Changeset: 64a42798ea5e
Author:naoto
Date:  2012-11-15 20:17 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64a42798ea5e

7199750: Loading sequence of service provider is changed
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh
! test/java/util/PluggableLocale/barprovider.jar
! test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java

hg: jdk8/tl/jdk: 8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but there is no SPI implementation; ...

[naoto . sato]

Changeset: cc325832469c
Author:naoto
Date:  2012-11-07 15:08 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc325832469c

8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but 
there is no SPI implementation
8001562: Collator.getAvailableLocales() doesn't return all locales for which 
localized instances are available
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
+ test/java/util/Locale/Bug8001562.java
! test/java/util/PluggableLocale/BreakIteratorProviderTest.java
! test/java/util/PluggableLocale/CollatorProviderTest.java
! test/java/util/PluggableLocale/DateFormatProviderTest.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/NumberFormatProviderTest.java

hg: jdk8/tl/jdk: 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format()

[naoto . sato]

Changeset: 6420fcd61c10
Author:naoto
Date:  2012-11-01 13:28 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6420fcd61c10

8001440: CLDR adapter: Invalid number extension in language tag causes 
exception in NumberFormat.format()
Reviewed-by: okutsu

! src/share/classes/java/text/DecimalFormatSymbols.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh