Integrated: 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

2022-06-13 Thread Naoto Sato
On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato  wrote:

> Backing out a fix that is causing a T1 failure.
> 
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

This pull request has now been integrated.

Changeset: fbe92666
Author:    Naoto Sato 
URL:   
https://git.openjdk.org/jdk/commit/fbe926662287283c579fdb4ca8290670500cf5a5
Stats: 95 lines in 2 files changed: 1 ins; 91 del; 3 mod

8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ 
env variable

Reviewed-by: dholmes

-

PR: https://git.openjdk.org/jdk/pull/9151


RFR: 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

2022-06-13 Thread Naoto Sato
Backing out a fix that is causing a T1 failure.

This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

-

Commit messages:
 - 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ 
env variable

Changes: https://git.openjdk.org/jdk/pull/9151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9151=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288378
  Stats: 95 lines in 2 files changed: 1 ins; 91 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9151.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9151/head:pull/9151

PR: https://git.openjdk.org/jdk/pull/9151


RFR: 8287868: Localized names update in COMPAT locale provider

2022-06-10 Thread Naoto Sato
As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's 
locale data (before CLDR).  This is useful for legacy applications, but some of 
its data got obsolete for later locale data updates, such as the country name 
change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those 
names up-to-date from CLDR. More specifically, changes are made for `language`, 
`country`, `script` display names in `Locale` class, and `Currency` display 
names. Localized names used for `TimeZone`s and `Currency` symbols (such as 
`$`) are not modified so that `format`/`parse` should work as with JDK8.

-

Commit messages:
 - 8287868: Localized names update in COMPAT locale provider

Changes: https://git.openjdk.org/jdk/pull/9134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9134=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287868
  Stats: 9930 lines in 65 files changed: 17 ins; 7 del; 9906 mod
  Patch: https://git.openjdk.org/jdk/pull/9134.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9134/head:pull/9134

PR: https://git.openjdk.org/jdk/pull/9134


Re: RFR: 8285838: DST not applying properly with zone id offset set with TZ env variable [v7]

2022-06-09 Thread Naoto Sato
On Tue, 7 Jun 2022 14:15:55 GMT, Gaurav Chaudhari  wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an 
>> attempt is made to find the GMT offset in order to get the current time, 
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285838: Simplified Daylight period checks for test.

Looks good. Thanks for the contribution.

-

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8661


Re: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows

2022-06-09 Thread Naoto Sato
On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie  wrote:

> The test  
> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` 
> verifies different failure modes of resource bundles. One of the failures is 
> that the runner class, `MissingResourceCauseTestRun.java`, creates a file 
> `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the 
> test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is 
> removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a 
> no-op, so the file is not made unreadable, and hence the test fails. In my 
> personal cygwin test environment, the chmod command does have some effect, 
> but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in 
> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original 
> shell script code explicitly excluded Windows from testing. This was changed 
> in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. 
> Apparently the test passes on the current Cygwin setup on GHA. I have failed 
> to reproduce the working conditions that makes a file actually unreadable for 
> the owner on Windows, neither on my GHA test repo, nor locally. I've searched 
> the web to figure out how to properly set file permissions on Windows to make 
> the file unreadable, using Windows native tools, to no avail. I've even asked 
> a [Stack Overflow 
> question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows);
>  which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to 
> work properly, I suggest we instead skip the unreadable test on Windows. It 
> is clearly unstable and highly depending on the Windows environment, the test 
> was never originally supported or intended for Windows, and at the of the 
> day, testing file unreadability is not an important regression test for 
> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Marked as reviewed by naoto (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9061


Re: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows

2022-06-09 Thread Naoto Sato
On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato  wrote:

>> The test  
>> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` 
>> verifies different failure modes of resource bundles. One of the failures is 
>> that the runner class, `MissingResourceCauseTestRun.java`, creates a file 
>> `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the 
>> test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file 
>> is removed.
>> 
>> This does not work reliably on Windows. On msys2, `chmod` is essentially a 
>> no-op, so the file is not made unreadable, and hence the test fails. In my 
>> personal cygwin test environment, the chmod command does have some effect, 
>> but it is still not enough to make the file unreadable, and so the test 
>> fails.
>> 
>> The test was originally a shell script test that got converted to Java in 
>> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original 
>> shell script code explicitly excluded Windows from testing. This was changed 
>> in the rewrite, for reasons I cannot determine.
>> 
>> What suprises me, though, is the "how can this ever has worked???" factor. 
>> Apparently the test passes on the current Cygwin setup on GHA. I have failed 
>> to reproduce the working conditions that makes a file actually unreadable 
>> for the owner on Windows, neither on my GHA test repo, nor locally. I've 
>> searched the web to figure out how to properly set file permissions on 
>> Windows to make the file unreadable, using Windows native tools, to no 
>> avail. I've even asked a [Stack Overflow 
>> question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows);
>>  which as of yet is still unanswered.
>> 
>> Since I feel I've spent far more time than reasonable trying to get this to 
>> work properly, I suggest we instead skip the unreadable test on Windows. It 
>> is clearly unstable and highly depending on the Windows environment, the 
>> test was never originally supported or intended for Windows, and at the of 
>> the day, testing file unreadability is not an important regression test for 
>> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).
>
> Thanks for the investigation, Magnus. I believe it is a bug to include the 
> Windows environment in refactoring the shell script to Java. Why it's been 
> working? No idea. Could be `IOException` has been thrown not by `unreadable` 
> but for some other reason?

> @naotoj Yes, that could be a likely possibility. Perhaps the file were never 
> created, or not in the expected place?

I'd guess something like that too. Anyways, eliminating this unreliability in 
test is a good clean up. Approving the fix assuming Jai's comment is addressed.

-

PR: https://git.openjdk.org/jdk/pull/9061


Re: RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows

2022-06-08 Thread Naoto Sato
On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie  wrote:

