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
Webrev
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
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
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
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
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
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
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()`
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()`
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`.
> - `
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
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
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
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
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
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
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 ba
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 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
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 origin
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: https://git.openjdk.java.net/jdk/p
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: https://webrevs.openjd
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
> 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
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
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 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 with a new target base due to a merge
or a re
> 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
>> doe
> 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 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
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 Zone
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:
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/
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
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
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
On Thu, 21 Apr 2022 11:34:14 GMT, Magnus Ihse Bursie wrote:
> `codespell` could just find a single typo in the files covered by the i18n
> alias. Just fixing the typo did not make the comment more readable, so I
> rewrote it slightly.
Marked as reviewed by naoto (Reviewer).
-
PR:
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
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
> 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
> 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
On Thu, 14 Apr 2022 20:52:44 GMT, Naoto Sato wrote:
> Added the test case, and eliminated the immediate hashmap value, replaced
> with the ordinal number of `Character.UnicodeScript.UNKNOWN`.
This pull request has now been integrated.
Changeset: eb9c457b
Author: Naoto Sat
> Added the test case, and eliminated the immediate hashmap value, replaced
> with the ordinal number of `Character.UnicodeScript.UNKNOWN`.
Naoto Sato has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 29 commits:
- Merge
> 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
> Added the test case, and eliminated the immediate hashmap value, replaced
> with the ordinal number of `Character.UnicodeScript.UNKNOWN`.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Fixed a typo
-
Changes:
Added the test case, and eliminated the immediate hashmap value, replaced with
the ordinal number of `Character.UnicodeScript.UNKNOWN`.
-
Depends on: https://git.openjdk.java.net/jdk/pull/7928
Commit messages:
- 8284856: Add a test case for checking UnicodeScript entity numbers
Ch
On Thu, 14 Apr 2022 18:32:03 GMT, Naoto Sato wrote:
>>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
>>
>> @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But
>> usually we only solve 1 issue in 1 pr, so I thin
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in c
On Thu, 14 Apr 2022 17:06:53 GMT, XenoAmess wrote:
>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
>
>> Good point! Filed an issue: https://bugs.openjdk.java.net/browse/JDK-8284856
>
> @stuart-marks @naotoj I can help solve JDK-8284856 after this pr. But usually
On Wed, 13 Apr 2022 23:48:06 GMT, Stuart Marks wrote:
> but I suspect the cleanup may simply be removing them entirely.
+1 for removing it.
-
PR: https://git.openjdk.java.net/jdk/pull/7928
On Wed, 13 Apr 2022 22:40:38 GMT, Stuart Marks wrote:
>> XenoAmess has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update LastModified
>
> src/java.base/share/classes/java/lang/Character.java line 8574:
>
>> 8572: private static
> 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:
Modified class desc of `Iso
On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> revert changes in:
> src/java.desktop
> src/java.management
> src/jdk
> 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
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
unicode.org/index/downloads/cldr-41
Naoto Sato has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 22 commits:
- Merge branch 'master' into cldr+
- Merge branch 'master' into cldr+
- CLDR v41 final
- CLDR v41 beta2
- Mer
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> consta
This is to upgrade the CLDR data from version 39 to version 41 which was
released yesterday. The vast majority of the changes are basically replacing
the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
v41's release notes: https://cldr.unicode.org/index/downloads/cldr-4
On Thu, 7 Apr 2022 00:09:58 GMT, Joe Wang wrote:
>> This is a follow-on task after deprecating the Locale constructors
>> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
>> simple replacements to Locale constructors with `Locale.of()` or Locale
>> constants, such as
This is a follow-on task after deprecating the Locale constructors
(https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
simple replacements to Locale constructors with `Locale.of()` or Locale
constants, such as `Locale.US`.
-
Commit messages:
- 8283698: Refa
On Wed, 6 Apr 2022 16:48:38 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java line 63:
>>
>>> 61: * http://www.ietf.org/rfc/rfc3454.txt";>RFC 3454.
>>> 62: * StringPrep prepares Unicode strings for use in network protocols.
>>> 63: * Profiles of
On Wed, 6 Apr 2022 14:12:17 GMT, Daniel Jeliński wrote:
>> This patch adds missing `r` in `string`s
>
> Daniel Jeliński has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Revert liblcms changes
src/java.base/share/classes/jdk/internal/icu/tex
On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad wrote:
> A few integer divisions and multiplications can be replaced with test +
> addition, leading to a decent speed-up on java.time microbenchmarks such as
> `GetYearBench`. Numbers from my local x86 workstation, seeing similar
> speed-up on
Fixes test failures caused by depending on the default locale. Specifying
explicit `Locale.US` will do.
-
Commit messages:
- 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails:
DateTimeParseException
Changes: https://git.openjdk.java.net/jdk/pull/8045/files
Webrev:
On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung wrote:
> redo of 8280400
I believe
`src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties`
and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to
the l10n changes.
-
PR: https:
On Tue, 29 Mar 2022 21:28:44 GMT, Naoto Sato wrote:
>> Proposing to deprecate the constructors in the `java.util.Locale` class.
>> There is already a factory method and a builder to return singletons, so
>> there is no need to have constructors anymore unless one purpose
couraged. We cannot
> terminally deprecate those constructors for the compatibility to serialized
> objects created with older JDKs. Please see the draft CSR for more detail.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Change
On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote:
> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.
LGTM
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8005
On Mon, 28 Mar 2022 21:06:35 GMT, Roger Riggs wrote:
>> While it is true for completeness, I would limit the addition of new method
>> as little as possible, because there are already several ways to obtain a
>> Locale object.
>
> As with other varargs method calls, it is possible to pass an ar
couraged. We cannot
> terminally deprecate those constructors for the compatibility to serialized
> objects created with older JDKs. Please see the draft CSR for more detail.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
On Mon, 28 Mar 2022 17:13:44 GMT, Lance Andersen wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> New unit test. IllegalArgumentException.
>
> test/jdk/java/util/Locale/TestOf.jav
couraged. We cannot
> terminally deprecate those constructors for the compatibility to serialized
> objects created with older JDKs. Please see the draft CSR for more detail.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
couraged. We cannot
> terminally deprecate those constructors for the compatibility to serialized
> objects created with older JDKs. Please see the draft CSR for more detail.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision
On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote:
> This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset`
> (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.java.net/jd
On Sun, 27 Mar 2022 08:45:01 GMT, ExE Boss wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed a build failure
>
> src/java.base/share/classes/java/util/Locale.java line 819:
>
On Sat, 26 Mar 2022 11:30:53 GMT, Lance Andersen wrote:
> One suggestion As part of the PR, we should probably update
> test/jdk/java/util/Locale/LocaleTest.java. or perhaps add a new test for
> Locale.of() for completeness.
Thanks, Lance. Sure, I will add some new unit tests for the new metho
couraged. We cannot
> terminally deprecate those constructors for the compatibility to serialized
> objects created with older JDKs. Please see the draft CSR for more detail.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Fix
On Fri, 25 Mar 2022 01:56:33 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
>> line 375:
>>
>>> 373: (locale.getLanguage().isEmpty() ? "und" :
couraged. We cannot
> terminally deprecate those constructors for the compatibility to serialized
> objects created with older JDKs. Please see the draft CSR for more detail.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Added a
On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs wrote:
>> Proposing to deprecate the constructors in the `java.util.Locale` class.
>> There is already a factory method and a builder to return singletons, so
>> there is no need to have constructors anymore unless one purposefully wants
>> to crea
On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks wrote:
>> Proposing to deprecate the constructors in the `java.util.Locale` class.
>> There is already a factory method and a builder to return singletons, so
>> there is no need to have constructors anymore unless one purposefully wants
>> to cre
Proposing to deprecate the constructors in the `java.util.Locale` class. There
is already a factory method and a builder to return singletons, so there is no
need to have constructors anymore unless one purposefully wants to create
`ill-formed` Locale objects, which is discouraged. We cannot ter
On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato wrote:
> Fixing the out-of-date number of entries in
> `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been
> renamed and now repurposed just to examine whether the `NUM_ENTITIES`
> correctly has the `map.size()`
On Tue, 22 Mar 2022 21:42:04 GMT, Stuart Marks wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment adjusted per review suggestion
>
> src/java.base/share/classes/java/lang/Char
> Fixing the out-of-date number of entries in
> `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been
> renamed and now repurposed just to examine whether the `NUM_ENTITIES`
> correctly has the `map.size()` value.
Naoto Sato has updated the pull request increm
Fixing the out-of-date number of entries in
`Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been
renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly
has the `map.size()` value.
-
Commit messages:
- 8283465: Character.UnicodeBlock.NU
On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato wrote:
> This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE
> redenomination (removing 3 zeros). Its effective date is 4/1, but I went
> ahead as JDK19 won't be released by 4/1.
This pull request has now b
This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE
redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead
as JDK19 won't be released by 4/1.
-
Commit messages:
- 8283277: ISO 4217 Amendment 171 Update
Changes: https://git.openjdk.jav
1 - 100 of 1001 matches
Mail list logo
