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

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

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

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 pu

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

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, `MissingResourceCause

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

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

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

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 add

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()`

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()`

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

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 increm

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

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

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

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

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 pu

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 t

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 pu

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

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

2022-06-01 Thread Naoto Sato
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: R

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

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 ba

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

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

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.

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 resour

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

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 origin

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

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:

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

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

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

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

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

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 i

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

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

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

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

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

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

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 i

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

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

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

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

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 re

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

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

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

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

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

2022-05-11 Thread Naoto Sato
s 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..d5a29

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

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.

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 &

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 &

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

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 Zone

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 co

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

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 k

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:

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

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&pr=8558&range=00 Issue: https://bugs.openjdk.java.net/browse/

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

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 k

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_

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

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

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 k

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 (

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 b

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

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

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,

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 comma

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 chan

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 co

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

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.

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 mes

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/

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

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

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/

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 e

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

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 me

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

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 implemen

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

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 ar

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

  1   2   3   4   5   6   7   8   9   10   >