> The test  
> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` 
> verifies different failure modes of resource bundles. One of the failures is 
> that the runner class, `MissingResourceCauseTestRun.java`, creates a file 
> `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the 
> test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is 
> removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a 
> no-op, so the file is not made unreadable, and hence the test fails. In my 
> personal cygwin test environment, the chmod command does have some effect, 
> but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in 
> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original 
> shell script code explicitly excluded Windows from testing. This was changed 
> in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. 
> Apparently the test passes on the current Cygwin setup on GHA. I have failed 
> to reproduce the working conditions that makes a file actually unreadable for 
> the owner on Windows, neither on my GHA test repo, nor locally. I've searched 
> the web to figure out how to properly set file permissions on Windows to make 
> the file unreadable, using Windows native tools, to no avail. I've even asked 
> a [Stack Overflow 
> question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows);
>  which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to 
> work properly, I suggest we instead skip the unreadable test on Windows. It 
> is clearly unstable and highly depending on the Windows environment, the test 
> was never originally supported or intended for Windows, and at the of the 
> day, testing file unreadability is not an important regression test for 
> [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Thanks for the investigation, Magnus. I believe it is a bug to include the 
Windows environment in refactoring the shell script to Java. Why it's been 
working? No idea. Could be `IOException` has been thrown not by `unreadable` 
but for some other reason?

-

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


Integrated: 8287541: Files.writeString fails to throw IOException for charset "windows-1252"

2022-06-08 Thread Naoto Sato
On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato  wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces 
> unmappable characters with replacements if the encoder is an `ArrayEncoder`. 
> Changed only to do so if `doReplace` is `true` in 
> `String.encodeWithEncoder()`.

This pull request has now been integrated.

Changeset: 6fb84e2c
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/6fb84e2c9119bdb9c66dd49422bcab637bbd4008
Stats: 22 lines in 2 files changed: 4 ins; 11 del; 7 mod

8287541: Files.writeString fails to throw IOException for charset "windows-1252"

Reviewed-by: iris, bpb, alanb, jpai, lancea, aturbanov

-

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


Re: RFR: 8287896: PropertiesTest.sh fail on msys2

2022-06-07 Thread Naoto Sato
On Tue, 7 Jun 2022 10:14:47 GMT, Magnus Ihse Bursie  wrote:

> The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, 
> since it does not properly detect this environment.

Looks good. Thanks for the change.

-

Marked as reviewed by naoto (Reviewer).

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


Re: RFR: 8285081: Improve XPath operators count accuracy [v3]

2022-06-06 Thread Naoto Sato
On Fri, 3 Jun 2022 23:56:31 GMT, Joe Wang  wrote:

>> Adjust how XPath operators are counted to improve accuracy. This change does 
>> not affect how XPath works. 
>> 
>> Test:  
>>  Tier2 passed;
>>  JCK XML tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   remove unused parameter

LGTM

-

Marked as reviewed by naoto (Reviewer).

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


Re: RFR: 8287860: Revise usage of volatile in j.u.Locale [v2]

2022-06-06 Thread Naoto Sato
On Mon, 6 Jun 2022 14:36:03 GMT, Сергей Цыпанов  wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be 
>> volatile, even in case of race in the worst case it is recalculated at most 
>> once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8287860: Mark hash fields with @Stable

src/java.base/share/classes/java/util/Locale.java line 1084:

> 1082: Properties props = GetPropertyAction.privilegedGetProperties();
> 1083: 
> 1084: Locale defaultLocale = Locale.defaultLocale;

I'd use a different local variable name so that it won't clash with the field 
name. The same holds for other locations (`isoLanguages` and `languageTag`)

-

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


Re: RFR: 8287860: Revise usage of volatile in j.u.Locale [v3]

2022-06-06 Thread Naoto Sato
On Mon, 6 Jun 2022 20:19:22 GMT, Сергей Цыпанов  wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be 
>> volatile, even in case of race in the worst case it is recalculated at most 
>> once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8287860: Rename local vars

Looks good. Thanks for fixing this.

-

Marked as reviewed by naoto (Reviewer).

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


Re: RFR: 8287541: Files.writeString fails to throw IOException for charset "windows-1252" [v2]

2022-06-06 Thread Naoto Sato
On Sat, 4 Jun 2022 11:27:00 GMT, Andrey Turbanov  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Changed per suggestion
>
> src/java.base/share/classes/java/lang/String.java line 849:
> 
>> 847: int en = scale(len, ce.maxBytesPerChar());
>> 848: // fastpath with ArrayEncoder implies `doReplace`.
>> 849: if (ce instanceof ArrayEncoder ae && doReplace) {
> 
> Wouldn't it be more readable (and perphaps faster) if we do check boolean 
> flag first?

Fixed.

-

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


Re: RFR: 8287541: Files.writeString fails to throw IOException for charset "windows-1252" [v2]

2022-06-06 Thread Naoto Sato
> The code path calls `String.getBytesNoRepl()`, but it blindly replaces 
> unmappable characters with replacements if the encoder is an `ArrayEncoder`. 
> Changed only to do so if `doReplace` is `true` in 
> `String.encodeWithEncoder()`.

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

  Changed per suggestion

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9019/files
  - new: https://git.openjdk.java.net/jdk/pull/9019/files/72d27809..51ce3615

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

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

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


Re: RFR: 8285081: Improve XPath operators count accuracy

2022-06-03 Thread Naoto Sato
On Fri, 3 Jun 2022 18:17:55 GMT, Joe Wang  wrote:

> Adjust how XPath operators are counted to improve accuracy. This change does 
> not affect how XPath works. 
> 
> Test:  
>  Tier2 passed;
>  JCK XML tests passed.

src/java.xml/share/classes/com/sun/java_cup/internal/runtime/lr_parser.java 
line 152:

> 150: private int opCount = 0;
> 151: private int totalOpCount = 0;
> 152: private int lastSym;

`lastSym` is never initialized. It's OK for the first time, but should this be 
reset for the next use (if any), e.g. somewhere around line 595?

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java
 line 99:

> 97:   public static final int[] OPERATORS = {GT, GE, EQ, NE, LT, LE, SLASH, 
> DSLASH,
> 98:   DOT, DDOT, ATSIGN, DCOLON, PLUS, MINUS, STAR, DIV, MOD, AND, OR, 
> LPAREN,
> 99:   LBRACK, VBAR, DOLLAR, NODE, TEXT, PI, PIPARAM};

Any reason for re-shuffling the order of operators? I'd expect new ones are 
appended to the existing ones, or appear in the order of their declarations 
above?
(or is this automatically generated, as described in the comment?)

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java
 line 351:

> 349: {
> 350:   nesting++;
> 351:   if (!isLiteral) {

`if (isLiteral) {` might be more readable.

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java
 line 377:

> 375: else if ((Token.LPAREN != c) && (Token.LBRACK != c) && 
> (Token.RPAREN != c)
> 376: && (Token.RBRACK != c) && (Token.COLON != c) && 
> (Token.COMMA != c)) {
> 377: if (Token.STAR == c) {

Could be 

if (Token.STAR != c || !isAxis) {
incrementCount(c);
}

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java
 line 476:

> 474:   }
> 475: 
> 476:   private void incrementCount(char c) {

`c` is not used.

-

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


RFR: 8287541: Files.writeString fails to throw IOException for charset "windows-1252"

2022-06-03 Thread Naoto Sato
The code path calls `String.getBytesNoRepl()`, but it blindly replaces 
unmappable characters with replacements if the encoder is an `ArrayEncoder`. 
Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

-

Commit messages:
 - 8287541: Files.writeString fails to throw IOException for charset 
"windows-1252"

Changes: https://git.openjdk.java.net/jdk/pull/9019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9019=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287541
  Stats: 22 lines in 2 files changed: 4 ins; 11 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9019/head:pull/9019

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


Integrated: 8287340: Refactor old code using StringTokenizer in locale related code

2022-06-02 Thread Naoto Sato
On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato  wrote:

> Refactoring some old code in locale providers. The test case data have also 
> been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not 
> handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` 
> and falls back, so comparing locales using language tags does not work for 
> those locales. Changed to compare with `Locale.toString()` instead.

This pull request has now been integrated.

Changeset: 26d24263
Author:Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/26d24263c7db6d8f722afefc975b03cb575fa6ee
Stats: 177 lines in 4 files changed: 6 ins; 62 del; 109 mod

8287340: Refactor old code using StringTokenizer in locale related code

Reviewed-by: iris, joehw

-

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


Re: RFR: 8285838: DST not applying properly with zone id offset set with TZ env variable [v6]

2022-06-02 Thread Naoto Sato
On Thu, 2 Jun 2022 18:14:55 GMT, Gaurav Chaudhari  wrote:

> Is the suggestion here to substitute the setting of the TZ environment 
> variable, and simply getting a date based off this `SimpleTimeZone` , so as 
> to bypass the process creation and just have it as a more simpler test?

No. The test process still has to be spawned with the TZ env variable set. The 
suggested piece is supposed to replace the following `if` in `runTZTest()` 
method:

Calendar calendar = Calendar.getInstance();
Date time = calendar.getTime();
// Add 1 since getMonth() starts from 0.
int month = time.getMonth() + 1;
ZonedDateTime date = ZonedDateTime.ofInstant(time.toInstant(), 
ZoneId.systemDefault());
if ((month > Month.MARCH.getValue() && month < 
Month.OCTOBER.getValue()) ||
(month == Month.MARCH.getValue() && 
date.isAfter(getLastSundayOfMonth(date))) ||
(month == Month.OCTOBER.getValue() && 
date.isBefore(getLastSundayOfMonth(date {

-

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


Re: RFR: 8285838: DST not applying properly with zone id offset set with TZ env variable [v6]

2022-06-02 Thread Naoto Sato
On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari  wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an 
>> attempt is made to find the GMT offset in order to get the current time, 
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

I tried several runs of CI tests and found no failures. Sorry for the false 
alarm. BTW, now I've looked the test more closely, the test can be simplified 
by using `SimpleTimeZone`, such as:

 new SimpleTimeZone(360, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 
0, Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(new Date())

This piece will check the current date is in DST, emulating 
`TZ=MEZ-1MESZ,M3.5.0,M10.5.0`

-

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


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

2022-06-01 Thread 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: 8285838: DST not applying properly with zone id offset set with TZ env variable [v6]

2022-06-01 Thread Naoto Sato
On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari  wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an 
>> attempt is made to find the GMT offset in order to get the current time, 
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

The machine has `/etc/localtime` pointing to `/usr/share/zoneinfo/GMT`, thus 
the system zone is `GMT`. However, for some reason, I cannot reproduce it on 
that machine any longer. Could be some inconsistency in my repo. Will test in 
our CI system and let you know the result later.

-

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


Re: RFR: 8287340: Refactor old code using StringTokenizer in locale related code [v2]

2022-06-01 Thread Naoto Sato
On Wed, 1 Jun 2022 04:10:03 GMT, ExE Boss  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Removed unnecessary clone() call
>
> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 
> 181:
> 
>> 179: .toArray(Locale[]::new);
>> 180: }
>> 181: return AVAILABLE_LOCALES;
> 
> This should probably clone the cached array:
> Suggestion:
> 
> return AVAILABLE_LOCALES.clone();
> 
> 
> Matching what `JRELocaleProviderAdapter` does[^1], since there’s no guarantee 
> that the result of `getAvailableLocales()` won’t be mutated.
> 
> [^1]: 
> https://github.com/openjdk/jdk/blob/6b1169e266b9d21864f886ef574dd64116fa2cb0/src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java#L430-L439

Thanks for your comments. In fact, `clone()` in `JRELocaleProviderAdapter` is 
not necessary, as it will be subsumed into `Locale.getAvailableLocales()` and 
other `getAvailableLocales()` methods in locale sensitives services (such as 
`DateFormat`) where they are defensively cloned. Removed this `clone()` 
invocation.

-

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


Re: RFR: 8287340: Refactor old code using StringTokenizer in locale related code [v2]

2022-06-01 Thread Naoto Sato
> Refactoring some old code in locale providers. The test case data have also 
> been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not 
> handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` 
> and falls back, so comparing locales using language tags does not work for 
> those locales. Changed to compare with `Locale.toString()` instead.

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

  Removed unnecessary clone() call

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8960/files
  - new: https://git.openjdk.java.net/jdk/pull/8960/files/6b1169e2..d1b00f10

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

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

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


Re: RFR: 8285838: DST not applying properly with zone id offset set with TZ env variable [v5]

2022-05-31 Thread Naoto Sato
On Tue, 31 May 2022 20:10:44 GMT, Gaurav Chaudhari  
wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an 
>> attempt is made to find the GMT offset in order to get the current time, 
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285838: Corrected month comparison check for TZ DST

I tried out your patch on my local Linux machine, but the new test failed with 
the following exception:

ACTION: main -- Failed. Execution failed: `main' threw exception: 
java.lang.RuntimeException: Expected to get exit value of [0]
REASON: User specified action: run main/othervm CustomTzIDCheckDST 
TIME:   1.564 seconds
messages:
command: main CustomTzIDCheckDST
reason: User specified action: run main/othervm CustomTzIDCheckDST 
Mode: othervm [/othervm specified]
elapsed time (seconds): 1.564
configuration:
STDOUT:
Command line: 
[/home/nsato/projects/jdk/git/jdk/build/linux-x64/images/jdk/bin/java -cp 
/home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/java/util/TimeZone/CustomTzIDCheckDST.d:/home/nsato/projects/jdk/git/jdk/open/test/jdk/java/util/TimeZone:/home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/test/lib:/home/nsato/projects/jdk/git/jdk/open/test/lib:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/javatest.jar:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/jtreg.jar
 CustomTzIDCheckDST runTZTest ]
[2022-05-31T22:27:05.958567816Z] Gathering output for process 14771
[2022-05-31T22:27:06.635595481Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.635976964Z] Waiting for completion finished for process 
14771
Output and diagnostic info for process 14771 was saved into 
'pid-14771-output.log'
[2022-05-31T22:27:06.663087767Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.663360403Z] Waiting for completion finished for process 
14771
[2022-05-31T22:27:06.663754609Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.663869034Z] Waiting for completion finished for process 
14771
STDERR:
 stdout: [];
 stderr: [Exception in thread "main" java.time.DateTimeException: Invalid ID 
for offset-based ZoneId: GMT-22:00
at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:436)
at java.base/java.time.ZoneId.of(ZoneId.java:406)
at java.base/java.time.ZoneId.of(ZoneId.java:358)
at java.base/java.time.ZoneId.of(ZoneId.java:314)
at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581)
at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570)
at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
at java.base/java.time.ZoneId.systemDefault(ZoneId.java:274)
at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:64)
at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:51)
Caused by: java.time.DateTimeException: Zone offset hours not in valid range: 
value -22 is not in the range -18 to 18
at java.base/java.time.ZoneOffset.validate(ZoneOffset.java:373)
at 
java.base/java.time.ZoneOffset.ofHoursMinutesSeconds(ZoneOffset.java:326)
at java.base/java.time.ZoneOffset.of(ZoneOffset.java:257)
at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:430)
... 10 more
]
 exitValue = 1

java.lang.RuntimeException: Expected to get exit value of [0]

at 
jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:489)
at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:49)
at 
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:1585)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to 
get exit value of [0]

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected to 
get exit value of [0]

-

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


RFR: 8287340: Refactor old code using StringTokenizer in locale related code

2022-05-31 Thread Naoto Sato
Refactoring some old code in locale providers. The test case data have also 
been modified due to:
- There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not 
handle the case for `no-NO-NY`.
- `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` 
and falls back, so comparing locales using language tags does not work for 
those locales. Changed to compare with `Locale.toString()` instead.

-

Commit messages:
 - 8287340: Refactor old code using StringTokenizer in locale related code

Changes: https://git.openjdk.java.net/jdk/pull/8960/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8960=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287340
  Stats: 175 lines in 4 files changed: 6 ins; 61 del; 108 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8960.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8960/head:pull/8960

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


Re: RFR: 8285838: DST not applying properly with zone id offset set with TZ env variable [v4]

2022-05-31 Thread Naoto Sato
On Mon, 30 May 2022 15:40:37 GMT, Gaurav Chaudhari  
wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an 
>> attempt is made to find the GMT offset in order to get the current time, 
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 67:

> 65: if ((month > Month.MARCH.getValue() && month < 
> Month.OCTOBER.getValue()) ||
> 66: (month == Month.MARCH.getValue() && 
> date.isAfter(getLastSundayOfMonth(date))) ||
> 67: (month == Month.OCTOBER.getValue() && 
> date.isBefore(getLastSundayOfMonth(date {

I don't think these conditions are correct, as `month` is zero-based, and 
comparing it with `Month.MARCH` will be incorrect. The same holds for October.

-

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


Re: RFR: 8284400: Improve XPath exception handling

2022-05-27 Thread Naoto Sato
On Fri, 27 May 2022 01:12:18 GMT, Joe Wang  wrote:

> Addresses an insufficiency of error handling in the XPath implementation. 
> Some cleanup where appropriate, without attempting to do too much as this is 
> a component that hasn't had much changes for 15 years, a fairly stable 
> application.
> 
> Test: tier2 passed
> JCK: JCK XML tests passed

LGTM. Nit: some files have old copyright years and/or `@LastModified` fields

-

Marked as reviewed by naoto (Reviewer).

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


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

2022-05-27 Thread Naoto Sato
On Fri, 27 May 2022 06:14:13 GMT, XenoAmess  wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Merge remote-tracking branch 'stuart-marks/pull/8302' into fix_8284780
>
># Conflicts:
>#  src/java.base/share/classes/java/util/HashSet.java
>#  src/java.base/share/classes/java/util/LinkedHashSet.java
>  - Minor terminology fixes: change "item" and "key" to element; remove
>"insertion-ordered" from LinkedHashSet static factory method because
>LHS is implicit insertion-ordered.

src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 
227:

> 225: }
> 226: StringTokenizer tokens = new 
> StringTokenizer(supportedLocaleString);
> 227: Set tagset = HashSet.newHashSet(tokens.countTokens());

Hi @XenoAmess, during the refactoring of the above `StringTokenizer`, it turned 
out that this `HashSet` can be replaced with `Set.of()`. So you can leave this 
piece as it is, as I will take care of it with JDK-8287340.

src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
 line 461:

> 459: }
> 460: StringTokenizer tokens = new 
> StringTokenizer(supportedLocaleString);
> 461: Set tagset = HashSet.newHashSet(tokens.countTokens());

Same as above.

-

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


Integrated: 8287187: Utilize HashMap.newHashMap() in CLDRConverter

2022-05-26 Thread Naoto Sato
On Wed, 25 May 2022 16:43:59 GMT, Naoto Sato  wrote:

> Refactoring the leftover self-calculations of the optimized `HashMap` initial 
> value with `newHashMap()` method. Also replaced some string literals using 
> text blocks for better readability. Confirmed that the output resource bundle 
> sources are effectively (sans indentation) the same as the original ones.

This pull request has now been integrated.

Changeset: c10749a6
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/c10749a6a70977fbd6cd33b298410d212276fcf1
Stats: 65 lines in 1 file changed: 8 ins; 1 del; 56 mod

8287187: Utilize HashMap.newHashMap() in CLDRConverter

Reviewed-by: joehw

-

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


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

2022-05-25 Thread Naoto Sato
On Wed, 25 May 2022 05:42:22 GMT, Stuart Marks  wrote:

> (Also, I haven't seen `StringTokenizer` in a long time)

That's some old code lingering in locale-related stuff. Will fix them after 
this PR gets integrated.

-

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


Re: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter [v2]

2022-05-25 Thread Naoto Sato
> Refactoring the leftover self-calculations of the optimized `HashMap` initial 
> value with `newHashMap()` method. Also replaced some string literals using 
> text blocks for better readability. Confirmed that the output resource bundle 
> sources are effectively (sans indentation) the same as the original ones.

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

  minor fixup

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8887/files
  - new: https://git.openjdk.java.net/jdk/pull/8887/files/faab3ea1..c2cc3391

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

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

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


RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter

2022-05-25 Thread Naoto Sato
Refactoring the leftover self-calculations of the optimized `HashMap` initial 
value with `newHashMap()` method. Also replaced some string literals using text 
blocks for better readability. Confirmed that the output resource bundle 
sources are effectively (sans indentation) the same as the original ones.

-

Commit messages:
 - 8287187: Utilize HashMap.newHashMap() in CLDRConverter

Changes: https://git.openjdk.java.net/jdk/pull/8887/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8887=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287187
  Stats: 65 lines in 1 file changed: 8 ins; 1 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8887/head:pull/8887

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


Re: RFR: 8287181: Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder.setExtension

2022-05-24 Thread Naoto Sato
On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov  wrote:

> No need to separately perform `HashMap.containsKey` before `HashMap.remove` 
> call. If key is present - it will be removed anyway. If it's not present, 
> nothing will be deleted.

Marked as reviewed by naoto (Reviewer).

-

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


Integrated: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

2022-05-23 Thread Naoto Sato
On Thu, 3 Mar 2022 19:33:31 GMT, Naoto Sato  wrote:

> Supporting `IsoFields` temporal fields in chronologies that are similar to 
> ISO chronology. Corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: ef7a9f81
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/ef7a9f817096d5fac8ed624cadb087fcbe5eb98a
Stats: 282 lines in 13 files changed: 244 ins; 10 del; 28 mod

8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

Reviewed-by: joehw, rriggs

-

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


Re: RFR: 8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0

2022-05-20 Thread Naoto Sato
On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov  wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use 
> single call `HashMap.getOrDefault`.
> It's faster and clearer.

Marked as reviewed by naoto (Reviewer).

-

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


Integrated: 8267038: Update IANA Language Subtag Registry to Version 2022-03-02

2022-05-19 Thread Naoto Sato
On Wed, 18 May 2022 16:28:02 GMT, Naoto Sato  wrote:

> This is to incorporate the latest language subtag registry definition 
> (version 2022-03-02) into JDK19.

This pull request has now been integrated.

Changeset: 7b19226b
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/7b19226be24356572df493446e3b0a9380b3d217
Stats: 281 lines in 2 files changed: 271 ins; 2 del; 8 mod

8267038: Update IANA Language Subtag Registry to Version 2022-03-02

Reviewed-by: rriggs

-

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


RFR: 8267038: Update IANA Language Subtag Registry to Version 2022-03-02

2022-05-18 Thread Naoto Sato
This is to incorporate the latest language subtag registry definition (version 
2022-03-02) into JDK19.

-

Commit messages:
 - LSR 2022-03-02
 - LSR 2021-12-29
 - LSR 2021-08-06
 - LSR 2021-07-21

Changes: https://git.openjdk.java.net/jdk/pull/8776/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8776=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267038
  Stats: 281 lines in 2 files changed: 271 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8776.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8776/head:pull/8776

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


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

2022-05-18 Thread 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: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]

2022-05-17 Thread Naoto Sato
> Supporting `IsoFields` temporal fields in chronologies that are similar to 
> ISO chronology. Corresponding CSR has also been drafted.

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:

 - Merge branch 'master' into JDK-8279185
 - Addressing review comments
 - Revert to use the default method
 - Removed unnecessary package names
 - Modified class desc of `IsoFields`
 - abstract class -> top level interface
 - interface -> abstract class
 - Removed the method
 - Changed to use a type to determine ISO based or not
 - Renamed the new method
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d7dfd3a6...3f69909f

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/45edbc3b..3f69909f

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

  Stats: 243466 lines in 3650 files changed: 182993 ins; 40828 del; 19645 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

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


Re: RFR: 8285838: DST not applying properly with zone id offset set with TZ env variable

2022-05-17 Thread Naoto Sato
On Wed, 11 May 2022 18:00:31 GMT, Gaurav Chaudhari  
wrote:

> This fix ensures that when a lookup for a custom TZ code fails, and an 
> attempt is made to find the GMT offset in order to get the current time, 
> Daylight savings rules are applied correctly.

Thanks for contributing the fix. This issue has been reported in the past, but 
closed as will not fix (https://bugs.openjdk.java.net/browse/JDK-6992725), as 
implementing POSIX TZ fully requires a sizable amount of work for a rare 
situation. Returning a fixed offset ID with the `TZ` set to observing DST is 
thus a compromised solution. Even if the fix would return a custom zone 
observing the DST does not mean the zone is correct in winter. Having said that 
I agree that the derived fixed offset zone should reflect the *current* offset, 
as well as macOS's implementation.

src/java.base/unix/native/libjava/TimeZone_md.c line 609:

> 607: }
> 608: 
> 609: offset = (gmt.tm_hour - localtm.tm_hour)*3600 + (gmt.tm_min - 
> localtm.tm_min)*60;

Since it is not using `timezone` anymore, we can reverse the subtraction, i.e., 
`localtime` - `gmtime` so that the weird sign switch below can be eliminated.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights 
> reserved.

This is a new test case, the year should be only 2022.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 27:

> 25:  * Specifically called by runCustomTzIDCheckDST.sh to check if Daylight 
> savings is
> 26:  * properly followed with a custom TZ code set through environment 
> variables.
> 27:  * */

Nit: Need a new line.

test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 1:

> 1: #

I'd change this script into a java test case (using `.sh` is not recommended). 
In fact, this causes a failure invoking `javac` with `-Xmx768m` (from 
TESTVMOPTS)
There are libraries under `jdk/test/lib/` for building test jvm process and 
tools.

test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 40:

> 38: 
> 39: OS=`uname -s`
> 40: case "$OS" in 

In case other than Linux/AIX, it would be helpful to emit some message that the 
test is ignored.

-

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


Re: RFR: 8282280: Update Xerces to Version 2.12.2 [v2]

2022-05-17 Thread Naoto Sato
On Tue, 17 May 2022 00:39:37 GMT, Joe Wang  wrote:

>> Update to Xerces 2.12.2.
>> 
>> The update also fixes JDK-8144117. Added a test.
>> 
>> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this 
>> update. See related issue report.
>
> Joe Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   provider description

Marked as reviewed by naoto (Reviewer).

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v9]

2022-05-17 Thread Naoto Sato
On Tue, 17 May 2022 01:19:30 GMT, Ichiroh Takiguchi  
wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has 
>> Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable 
> has non ASCII character

Looks good. Thanks for the fix!

-

Marked as reviewed by naoto (Reviewer).

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


Re: RFR: 8282280: Update Xerces to Version 2.12.2

2022-05-16 Thread Naoto Sato
On Mon, 16 May 2022 19:34:11 GMT, Joe Wang  wrote:

> Update to Xerces 2.12.2.
> 
> The update also fixes JDK-8144117. Added a test.
> 
> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this 
> update. See related issue report.

Changes look good to me. Some minor nits follow.

test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 48:

> 46:  */
> 47: public class SchemaTest {
> 48: private static final String XSD_8144117 = "\n" +

If it is not from the upstream Xerces test but our own, can we utilize text 
blocks here?

test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 79:

> 77: 
> 78: /*
> 79:  * DataProvider: valid xsd

This comment is the same as the above provider. Can we change it to a more 
meaningful one?

-

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


Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]

2022-05-16 Thread Naoto Sato
On Thu, 12 May 2022 18:02:26 GMT, Shruthi  wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and 
>> XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has refreshed the contents of this pull request, and previous commits 
> have been removed. The incremental views will show differences compared to 
> the previous content of the PR. The pull request contains one new commit 
> since the last revision:
> 
>   Modify copyright year

Do not enclose the skara command within backquotes.

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v8]

2022-05-16 Thread Naoto Sato
On Mon, 16 May 2022 17:16:31 GMT, Ichiroh Takiguchi  
wrote:

> The 1st word changed from Return to Returns.
Is it OK ?

That's more of plain English to me. Maybe some natives can correct it if needed.

> And it seems @return is translated to Japanese on Japanese environment.

Yes. I believe that's what is supposed to work.

-

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


Integrated: 8286399: Address possibly lossy conversions in JDK Build Tools

2022-05-16 Thread Naoto Sato
On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato  wrote:

> Applied required casts for the upcoming warning. Verified by cherry-picking 
> Adam's patch.

This pull request has now been integrated.

Changeset: c044cb83
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/c044cb8346bb8fbba46db1debe921cf96885ada0
Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8286399: Address possibly lossy conversions in JDK Build Tools

Reviewed-by: rriggs, joehw

-

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


Integrated: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

2022-05-16 Thread Naoto Sato
On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato  wrote:

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support 
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. 
> Corresponding CSR is also being drafted.

This pull request has now been integrated.

Changeset: b884db8f
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/b884db8f7c03fd300becaeb9d572f3b2c18351ae
Stats: 155 lines in 4 files changed: 110 ins; 0 del; 45 mod

8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and 
returns GMT unexpected

Reviewed-by: uschindler, scolebourne, joehw

-

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


Re: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools

2022-05-13 Thread Naoto Sato
On Fri, 13 May 2022 22:11:17 GMT, Joe Wang  wrote:

>> Applied required casts for the upcoming warning. Verified by cherry-picking 
>> Adam's patch.
>
> make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java
>  line 1278:
> 
>> 1276: state[numCategories] |= (short) END_STATE_FLAG;
>> 1277: if (sawEarlyBreak) {
>> 1278: state[numCategories] |= LOOKAHEAD_STATE_FLAG;
> 
> Does this need a cast as well? and also other cases, e.g. line 1019: 
> state[numCategories] = DONT_LOOP_FLAG;?

No, it doesn't. `LOOKAHEAD_STATE_FLAG` is defined as `0x2000` which is within 
the range of `short`. OTOH, `END_STATE_FLAG` is `0x8000` thus a lossy 
conversion.

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v8]

2022-05-13 Thread Naoto Sato
On Fri, 13 May 2022 17:38:48 GMT, Ichiroh Takiguchi  
wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has 
>> Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable 
> has non ASCII character

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 251:

> 249: 
> 250: /**
> 251:  * Return the {@code sun.jnu.encoding} system property.

This can be eliminated by changing the`@return` block tag below to `{@return 
the {@code sun.jnu.encoding} ...}`.

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 264:

> 262: 
> 263: /**
> 264:  * Return charset for {@code sun.jnu.encoding} system property.

Same as above. `charset` can be capitalized and changed to `{@code}`.

-

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


RFR: 8286399: Address possibly lossy conversions in JDK Build Tools

2022-05-13 Thread Naoto Sato
Applied required casts for the upcoming warning. Verified by cherry-picking 
Adam's patch.

-

Commit messages:
 - 8286399: Address possibly lossy conversions in JDK Build Tools

Changes: https://git.openjdk.java.net/jdk/pull/8706/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8706=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286399
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8706.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8706/head:pull/8706

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


Integrated: 8286287: Reading file as UTF-16 causes Error which "shouldn't happen"

2022-05-12 Thread Naoto Sato
On Tue, 10 May 2022 20:22:39 GMT, Naoto Sato  wrote:

> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter 
> replaces on malformed/unmappable characters with replacements. However, there 
> was a code path that lacked to set the `CodingErrorAction.REPLACE` on the 
> decoder. Unrelated, one typo in a test was also fixed.

This pull request has now been integrated.

Changeset: cc7560e9
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/cc7560e995eac56709d9e55a1561135fad246cb2
Stats: 54 lines in 2 files changed: 52 ins; 2 del; 0 mod

8286287: Reading file as UTF-16 causes Error which "shouldn't happen"

Reviewed-by: jpai, bpb, rriggs

-

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v5]

2022-05-11 Thread Naoto Sato
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support 
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. 
> Corresponding CSR is also being drafted.

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

 - Disallow `UTC` -> `GMT`
 - Merge branch 'master' into JDK-8285844
 - Minor fixup
 - Allowed round-trips for offset-style ZoneIds.
 - Fixed offsets in milliseconds, added test variations, refined Custom ID 
definitions
 - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets 
and returns GMT unexpected

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/9722decd..11150ac5

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

  Stats: 8626 lines in 248 files changed: 4866 ins; 2323 del; 1437 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v4]

2022-05-11 Thread Naoto Sato
On Wed, 11 May 2022 18:30:32 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Minor fixup
>
> src/java.base/share/classes/java/util/TimeZone.java line 80:
> 
>> 78:  * {@code GMT} Sign Hours {@code :} Minutes 
>> {@code :} Seconds
>> 79:  * {@code GMT} Sign Hours {@code :} Minutes
>> 80:  * {@code GMT} Sign Hours Minutes
> 
> For hours and minutes, the format can be hh:mm or hhmm. Is it worth it to 
> support hhmmss as well?

It would be consistent, but I don't see much requirement for it. I'll consider 
if someone needs it.

-

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v4]

2022-05-11 Thread Naoto Sato
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support 
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. 
> Corresponding CSR is also being drafted.

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

  Minor fixup

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/fcdaf512..9722decd

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

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

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v3]

2022-05-11 Thread Naoto Sato
On Wed, 11 May 2022 09:00:45 GMT, Uwe Schindler  wrote:

>> I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they 
>> fail to convert to TimeZone. Same happens if you use this as String name in 
>> `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It 
>> does not work with or without this PR.
>
> In short, we can only test what works. The test was mainly added to allow 
> roundtrips of `ZoneOffset` instances.

The code intended to allow only offset-style ids that start with `GMT` (which 
is compatible with TimeZone's CustomID). Now I made changes to allow all 
offset-style zone ids.

-

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v3]

2022-05-11 Thread Naoto Sato
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support 
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. 
> Corresponding CSR is also being drafted.

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

  Allowed round-trips for offset-style ZoneIds.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/81a806e5..fcdaf512

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

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

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


Re: RFR: 8286287: Reading file as UTF-16 causes Error which "shouldn't happen" [v2]

2022-05-11 Thread Naoto Sato
> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter 
> replaces on malformed/unmappable characters with replacements. However, there 
> was a code path that lacked to set the `CodingErrorAction.REPLACE` on the 
> decoder. Unrelated, one typo in a test was also fixed.

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

  Reverted the typo fix

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8640/files
  - new: https://git.openjdk.java.net/jdk/pull/8640/files/0fa7cd38..d5a29e2b

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

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

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


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

2022-05-10 Thread 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


RFR: 8286287: Reading file as UTF-16 causes Error which "shouldn't happen"

2022-05-10 Thread Naoto Sato
`String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter 
replaces on malformed/unmappable characters with replacements. However, there 
was a code path that lacked to set the `CodingErrorAction.REPLACE` on the 
decoder. Unrelated, one typo in a test was also fixed.

-

Commit messages:
 - 8286287: Reading file as UTF-16 causes Error which "shouldn't happen"

Changes: https://git.openjdk.java.net/jdk/pull/8640/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8640=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286287
  Stats: 55 lines in 3 files changed: 52 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8640.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8640/head:pull/8640

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v2]

2022-05-10 Thread Naoto Sato
On Mon, 9 May 2022 22:29:50 GMT, Uwe Schindler  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fixed offsets in milliseconds, added test variations, refined Custom ID 
>> definitions
>
> src/java.base/share/classes/java/util/TimeZone.java line 539:
> 
>> 537: public static TimeZone getTimeZone(ZoneId zoneId) {
>> 538: String tzid = zoneId.getId(); // throws an NPE if null
>> 539: if (zoneId instanceof ZoneOffset zo) {
> 
> I like this because it is much faster than the conversion to ZoneId and 
> parsing it back! It is similar to use of SimpleTimeZone, but this is better 
> as the returned timezone is unmodifiable, correct?

Yes, and it aligns with the other call site (line 588).

> test/jdk/java/util/TimeZone/ZoneOffsetRoundTripTest.java line 43:
> 
>> 41: private Object[][] testZoneOffsets() {
>> 42: return new Object[][] {
>> 43: {ZoneId.of("Z"), 0},
> 
> I know, `ZoneId.of()` should parse this as a `ZoneOffset` and return a 
> `ZoneOffset` instance, but maybe add also the other string variants with 
> prefix (`ZoneId.of("UTC+00:00:01")` or `ZoneId.of("GMT+00:00:01")` as data 
> items. Maybe also use `ZoneOffset.of()` for the plain zones to be explicit.

Added them except "UTC+...", as it is not recognizable as a Custom ID.

-

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v2]

2022-05-10 Thread Naoto Sato
On Tue, 10 May 2022 13:12:10 GMT, Jaikiran Pai  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Fixed offsets in milliseconds, added test variations, refined Custom ID 
>> definitions
>
> src/java.base/share/classes/java/util/TimeZone.java line 109:
> 
>> 107:  * 
>> 108:  * NormalizedCustomID:
>> 109:  * {@code GMT} Sign TwoDigitHours {@code :} 
>> Minutes [Seconds]
> 
> Hello Naoto,
> 
> Should this instead be: `... Minutes [{@code :} Seconds]` - 
> i.e. should it have the `:` literal if seconds are present in the custom 
> timezone id?

The colon is included in `Seconds` part below. I changed the part name to 
`ColonSeconds` to make it clearer.

> src/java.base/share/classes/java/util/TimeZone.java line 543:
> 
>> 541: return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID + tzid, 
>> totalSecs);
>> 542: } else {
>> 543: return getTimeZone(tzid, true);
> 
> Before the change in this PR, we used to prefix `GMT` to (non-custom timezone 
> ids) if the timezone id returned by `ZoneId#getId()` started with the `+` or 
> `-` sign, before calling `getTimeZone(modifiedTzid, true)`. 
> With this change, for `ZoneId`s that aren't `ZoneOffset` instance, we now 
> call `getTimeZone(originalTzid, true)`, without first checking/prefixing the 
> id with `GMT`. Is that an intentional change and would that potentially cause 
> `getTimeZone(String, boolean)` to return a different result?

Yes, it is intentional. The `Time-zone IDs` section in the `ZoneId` class 
description is clear that zone id starting with "+/-" is a `ZoneOffset` 
instance. Other ZoneIds should have offsets with prefix or region-based ids.

-

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


Re: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected [v2]

2022-05-10 Thread Naoto Sato
> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support 
> second-level resolution, enabling round trips with `java.time.ZoneOffset`s. 
> Corresponding CSR is also being drafted.

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

  Fixed offsets in milliseconds, added test variations, refined Custom ID 
definitions

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/843e86be..81a806e5

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

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

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


RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

2022-05-09 Thread Naoto Sato
This is to extend the `Custom ID`s in `java.util.TimeZone` class to support 
second-level resolution, enabling round trips with `java.time.ZoneOffset`s. 
Corresponding CSR is also being drafted.

-

Commit messages:
 - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets 
and returns GMT unexpected

Changes: https://git.openjdk.java.net/jdk/pull/8606/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8606=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285844
  Stats: 145 lines in 4 files changed: 98 ins; 1 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

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


Re: RFR: 8238373: Punctuation should be same in jlink help usage on Japanese language [v2]

2022-05-09 Thread Naoto Sato
On Mon, 9 May 2022 06:38:29 GMT, KIRIYAMA Takuya  wrote:

>> When showing help for the jlink command in a Japanese locale, delimiters of 
>> option's aliases are a mixture of "," and \u3001. Delimiter should be 
>> unified to ",".
>> As the same, there is a inconsistency of delimiters in the jar command help 
>> in a Japanese locale, and "," should be used.
>> Similarly, the javap command help uses space as delimiters other than the 
>> module option in all locales. This inconsistency should also be corrected.
>> 
>> Would you please review this fix?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8238373: Punctuation should be same in jlink help usage on Japanese language

I think it's ready for you to integrate. I can sponsor your changes.

-

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


Re: RFR: 8286163: micro-optimize Instant.plusSeconds

2022-05-09 Thread Naoto Sato
On Wed, 4 May 2022 20:27:04 GMT, lennartfricke  wrote:

> Provide micro-benchmark for comparison

Looks good to me.

-

Marked as reviewed by naoto (Reviewer).

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v4]

2022-05-06 Thread Naoto Sato
On Fri, 6 May 2022 14:29:06 GMT, Ichiroh Takiguchi  
wrote:

>> test/jdk/java/lang/System/i18nEnvArg.java line 110:
>> 
>>> 108: String s = System.getenv(EUC_JP_TEXT);
>>> 109: ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>> 110: PrintStream ps = new PrintStream(baos);
>> 
>> Can utilize try-with-resources pattern.
>
> Use `shouldNotContain()` to find the error message.

I was suggesting `try (ByteArrayOutputStream baos = ...) {` so that no need to 
clean them up, but I see you removed them. But I prefer not to use 
`shouldNotContain("ERROR: ")` but to check the return value as before.

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v5]

2022-05-06 Thread Naoto Sato
On Fri, 6 May 2022 14:23:00 GMT, Ichiroh Takiguchi  
wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has 
>> Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable 
> has non ASCII character

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 77:

> 75: SUN_JNU_ENCODING = getProperty(props, "sun.jnu.encoding");
> 76: jnuCharset = Charset.forName(SUN_JNU_ENCODING, 
> Charset.defaultCharset());
> 77: }

I am not sure it is OK to initialize `Charset` here, as `sun_jnu_encoding` is 
initialized in `System.initPhase1()` and pulling `Charset` there may cause some 
init order change. I'd only cache the encoding string here.

-

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


Integrated: 8286154: Fix 3rd party notices in test files

2022-05-06 Thread Naoto Sato
On Thu, 5 May 2022 16:13:59 GMT, Naoto Sato  wrote:

> Trivial fix to 3rd party copyright notices.

This pull request has now been integrated.

Changeset: 1277f5d8
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/1277f5d84e9c2863595396a471a61d83f8a0298c
Stats: 100 lines in 21 files changed: 64 ins; 0 del; 36 mod

8286154: Fix 3rd party notices in test files

Reviewed-by: darcy, joehw, iris

-

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


Integrated: 8272352: Java launcher can not parse Chinese character when system locale is set to UTF-8

2022-05-05 Thread Naoto Sato
On Wed, 27 Apr 2022 20:23:32 GMT, Naoto Sato  wrote:

> Java runtime has been detecting the Windows system locale encoding using 
> `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, 
> but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. 
> In order to detect whether the user has selected `UTF-8` as the default, the 
> code page has to be queried with `GetACP()`.
> Also, the case if the call to `GetLocaleInfo` fails changed to fall back to 
> `UTF-8` instead of `Cp1252`.

This pull request has now been integrated.

Changeset: 22934485
Author:Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/229344853126692d38ff7cb164dd5d17c5bf7fbb
Stats: 15 lines in 1 file changed: 6 ins; 4 del; 5 mod

8272352: Java launcher can not parse Chinese character when system locale is 
set to UTF-8

Reviewed-by: rriggs

-

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


RFR: 8286154: Fix 3rd party notices in test files

2022-05-05 Thread Naoto Sato
Trivial fix to 3rd party copyright notices.

-

Commit messages:
 - 8286154: Fix 3rd party notices in test files

Changes: https://git.openjdk.java.net/jdk/pull/8558/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8558=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286154
  Stats: 100 lines in 21 files changed: 64 ins; 0 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8558/head:pull/8558

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v4]

2022-05-05 Thread Naoto Sato
On Thu, 5 May 2022 08:08:29 GMT, Ichiroh Takiguchi  
wrote:

>> src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 73:
>> 
>>> 71: @SuppressWarnings("removal")
>>> 72: String jnuEncoding = 
>>> AccessController.doPrivileged((PrivilegedAction) ()
>>> 73: -> System.getProperty("sun.jnu.encoding"));
>> 
>> No need to issue `doPrivileged()`, which is deprecated
>
> Hello @naotoj .
> If I just use `System.getProperty("sun.jnu.encoding")`, following testcases 
> were failed.
> 
> java/lang/ProcessBuilder/SecurityManagerClinit.java 
> java/lang/ProcessHandle/PermissionTest.java 
> 
> Please give me your suggestion again.

Ah, OK. Never mind.

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v4]

2022-05-04 Thread Naoto Sato
On Wed, 4 May 2022 17:09:32 GMT, Ichiroh Takiguchi  
wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has 
>> Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable 
> has non ASCII character

src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 73:

> 71: @SuppressWarnings("removal")
> 72: String jnuEncoding = 
> AccessController.doPrivileged((PrivilegedAction) ()
> 73: -> System.getProperty("sun.jnu.encoding"));

No need to issue `doPrivileged()`, which is deprecated

src/java.base/unix/classes/java/lang/ProcessImpl.java line 149:

> 147: @SuppressWarnings("removal")
> 148: String jnuEncoding = 
> AccessController.doPrivileged((PrivilegedAction) ()
> 149: -> System.getProperty("sun.jnu.encoding"));

Same here.

test/jdk/java/lang/System/i18nEnvArg.java line 70:

> 68: Map environ = pb.environment();
> 69: environ.clear();
> 70: environ.put("LANG", "ja_JP.eucjp");

There are many duplicate pieces of code here and in the `else` block below. Can 
you simplify this `if` statement more?

test/jdk/java/lang/System/i18nEnvArg.java line 110:

> 108: String s = System.getenv(EUC_JP_TEXT);
> 109: ByteArrayOutputStream baos = new ByteArrayOutputStream();
> 110: PrintStream ps = new PrintStream(baos);

Can utilize try-with-resources pattern.

-

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


Re: RFR: 8272352: Java launcher can not parse Chinese character when system locale is set to UTF-8 [v2]

2022-05-03 Thread Naoto Sato
On Tue, 3 May 2022 16:17:00 GMT, Roger Riggs  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Default to UTF-8 if malloc fails
>
> src/java.base/windows/native/libjava/java_props_md.c line 695:
> 
>> 693:_encoding);
>> 694: 
>> 695: sprops.sun_jnu_encoding = getEncodingInternal(0);
> 
> How should NULL from `getEncodingInternal` be handled?  (only if malloc 
> fails).
> Perhaps just it should return the literal "UTF-8".

Fixed as suggested.

-

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


Re: RFR: 8272352: Java launcher can not parse Chinese character when system locale is set to UTF-8 [v2]

2022-05-03 Thread Naoto Sato
> Java runtime has been detecting the Windows system locale encoding using 
> `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, 
> but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. 
> In order to detect whether the user has selected `UTF-8` as the default, the 
> code page has to be queried with `GetACP()`.
> Also, the case if the call to `GetLocaleInfo` fails changed to fall back to 
> `UTF-8` instead of `Cp1252`.

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

  Default to UTF-8 if malloc fails

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8434/files
  - new: https://git.openjdk.java.net/jdk/pull/8434/files/cde671cf..e04e0fb6

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

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

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v2]

2022-05-03 Thread Naoto Sato
On Tue, 3 May 2022 17:30:34 GMT, Ichiroh Takiguchi  
wrote:

>> test/jdk/java/lang/System/i18nEnvArg.java line 63:
>> 
>>> 61: }
>>> 62: 
>>> 63: public static class Start {
>> 
>> Do we need `Start` class? Can it be merged with the parent to reduce the 
>> complexity?
>
> I'm not sure, it expected one...
> 
> I created i18nEnvArg.sh for start-up, then add `@modules jdk.charsets` and 
> remove `i18nEnvArg$Start` class.

Sorry if my comment was unclear. I meant to not create a shell script (shell 
scripts in the test are discouraged), but to re-use the main class twice, 
invoking with different arguments to main(), as both creating a testJvm process 
(one for eucjp jvm, and the other for Start).

>> test/jdk/java/lang/System/i18nEnvArg.java line 130:
>> 
>>> 128: environ_mid.setAccessible(true);
>>> 129: byte[][] environ = (byte[][]) environ_mid.invoke(null,
>>> 130: (Object[])null);
>> 
>> I am not sure I like this piece, invoking a package private method of 
>> `ProcessEnvironment` class. Can we simply verify the result of 
>> `System.getenv(EUC_JP_TEXT)`?
>
> I think 3 processes required for this testing.
> 1. Start test process on ja_JP.eucjp locale
> 2. Set the test data by encoder
> 3. Verify the encoded data by decoder
> 
> To verify the encoded data, I think I need to check the byte data.

Do we need to verify the intermediate byte encoding? Could we simply compare 
the text given to environ.put() in Start process and System.getenv() in Verify 
process match?

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v2]

2022-05-02 Thread Naoto Sato
On Sun, 1 May 2022 04:51:17 GMT, Ichiroh Takiguchi  
wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has 
>> Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable 
> has non ASCII character

test/jdk/java/lang/System/i18nEnvArg.java line 63:

> 61: }
> 62: 
> 63: public static class Start {

Do we need `Start` class? Can it be merged with the parent to reduce the 
complexity?

test/jdk/java/lang/System/i18nEnvArg.java line 87:

> 85: System.getProperty("java.class.path"),
> 86: "i18nEnvArg$Verify",
> 87: EUC_JP_TEXT);

