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
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
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`).
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
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`,
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, `MissingResourceCau
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`,
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.encod
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:
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
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
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
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
> 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 i
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.
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
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`.
> - `Local
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
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
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
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
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
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 unn
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
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
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
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.
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:
>#
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
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
on) 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
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
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).
-
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:
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:
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
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:
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:
> 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 b
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
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
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
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
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,
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
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/
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
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:
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
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:
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 `CodingErrorActio
> 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
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:
>
>>
> 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
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
>>
> 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
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
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
`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.
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
&
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
&
> 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
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
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
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
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 =
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
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:
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.
&
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:
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:
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
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_
ected `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
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
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
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
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
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 fallb
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
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
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
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
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
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
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 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
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
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/
> 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
> 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
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/
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
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
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
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
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
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
>
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
> 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 - 100 of 1638 matches
Mail list logo
