On Fri, 1 Aug 2025 19:05:27 GMT, Naoto Sato wrote:
>> Enabling lenient minus sign matching when parsing numbers. In some locales,
>> e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212),
>> which is not the "Hyphen Minus" (U+002D) that users type in from keyboard.
>> Thus
On Fri, 1 Aug 2025 20:14:46 GMT, Justin Lu wrote:
> Please review this PR which is a backport of commit
> [8e921aee](https://github.com/openjdk/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> It is a t
On Fri, 1 Aug 2025 19:08:37 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/text/DecimalFormat.java line 422:
>>
>>> 420: * @implNote The default implementation follows the LDML specification
>>> for
>>> 421: * {@code parseLenient} elements to interpret minus sign patterns when
>>
Please review this PR which is a backport of commit
[8e921aee](https://github.com/openjdk/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
It is a trivial doc-only change to correct indentation alignment in the class
specificat
On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu wrote:
> Please review this doc only PR.
>
> java.text.DecimalFormat uses an implSpec tag in the middle of the class
> description. This location was on purpose as the contents related to the
> surrounding section. However, this ha
On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu wrote:
> Please review this doc only PR.
>
> java.text.DecimalFormat uses an implSpec tag in the middle of the class
> description. This location was on purpose as the contents related to the
> surrounding section. However, this ha
On Thu, 31 Jul 2025 23:21:17 GMT, Chen Liang wrote:
>> Please review this doc only PR.
>>
>> java.text.DecimalFormat uses an implSpec tag in the middle of the class
>> description. This location was on purpose as the contents related to the
>> surrounding section. However, this has caused slig
On Thu, 31 Jul 2025 22:30:35 GMT, Naoto Sato wrote:
>> Enabling lenient minus sign matching when parsing numbers. In some locales,
>> e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212),
>> which is not the "Hyphen Minus" (U+002D) that users type in from keyboard.
>> Thus
On Thu, 31 Jul 2025 22:04:56 GMT, Naoto Sato wrote:
>> Enabling lenient minus sign matching when parsing numbers. In some locales,
>> e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212),
>> which is not the "Hyphen Minus" (U+002D) that users type in from keyboard.
>> Thus
Please review this doc only PR.
java.text.DecimalFormat uses an implSpec tag in the middle of the class
description. This location was on purpose as the contents related to the
surrounding section. However, this has caused slight indentation in the rest of
the class description below the tag (a
On Tue, 22 Jul 2025 22:25:33 GMT, Naoto Sato wrote:
>> This PR removes the system property deprecated in JDK 25. If the property is
>> specified at runtime, a warning will be emitted at startup to inform the
>> user that the value is ignored. A corresponding CSR has been drafted as well
>
> Nao
On Tue, 22 Jul 2025 22:22:40 GMT, Naoto Sato wrote:
>> This PR removes the system property deprecated in JDK 25. If the property is
>> specified at runtime, a warning will be emitted at startup to inform the
>> user that the value is ignored. A corresponding CSR has been drafted as well
>
> Nao
On Tue, 22 Jul 2025 22:01:10 GMT, Naoto Sato wrote:
>> This PR removes the system property deprecated in JDK 25. If the property is
>> specified at runtime, a warning will be emitted at startup to inform the
>> user that the value is ignored. A corresponding CSR has been drafted as well
>
> Nao
On Mon, 21 Jul 2025 22:56:50 GMT, Naoto Sato wrote:
> This PR removes the system property deprecated in JDK 25. If the property is
> specified at runtime, a warning will be emitted at startup to inform the user
> that the value is ignored. A corresponding CSR has been drafted as well
Should we
On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigne
On Thu, 17 Jul 2025 19:06:25 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1769:
>>
>>> 1767: * fields (> 550 lines).
>>> 1768: */
>>> 1769: private static BinaryToASCIIConverter
>>> getCompatBinaryToASCIIConverter(doub
On Thu, 17 Jul 2025 12:28:06 GMT, Raffaello Giulietti
wrote:
>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Added comment to COMPAT st
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
On Fri, 13 Jun 2025 19:34:40 GMT, Johannes Graham wrote:
>> Ah got it, I see your point. We would have goten underflow in
>> `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a
>> check.
>>
>> Is there a specific example you have that requires the switch to the newer
>> c
On Thu, 12 Jun 2025 15:26:55 GMT, Johannes Graham wrote:
>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
>>
>>> 1839:
>>> 1840: static ASCIIToBinaryConverter readDoubleSignlessDigits(int
>>> decExp, char[] digits, int length) {
>>> 1841: if (decExp
On Mon, 9 Jun 2025 23:44:20 GMT, Justin Lu wrote:
>> Johannes Graham has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> catch ArithmeticException
>
> src/java.base/share/classes/jdk/internal/math/FloatingDeci
On Tue, 10 Jun 2025 15:41:47 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigne
On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato wrote:
> This regression was introduced by the removal of the COMPAT locale provider,
> which partially broke support for the first year in the Japanese calendar. In
> the Japanese calendar system, the first year of an era should be formatted
> usin
On Mon, 9 Jun 2025 22:46:50 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigned
On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato wrote:
>> The parallel loading of JavaTimeSupplementary was a historical artifact from
>> the introduction of JSR 310, which additionally loads resouces that had not
>> existed before. Since the COMPAT locale provider which relied on this
>> mechanis
On Sat, 7 Jun 2025 17:36:40 GMT, Johannes Graham wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review - Moving all ISO resources to LocaleISOData & blessed modifier
>> order for l
On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu wrote:
>> Please review this PR which improves occurrences of lazy computation in
>> `Locale` and `BaseLocale`.
>>
>> Existing lazy initialization strategies such as CHM, static nested class,
>> and local inner class a
On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu wrote:
> Please review this PR which improves occurrences of lazy computation in
> `Locale` and `BaseLocale`.
>
> Existing lazy initialization strategies such as CHM, static nested class, and
> local inner class are replaced wit
On Mon, 9 Jun 2025 18:17:45 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring t
On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg wrote:
> This PR proposes to simplify lazy computation related to resource bundles.
> Previously, some objects were computed lazily using a double-checked locking
> algorithm. StableValues offers a more robust and succinct solution.
>
>
> This P
On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg wrote:
> This PR proposes to simplify lazy computation related to resource bundles.
> Previously, some objects were computed lazily using a double-checked locking
> algorithm. StableValues offers a more robust and succinct solution.
>
>
> This P
represented as a SV. Also, I did not think it was necessary to maintain a
> SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
review - Moving all ISO resources to Loca
On Thu, 5 Jun 2025 11:50:01 GMT, Johannes Döbler wrote:
>> Please review this PR which improves occurrences of lazy computation in
>> `Locale` and `BaseLocale`.
>>
>> Existing lazy initialization strategies such as CHM, static nested class,
>> and local inner class are replaced with Stable Val
Please review this PR which improves occurrences of lazy computation in
`Locale` and `BaseLocale`.
Existing lazy initialization strategies such as CHM, static nested class, and
local inner class are replaced with Stable Values.
Lambda usage is intentionally avoided in this change during `Locale
On Tue, 3 Jun 2025 16:47:20 GMT, Justin Lu wrote:
> Please review this PR which modifies the
> test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be
> repurposed to check the implicit locales for the FALLBACK BreakIterator and
> Collator providers. (F
On Tue, 3 Jun 2025 17:13:45 GMT, Justin Lu wrote:
> Please review this trivial doc correction to
> `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent
> that the returned Set is unmodifiable. Associated CSR filed.
This pull request has now been integrated.
Please review this trivial doc correction to
`Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent
that the returned Set is unmodifiable. Associated CSR filed.
-
Commit messages:
- init
Changes: https://git.openjdk.org/jdk/pull/25622/files
Webrev: https://
On Tue, 3 Jun 2025 18:17:17 GMT, Naoto Sato wrote:
>> Please review this trivial doc correction to
>> `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent
>> that the returned Set is unmodifiable. Associated CSR filed.
>
> Looks good. Reviewed the CSR too, but not sure i
On Tue, 3 Jun 2025 17:40:19 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review - var rename
>
> test/jdk/java/util/TimeZone/Bug8167143.java line 239:
>
>>
Since
> the method is corrected, it can be re-added as a test case. This change stems
> from discussion in https://git.openjdk.org/jdk/pull/25532.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
review - var rename
--
Please review this PR which modifies the
test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed
to check the implicit locales for the FALLBACK BreakIterator and Collator
providers. (FALLBACK is the primary provider in those cases.) Since the method
is corrected, it can b
On Thu, 29 May 2025 21:59:30 GMT, Justin Lu wrote:
> Please review this PR which cleans up some i18n tests.
>
> There are some i18n related tests that set the locale provider to CLDR (and
> only CLDR). Since JDK9, this is redundant and equivalent to the default.
> Thus,
On Fri, 30 May 2025 17:02:12 GMT, Justin Lu wrote:
>> Please review this PR which cleans up some i18n tests.
>>
>> There are some i18n related tests that set the locale provider to CLDR (and
>> only CLDR). Since JDK9, this is redundant and equivalent to the default.
On Thu, 29 May 2025 19:01:04 GMT, Justin Lu wrote:
> Please review this PR which removes the test tool `GenerateKeyList.java`
> after the COMPAT locale data removal.
>
> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool.
> However, this tool is manual
On Fri, 30 May 2025 00:41:12 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> re-add testCompat to Bug8167143.java
>
> test/jdk/java/util/TimeZone/Bug8167143.java line 10
are just extra noise for
> these tests.
>
> As this change is trivial cleanup, bug IDs are not updated in this change.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
re-add testCompat to Bug8167143.java
-
Changes
On Thu, 29 May 2025 22:47:11 GMT, Naoto Sato wrote:
>> Please review this PR which cleans up some i18n tests.
>>
>> There are some i18n related tests that set the locale provider to CLDR (and
>> only CLDR). Since JDK9, this is redundant and equivalent to the default.
>> Thus, occurrences of "-
are just extra noise for
> these tests.
>
> As this change is trivial cleanup, bug IDs are not updated in this change.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
reflect review: strip othervm mode + cleanup
Please review this PR which cleans up some i18n tests.
There are some i18n related tests that set the locale provider to CLDR (and
only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus,
occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these
tests.
On Thu, 29 May 2025 16:54:01 GMT, Naoto Sato wrote:
> These resource files are remnants from the removal of the COMPAT locale
> provider. Since the COMPAT provider has been removed, these localizations
> should also be cleaned up.
Looks good.
-
Marked as reviewed by jlu (Committe
On Thu, 29 May 2025 21:15:57 GMT, Justin Lu wrote:
>> Please review this PR which removes the test tool `GenerateKeyList.java`
>> after the COMPAT locale data removal.
>>
>> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool.
>> However,
There is no longer any point to keep it, and it can always be retrieved via
> the VCS if needed.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
reflect some corrections
-
Changes:
- all: https://git.openjdk.org/jdk/pul
Please review this PR which updates the test tool `GenerateKeyList.java` after
the COMPAT locale data removal.
`LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool; the
latter requires similar bundle name changes that were made to the former in
https://bugs.openjdk.org/brows
On Mon, 19 May 2025 20:56:55 GMT, Justin Lu wrote:
> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts
> _extlang_ subtags in the input as well as what behavior occurs. Additionally,
> both this method and `Locale.forLanguageTag(String)` should mention their
> b
On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato wrote:
> Test refactoring stemmed from the discussion at
> https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is
> now based on UTF-8 instead of ISO-8859-1
Test change looks good. Skimmed the data change, which also looks to be
On Wed, 28 May 2025 17:00:22 GMT, Justin Lu wrote:
> Please review this PR which updates the language subtag registry to Version
> 2025-05-15.
>
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`,
> `eko`, `luh`,`sjc`, `sqm`. A small change was a
On Wed, 28 May 2025 17:00:22 GMT, Justin Lu wrote:
> Please review this PR which updates the language subtag registry to Version
> 2025-05-15.
>
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`,
> `eko`, `luh`,`sjc`, `sqm`. A small change was a
Please review this PR which updates the language subtag registry to Version
2025-05-15.
LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`,
`eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve
the output as well.
-
Commit message
On Mon, 26 May 2025 08:25:30 GMT, Magnus Ihse Bursie wrote:
>> After we converted the source base to be fully UTF-8, we do not need to use
>> unicode sequences (like \u0123) in string literals. Sometimes, that might
>> still make sense, as for control characters, non-breaking space, etc. But
>
On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen wrote:
> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will
> call the DigitList::toString method. At this time, DigitList::toString will
> modify tempBuilder, which will cause incorrect results.
Change looks good to me, si
On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote:
> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data
> carrier for Locale. The class, once created is not modified; the class should
> be made immutable. Converting the class to a record accomplishes this an
On Thu, 22 May 2025 17:51:32 GMT, Justin Lu wrote:
>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data
>> carrier for Locale. The class, once created is not modified; the class
>> should be made immutable. Converting the class to a record accomplishes
On Thu, 22 May 2025 17:14:03 GMT, Chen Liang wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review: subtag -> subtags, switch on baseLang, improve fragility of list
>> field
> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data
> carrier for Locale. The class, once created is not modified; the class should
> be made immutable. Converting the class to a record accomplishes this and
> also simplifies some of the existing code.
J
> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data
> carrier for Locale. The class, once created is not modified; the class should
> be made immutable. Converting the class to a record accomplishes this and
> also simplifies some of the existing code.
J
On Wed, 21 May 2025 21:19:36 GMT, Justin Lu wrote:
> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data
> carrier for Locale. The class, once created is not modified; the class should
> be made immutable. Converting the class to a record accomplishes this an
_sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier
for Locale. The class, once created is not modified; the class should be made
immutable. Converting the class to a record accomplishes this and also
simplifies some of the existing code.
-
Commit message
ovided. This PR
> clarifies the lack of context in the specification.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
CSR review - clarify that 3 extlang subtags is not a JDK specific condition
-
Changes:
On Tue, 20 May 2025 23:02:45 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> setLanguageTag should mention all conversions, not just extlang
>
> src/java.base/share/clas
ovided. This PR
> clarifies the lack of context in the specification.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
adjust example wording
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25309/files
On Tue, 20 May 2025 00:39:16 GMT, Naoto Sato wrote:
>> An exception is thrown when more than three extlang subtags are provided
>> (ill-formed). The new wording is when an allowed amount of extlang subtags
>> are provided (not ill-formed). For example,
>>
>> `new Locale.Builder().setLanguageTa
ovided. This PR
> clarifies the lack of context in the specification.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
setLanguageTag should mention all conversions, not just extlang
-
Changes:
- all: https://git.openj
On Mon, 19 May 2025 23:41:25 GMT, Naoto Sato wrote:
>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts
>> _extlang_ subtags in the input as well as what behavior occurs.
>> Additionally, both this method and `Locale.forLanguageTag(String)` should
>> mention their behavior
It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_
subtags in the input as well as what behavior occurs. Additionally, both this
method and `Locale.forLanguageTag(String)` should mention their behavior when
more than three _extlang_ subtags are provided. This PR clari
On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato wrote:
> Removing now-defunct COMPAT locale provider tests.
Nice cleanup; lgtm
test/jdk/sun/text/resources/LocaleDataTest.java line 178:
> 176: public class LocaleDataTest
> 177: {
> 178: static final String TEXT_RESOURCES_PACKAGE
> ="sun.text.
On Sun, 11 May 2025 08:42:41 GMT, Abhishek N wrote:
>> Create a Test case to have special cases coverage for currency.getInstance().
>>
>> The test Validates that all currency codes and country-currency mappings in
>> the input file are consistent with the Java Currency API.
>>
>> test results
On Wed, 14 May 2025 16:59:23 GMT, Phil Race wrote:
>> Non-breaking space characters are problematic. They look identical to the
>> normal space character, but is not. For that reason, it should never be
>> typed as an UTF-8 literal, but only by using unicode sequences.
>>
>> I have checked:
>>
On Wed, 26 Mar 2025 20:31:07 GMT, Justin Lu wrote:
> Please review this PR which clarifies the behavior for integer and fraction
> limits in NumberFormat and implementing classes. An associated CSR is filed.
>
> There have been a few bugs submitted which indicate a misconception t
On Sun, 11 May 2025 08:42:41 GMT, Abhishek N wrote:
>> Create a Test case to have special cases coverage for currency.getInstance().
>>
>> The test Validates that all currency codes and country-currency mappings in
>> the input file are consistent with the Java Currency API.
>>
>> test results
On Thu, 8 May 2025 23:30:06 GMT, Justin Lu wrote:
>> Please review this PR which stems from discussion in the PR of JDK-8347949.
>>
>> The set of lazily loaded Currencies is a good fit for stable values.
>> `available` can now be made final as it is a SV supplier.
On Thu, 8 May 2025 22:55:34 GMT, Justin Lu wrote:
> Please review this PR which stems from discussion in the PR of JDK-8347949.
>
> The set of lazily loaded Currencies is a good fit for stable values.
> `available` can now be made final as it is a SV supplier.
>
> (This ch
On Tue, 6 May 2025 07:25:36 GMT, Abhishek N wrote:
> Create a Test case to have special cases coverage for currency.getInstance().
>
> The test Validates that all currency codes and country-currency mappings in
> the input file are consistent with the Java Currency API.
>
> test results:
>
>
On Thu, 8 May 2025 23:08:27 GMT, Chen Liang wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Chen's review - method name clarification
>
> src/java.base/share/classes/java/uti
ts in
> `Currency::getCurrencies` to make the distinction for simple vs special
> Currencies.)
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
Chen's review - method name clarification
-
Changes:
- all: htt
Please review this PR which stems from discussion in the PR of JDK-8347949.
The set of lazily loaded Currencies is a good fit for stable values.
`available` can now be made final as it is a SV supplier.
(This change also includes an unrelated minor edit to comments in
`Currency::getCurrencies`
On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato wrote:
> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time
> zone data was downgraded by the TZUpdater tool in which some time zones are
> missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null,
> while `Tim
nd fraction parsing.
> 2) The limits affecting formatting only has been the long-standing behavior
> for all the subclasses of NumberFormat provided by the OpenJDK reference
> implementation.
Justin Lu has updated the pull request with a new target base due to a merge or
a rebase. T
On Fri, 2 May 2025 20:51:31 GMT, Justin Lu wrote:
> Please review this PR which implements ISO 4217 update 179.
>
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not
> _country_) entity. As a result it is not added as an entry in the country to
> curr
On Fri, 2 May 2025 20:51:31 GMT, Justin Lu wrote:
> Please review this PR which implements ISO 4217 update 179.
>
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not
> _country_) entity. As a result it is not added as an entry in the country to
> curr
On Fri, 2 May 2025 15:49:03 GMT, Justin Lu wrote:
> Please review this PR which reduces the amount of combinations tested by
> `LocaleNameProviderTest`.
>
> This test was exhaustively testing over 1000x1000 `Locale` combinations which
> was expensive and caused a timeout in ti
Please review this PR which implements ISO 4217 update 179.
The _Arab Accounting Dinar_ currency is added under an _agency_, (not
_country_) entity. As a result it is not added as an entry in the country to
currency mapping in `currencyData.properties`. It has a numeric code of 396,
and minor u
r.
>
> Most of the diff is attributed to separating the method source from the test
> itself. But notice the filtering of `Locale`s done on `availloc` and
> `jreImplLoc`.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
Please review this PR which reduces the amount of combinations tested by
`LocaleNameProviderTest`.
This test was exhaustively testing over 1000x1000 `Locale` combinations which
was expensive and caused a timeout in tier 5. Narrowing down the tested locales
to Japanese language ones can reduce o
On Mon, 21 Apr 2025 21:51:35 GMT, Justin Lu wrote:
> Please review this PR which improves future currency checking for ISO 4217
> currencies.
>
> Checking for a currency that should not yet exist in the set of available
> currencies is already done.
> It should also be expli
On Mon, 21 Apr 2025 22:25:14 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move future currencies set up under setUpTestingData()
>
> test/jdk/java/util/Currency
instantiated as well via the String getter.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
move future currencies set up under setUpTestingData()
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24782/files
- new: ht
Please review this PR which improves future currency checking for ISO 4217
currencies.
Checking for a currency that should not yet exist in the set of available
currencies is already done.
It should also be explicitly checked that such a currency can not be
instantiated as well via the String g
On Mon, 21 Apr 2025 20:11:47 GMT, Naoto Sato wrote:
> Adding @spec tags to Emoji related methods in the Character class. A CSR has
> also been drafted.
Marked as reviewed by jlu (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/24779#pullrequestreview-2782310737
On Wed, 16 Apr 2025 23:06:19 GMT, Justin Lu wrote:
> Please review this PR which improves the _ValidateISO4217_ Currency test by
> adding testing of future currencies after the transition date.
>
> This is done by creating a patched version of Currency t
On Thu, 17 Apr 2025 00:15:47 GMT, Naoto Sato wrote:
> > As the test tracks the ISO 4217 data, manual testing of this change can be
> > done by modifying the cut-over year from 2025 to 2026 for the
> > `CW=ANG;2025-04-01-04-00-00;XCG` entry for both the JDK and test data.
>
> Would it be possib
1 - 100 of 979 matches
Mail list logo