Can utilize `ProcessTools` class.

test/jdk/java/lang/System/i18nEnvArg.java line 130:

> 128: environ_mid.setAccessible(true);
> 129: byte[][] environ = (byte[][]) environ_mid.invoke(null,
> 130: (Object[])null);

I am not sure I like this piece, invoking a package private method of 
`ProcessEnvironment` class. Can we simply verify the result of 
`System.getenv(EUC_JP_TEXT)`?

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v2]

2022-05-02 Thread Naoto Sato
On Sun, 1 May 2022 04:47:09 GMT, Ichiroh Takiguchi  
wrote:

>> test/jdk/java/lang/System/i18nEnvArg.java line 26:
>> 
>>> 24: /*
>>> 25:  * @test
>>> 26:  * @bug 8285517
>> 
>> If the test should work only on a particular env, should describe here and 
>> add `@requires`  tag.
>
> Add "@requires (os.family == "linux")"

Also `@modules jdk.charsets` should be added so that the test should be 
immediately ignored if it does not have `EUC-JP` charset.

-

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


Re: RFR: 8285947: Avoid redundant HashMap.containsKey calls in ZoneName

2022-05-02 Thread Naoto Sato
On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov  wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that Map 
> doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could be eliminated - 
> `java.time.format.ZoneName`.
> it gives a bit of performance for `toZid`.
> 
> 
> Benchmark Mode  Cnt   Score   Error  Units
> ZoneNamesBench.useExistingCountry avgt5  10,738 ± 0,065  ns/op
> ZoneNamesBench.useExistingCountryOld  avgt5  13,679 ± 0,089  ns/op
> 
> 
> 
> Benchmark
> 
> 
> @BenchmarkMode(value = Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Benchmark)
> public class ZoneNamesBench {
> 
> @Benchmark
> public String useExistingCountry() {
> return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
> }
> 
> @Benchmark
> public String useExistingCountryOld() {
> return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
> }
> }
> 
> 
> 
> public static String toZid(String zid, Locale locale) {
> String mzone = zidToMzone.get(zid);
> if (mzone == null) {
> String alias = aliases.get(zid);
> if (alias != null) {
> zid = alias;
> mzone = zidToMzone.get(zid);
> }
> }
> if (mzone != null) {
> Map map = mzoneToZidL.get(mzone);
> if (map == null || ((zid = map.get(locale.getCountry())) == 
> null)) {
> zid = mzoneToZid.get(mzone);
> }
> }
> return toZid(zid);
> }
> 
> public static String toZid(String zid) {
> return aliases.getOrDefault(zid, zid);
> }
> 
> public static String toZidOld(String zid, Locale locale) {
> String mzone = zidToMzone.get(zid);
> if (mzone == null && aliases.containsKey(zid)) {
> zid = aliases.get(zid);
> mzone = zidToMzone.get(zid);
> }
> if (mzone != null) {
> Map map = mzoneToZidL.get(mzone);
> if (map != null && map.containsKey(locale.getCountry())) {
> zid = map.get(locale.getCountry());
> } else {
> zid = mzoneToZid.get(mzone);
> }
> }
> return toZidOld(zid);
> }
> 
> public static String toZidOld(String zid) {
> if (aliases.containsKey(zid)) {
> return aliases.get(zid);
> }
> return zid;
> }
> 
> 

Marked as reviewed by naoto (Reviewer).

-

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


Integrated: 8282227: Locale information for nb is not working properly

2022-04-29 Thread Naoto Sato
On Tue, 26 Apr 2022 00:32:48 GMT, Naoto Sato  wrote:

> This was caused by incorporating CLDR v39, which switched the Norwegian 
> locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources 
> from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly 
> inheriting `no` from `nb` will fix the issue.

This pull request has now been integrated.

Changeset: 3d07b3c7
Author:Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/3d07b3c7f01b60ff4dc38f62407c212b48883dbf
Stats: 79 lines in 2 files changed: 74 ins; 1 del; 4 mod

8282227: Locale information for nb is not working properly

Reviewed-by: rriggs

-

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


Re: RFR: 8272352: Java launcher can not parse Chinese character when system locale is set to UTF-8

2022-04-27 Thread Naoto Sato
On Wed, 27 Apr 2022 23:12:59 GMT, Jie Fu  wrote:

> Is it possible to write a jtreg test for this fix? Thanks.

I am happy to write a test if possible, but AFAIK it requires configuring 
Windows settings (and reboot), so I don't think jtreg is capable of doing so. 
Thus I added `noreg-hard` to the JBS issue.

-

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


RFR: 8272352: Java launcher can not parse Chinese character when system locale is set to UTF-8

2022-04-27 Thread Naoto Sato
Java runtime has been detecting the Windows system locale encoding using 
`GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, but 
it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. In 
order to detect whether the user has selected `UTF-8` as the default, the code 
page has to be queried with `GetACP()`.
Also, the case if the call to `GetLocaleInfo` fails changed to fall back to 
`UTF-8` instead of `Cp1252`.

-

Commit messages:
 - 8272352: Java launcher can not parse Chinese character when system locale is 
set to UTF-8

Changes: https://git.openjdk.java.net/jdk/pull/8434/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8434=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272352
  Stats: 13 lines in 1 file changed: 3 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8434.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8434/head:pull/8434

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


Re: RFR: 8238373: Punctuation should be same in jlink help usage on Japanese language

2022-04-27 Thread Naoto Sato
On Wed, 27 Apr 2022 08:59:20 GMT, KIRIYAMA Takuya  wrote:

> When showing help for the jlink command in a Japanese locale, delimiters of 
> option's aliases are a mixture of "," and \u3001. Delimiter should be unified 
> to ",".
> As the same, there is a inconsistency of delimiters in the jar command help 
> in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the 
> module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

Looks fine to me. Nit: please modify the copyright years for `javap` properties 
files, as you modified the base (`javap.properties`) file.

-

Marked as reviewed by naoto (Reviewer).

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


Re: RFR: 8285485: Fix typos in corelibs

2022-04-27 Thread Naoto Sato
On Wed, 27 Apr 2022 06:39:30 GMT, Athijegannathan Sundararajan 
 wrote:

>> I ran `codespell` on modules owned by core-libs, and accepted those changes 
>> where it indeed discovered real typos.
>> 
>> I will update copyright years using a script before pushing (otherwise like 
>> every second change would be a copyright update, making reviewing much 
>> harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. 
>> The trouble with automating this is of course all false positives. But 
>> before even trying to solve that issue, all true positives must be fixed. 
>> Hence this PR.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties
>  line 188:
> 
>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>> 187: 
>> 188: main.plugin.category=\u7C7B\u522B
> 
> what's this?

Removing the trailing space? A similar one is in the `ja` resource bundle.

-

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


Re: RFR: 8285485: Fix typos in corelibs

2022-04-27 Thread Naoto Sato
On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie  wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes 
> where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like 
> every second change would be a copyright update, making reviewing much 
> harder).
> 
> The long term goal here is to make tooling support for running `codespell`. 
> The trouble with automating this is of course all false positives. But before 
> even trying to solve that issue, all true positives must be fixed. Hence this 
> PR.

Marked as reviewed by naoto (Reviewer).

-

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


Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

2022-04-26 Thread Naoto Sato
On Sun, 24 Apr 2022 09:18:54 GMT, Ichiroh Takiguchi  
wrote:

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese 
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

Thanks for fixing the issue.
As to the test, it has lots of redundancy, and too complicated to me. Can you 
simplify the test?

src/java.base/unix/classes/java/lang/ProcessImpl.java line 146:

> 144: private static final LaunchMechanism launchMechanism = 
> platform.launchMechanism();
> 145: private static final byte[] helperpath = 
> toCString(StaticProperty.javaHome() + "/lib/jspawnhelper");
> 146: private static Charset jnuCharset = null;

Can we simply call `jnuCharset()` here?

test/jdk/java/lang/ProcessBuilder/Basic.java line 605:

> 603: String fileEncoding = System.getProperty("file.encoding");
> 604: Charset cs;
> 605: if (nativeEncoding != null && 
> !nativeEncoding.equals(fileEncoding)) {

What's the reason for comparing `file.encoding`? Does 
`Charset.forName(nativeEncoding, Charset.defaultCharset())` suffice?

test/jdk/java/lang/System/i18nEnvArg.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8285517

If the test should work only on a particular env, should describe here and add 
`@requires`  tag.

test/jdk/java/lang/System/i18nEnvArg.java line 50:

> 48: 
> 49: public static void main(String[] args) throws Exception {
> 50: ProcessBuilder pb = new ProcessBuilder(javeExe,

Can utilize `jdk.test.lib.process.ProcessTools`.

-

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


Integrated: 8283620: System.out does not use the encoding/charset specified in the Javadoc

2022-04-26 Thread Naoto Sato
On Fri, 15 Apr 2022 20:26:55 GMT, Naoto Sato  wrote:

> Promoting the internal system properties for `System.out` and `System.err` so 
> that users can override the encoding used for those streams to `UTF-8`, 
> aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

This pull request has now been integrated.

Changeset: 03bcf7b6
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/03bcf7b6d196f6c5d851059cb6f580767eee4e94
Stats: 55 lines in 8 files changed: 22 ins; 4 del; 29 mod

8283620: System.out does not use the encoding/charset specified in the Javadoc

Reviewed-by: alanb

-

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


RFR: 8282227: Locale information for nb is not working properly

2022-04-25 Thread Naoto Sato
This was caused by incorporating CLDR v39, which switched the Norwegian locale 
inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources from `nb` 
to `no`, which now contradicts Java's locale fallback. Explicitly inheriting 
`no` from `nb` will fix the issue.

-

Commit messages:
 - 8282227: Locale information for nb is not working properly

Changes: https://git.openjdk.java.net/jdk/pull/8394/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8394=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282227
  Stats: 79 lines in 2 files changed: 74 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8394.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8394/head:pull/8394

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


Re: RFR: JDK-8285614: Fix typo in java.lang.Float

2022-04-25 Thread Naoto Sato
On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy  wrote:

> Fix typo introduced in JDK-8261123.

Marked as reviewed by naoto (Reviewer).

-

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


Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v2]

2022-04-25 Thread Naoto Sato
On Sat, 23 Apr 2022 05:53:17 GMT, David Holmes  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Modified the spec for the new system properties.
>
> src/java.base/share/classes/java/lang/System.java line 774:
> 
>> 772:  * Character encoding name for {@link System#out 
>> System.out}.
>> 773:  * The Java runtime can be started with the system property set 
>> to {@code UTF-8},
>> 774:  * starting it with the property set to another value clears to 
>> undefined behavior.
> 
> _leads_ to undefined behavior

Good catch! Fixed.

-

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


Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v3]

2022-04-25 Thread Naoto Sato
> Promoting the internal system properties for `System.out` and `System.err` so 
> that users can override the encoding used for those streams to `UTF-8`, 
> aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

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

  Fixed typos.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8270/files
  - new: https://git.openjdk.java.net/jdk/pull/8270/files/b5bcb870..a91fd9ca

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

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

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


Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v2]

2022-04-22 Thread Naoto Sato
> Promoting the internal system properties for `System.out` and `System.err` so 
> that users can override the encoding used for those streams to `UTF-8`, 
> aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

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

  Modified the spec for the new system properties.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8270/files
  - new: https://git.openjdk.java.net/jdk/pull/8270/files/9ef42917..b5bcb870

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

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

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


Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v2]

2022-04-22 Thread Naoto Sato
On Fri, 22 Apr 2022 09:31:19 GMT, Alan Bateman  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Modified the spec for the new system properties.
>
> src/java.base/share/classes/java/lang/System.java line 780:
> 
>> 778:  * The property may be set on the command line to the value
>> 779:  * {@code UTF-8}. Setting the property to a value other than 
>> {@code UTF-8}
>> 780:  * leads to unspecified behavior.
> 
> I think the proposal to introduce two standard properties is good and is 
> consistent with the recently introduced native.encoding. I'm not 100% sure 
> that the sentence "The property may be set on the command line ..." is 
> appropriate for the spec of standard properties. We got away with that for 
> file.encoding in implNote but that isn't spec. I think we may have to replace 
> this with something that says that the Java runtime can be started with the 
> system property set to "UTF-8", starting it with the property set to another 
> value clears to undefined behavior.

Thanks, Alan. Modified them as suggested.

-

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


RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc

2022-04-21 Thread Naoto Sato
Promoting the internal system properties for `System.out` and `System.err` so 
that users can override the encoding used for those streams to `UTF-8`, 
aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.

-

Commit messages:
 - 8283620: System.out does not use the encoding/charset specified in the 
Javadoc

Changes: https://git.openjdk.java.net/jdk/pull/8270/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8270=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283620
  Stats: 57 lines in 8 files changed: 24 ins; 4 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8270.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8270/head:pull/8270

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


Integrated: 8283324: CLDRConverter run time increased by 3x

2022-04-21 Thread Naoto Sato
On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato  wrote:

> Fixing performance regression caused by the fix to 
> https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra 
> looping through the resource map multiple times which was not necessary. The 
> execution time of the tool now got back on par with close to JDK18.

This pull request has now been integrated.

Changeset: f6e9ca0c
Author:    Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/f6e9ca0cbe671502b6b3b1d0f8fd86f0928f64ea
Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 mod

8283324: CLDRConverter run time increased by 3x

Reviewed-by: ihse

-

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


RFR: 8283324: CLDRConverter run time increased by 3x

2022-04-20 Thread Naoto Sato
Fixing performance regression caused by the fix to 
https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra 
looping through the resource map multiple times which was not necessary. The 
execution time of the tool now got back on par with close to JDK18.

-

Commit messages:
 - 8283324: CLDRConverter run time increased by 3x

Changes: https://git.openjdk.java.net/jdk/pull/8288/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8288=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283324
  Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8288.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8288/head:pull/8288

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


Re: RFR: 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException

2022-04-20 Thread Naoto Sato
On Wed, 20 Apr 2022 20:08:01 GMT, Joe Wang  wrote:

> Patch note:
> 
> A previous patch had a bug that missed the boundary check, that will 
> cause StringIndexOutOfBoundsException to be thrown instead of 
> XPathExpressionException as expected.
> 
> Fix: the fix is to check the boundaries of the parameter "index". 
> Objects.checkIndex is removed as it's redundant.

Marked as reviewed by naoto (Reviewer).

-

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


Re: RFR: 8284920: Incorrect Token type causes XPath expression to return incorrect results [v2]

2022-04-20 Thread Naoto Sato
On Wed, 20 Apr 2022 18:28:19 GMT, Joe Wang  wrote:

>> Patch note:
>> 
>> The previous patch changed all literal tokens to use constants. However, 
>> replacing "." with Token.DOT introduced this bug. 
>> While tokens with a single char are inherently of type char, due to the 
>> different implementation of the overloaded method "tokenIs" that takes 
>> String or char, a wrong input type will produce incorrect result. It may be 
>> worth it to take a closer look at the overloaded method, but for now, a 
>> quick fix is to reverse the input type back to String (DOT_STR).
>> 
>> Test: the issue affect the processing of the short form of the parent axis 
>> "..". The test verifies that all form of the parent axis shall return the 
>> same result.
>> 
>> Test: all XML tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   add test cases for the self axis

Marked as reviewed by naoto (Reviewer).

-

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


Re: RFR: 8282120: optimal capacity tests and test library need to be cleaned up

2022-04-19 Thread Naoto Sato
On Tue, 19 Apr 2022 18:12:04 GMT, Stuart Marks  wrote:

> The test `java/lang/Enum/ConstantDirectoryOptimalCapacity.java` was 
> problem-listed by 
> [JDK-8281631](https://bugs.openjdk.java.net/browse/JDK-8281631) and 
> essentially superseded by 
> [JDK-8186958](https://bugs.openjdk.java.net/browse/JDK-8186958). Given this, 
> the test should simply be removed. This test is the only test that depends on 
> a test library utility `test/lib/jdk/test/lib/util/OptimalCapacity.java` 
> which has a number of issues of its own, so it should simply be removed as 
> well.
> 
> See the bug report, in particular the comment
> 
> https://bugs.openjdk.java.net/browse/JDK-8282120?focusedCommentId=14489450=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14489450
> 
> for detailed discussion.

Good cleanup!

-

Marked as reviewed by naoto (Reviewer).

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


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

2022-04-19 Thread 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: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v9]

2022-04-19 Thread Naoto Sato
> Supporting `IsoFields` temporal fields in chronologies that are similar to 
> ISO chronology. Corresponding CSR has also been drafted.

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

  Addressing review comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/c3f15f6a..45edbc3b

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

  Stats: 50 lines in 6 files changed: 18 ins; 7 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

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


  1   2   3   4   5   6   7   8   9   10   >