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
e equivalent to
> `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency
> class files.
>
> The mocked time behavior is tested by using the `currency.properties`
> override in a separate invocation.
Justin Lu has updated the pull request incrementally with one add
On Thu, 17 Apr 2025 00:15:47 GMT, Naoto Sato 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 that replaces
>> `System.currentTime
On Thu, 17 Apr 2025 22:05:31 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> simple/special case in check invocation
>
> test/jdk/java/util/Currency/ValidateIS
e equivalent to
> `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency
> class files.
>
> The mocked time behavior is tested by using the `currency.properties`
> override in a separate invocation.
Justin Lu has updated the pull request incrementally with one add
e equivalent to
> `Long.MAX_VALUE`. A module patch is then applied to supply the new Currency
> class files.
>
> The mocked time behavior is tested by using the `currency.properties`
> override in a separate invocation.
Justin Lu has updated the pull request incrementally with one add
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
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 that replaces
`System.currentTimeMillis()` calls with a mocked value equivalent to
`Long.MAX_VALUE`.
On Wed, 16 Apr 2025 17:40:39 GMT, Johannes Graham wrote:
>> The `DigitList` class used in `DecimalFormat` does not reset the `data`
>> array in its clone method. This can cause interference when clones are used
>> concurrently.
>
> Johannes Graham has updated the pull request incrementally with
On Tue, 15 Apr 2025 14:43:56 GMT, Johannes Graham wrote:
>> The `DigitList` class used in `DecimalFormat` does not reset the `data`
>> array in its clone method. This can cause interference when clones are used
>> concurrently.
>
> Johannes Graham has updated the pull request incrementally with
On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bjørsnøs wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace InputStreamReader with BufferedReader
>
> FWIW, I checked out the revision
On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie wrote:
>> Justin Lu has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 16 commits:
>>
>> - Convert the merged master changes to UTF-8
>> -
On Fri, 4 Apr 2025 21:25:00 GMT, Justin Lu wrote:
> Please review this PR which improves some Currency
> `IllegalArgumentException`s by including the input in the message. This could
> be a currency code, country code, or locale. This change also includes tests
> to check the mes
On Wed, 2 Apr 2025 22:27:14 GMT, Justin Lu wrote:
> Please review this PR which provides unit tests for
> `ChoiceFormat#parse(String, ParsePosition)` to check default, multi match,
> and no match behavior. There were no existing relevant tests.
This pull request has now been i
On Wed, 2 Apr 2025 19:46:12 GMT, Justin Lu wrote:
>> Please review this PR which specifies the `ChoiceFormat#parse(String,
>> ParsePosition)` method. A corresponding CSR is filed. The current
>> specification is simply "Parses a Number from the input text" which d
On Tue, 1 Apr 2025 16:45:26 GMT, Justin Lu wrote:
> Please review this PR which specifies the `ChoiceFormat#parse(String,
> ParsePosition)` method. A corresponding CSR is filed. The current
> specification is simply "Parses a Number from the input text" which does not
>
Please review this PR which provides unit tests for `ChoiceFormat#parse(String,
ParsePosition)` to check default, multi match, and no match behavior. There
were no existing relevant tests.
-
Commit messages:
- more cases + cleanup
- init
Changes: https://git.openjdk.org/jdk/pull/
On Fri, 28 Mar 2025 20:17:30 GMT, Naoto Sato wrote:
> Proposing to remove the `java.locale.useOldISOCodes` system property. This
> property is for backward compatibility introduced back in JDK17 and I believe
> it is now fine to remove it. In this PR targeting JDK25, it emits a
> deprecate-for
ride as well
> as an invalid country code within a 3 length currency code.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
Naoto's review -> use str literal since not param test
-
Changes:
- all: https://git.ope
Please review this PR which improves some Currency `IllegalArgumentException`s
by including the input in the message. This could be a currency code, country
code, or locale. This change also includes tests to check the messages for an
invalid country via the region override as well as an invalid
> Please review this PR which provides unit tests for
> `ChoiceFormat#parse(String, ParsePosition)` to check default, multi match,
> and no match behavior. There were no existing relevant tests.
Justin Lu has updated the pull request incrementally with one additional commit
since
On Wed, 2 Apr 2025 10:05:04 GMT, Alan Bateman wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address further comments
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line
or a match, as well as no
> match should be made clear.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
Alan's review - Improve first sentence
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24361/files
- ne
On Tue, 1 Apr 2025 19:36:04 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect Naoto's review
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 5
or a match, as well as no
> match should be made clear.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
Address further comments
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24361/files
- new: https://git.openjdk
On Tue, 1 Apr 2025 18:17:12 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect Naoto's review
>
> src/java.base/share/classes/java/text/ChoiceFormat.java
or a match, as well as no
> match should be made clear.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
reflect Naoto's review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24361/files
- new: https://git.op
Please review this PR which specifies the `ChoiceFormat#parse(String,
ParsePosition)` method. A corresponding CSR is filed. The current specification
is simply "Parses a Number from the input text" which does not indicate how the
value is returned. The criteria for a match, as well as no match s
On Mon, 24 Mar 2025 21:21:20 GMT, Justin Lu wrote:
> Please review this specification update for `SimpleDateFormat` which
> explicitly specifies the behavior for 'reserved' pattern letters. This is a
> specification update and has the potential low risk of making an
&
On Mon, 24 Mar 2025 23:13:48 GMT, Justin Lu wrote:
>> Please review this specification update for `SimpleDateFormat` which
>> explicitly specifies the behavior for 'reserved' pattern letters. This is a
>> specification update and has the potential low risk of maki
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 incrementally with one additional commit
since the last
On Wed, 26 Mar 2025 22:35:25 GMT, Naoto Sato wrote:
>> That commentary is only in this method because of the non-obvious behavior
>> for the maximum integer digits. (The pattern does not change the
>> `maximumIntegerDigits`). Since not all users may read that section in the
>> class descriptio
On Wed, 26 Mar 2025 21:41:02 GMT, Naoto Sato 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 that
>> t
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 that these
limits impact parsing. The actual behavior is that these limits
On Wed, 19 Mar 2025 17:48:20 GMT, Naoto Sato wrote:
>> Upgrading the CLDR to version 47.0. A corresponding CSR has also been
>> drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Copyright year/bugid update
Spec chang
> Please review this specification update for `SimpleDateFormat` which
> explicitly specifies the behavior for 'reserved' pattern letters. This is a
> specification update and has the potential low risk of making an
> implementation non-compliant. Thus, an associated CS
Please review this specification update for `SimpleDateFormat` which explicitly
specifies the behavior for 'reserved' pattern letters. This is a specification
update and has the potential low risk of making an implementation
non-compliant. Thus, an associated CSR is filed.
-
Commit
On Fri, 21 Mar 2025 20:17:31 GMT, Naoto Sato wrote:
> Refining regex tests for Grapheme break so that every test case will run even
> with some failing ones.
Looks good
-
Marked as reviewed by jlu (Committer).
PR Review: https://git.openjdk.org/jdk/pull/24168#pullrequestreview-27
On Tue, 18 Mar 2025 18:37:17 GMT, Alexey Semenyuk wrote:
>> Follow up code cleanup for https://github.com/openjdk/jdk/pull/23936 PR.
>>
>> Details on cleanup actions are given in commit descriptions.
>
> @justin-curtis-lu PTAL. Is it a valid assumption that removing property keys
> from the mai
On Tue, 4 Mar 2025 01:37:57 GMT, Justin Lu wrote:
> Please review this PR and associated CSR which disallows passing null to 4
> `DecimalFormat` prefix/suffix setter methods.
>
> Currently these setters do not check the input String for null. When the
> prefix/suffix is
gt; non-functional as it will throw NPE for most operations.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
Make non-null apparent in param tag as well
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23880/fi
On Wed, 26 Feb 2025 22:18:17 GMT, Justin Lu wrote:
> Please review this PR which clarifies some behavior regarding NumberFormat
> grouping specifically in the grouping related methods.
>
> Please see the corresponding CSR for further detail. Note that an alternative
> would be
gt; non-functional as it will throw NPE for most operations.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
correct bug ID for test
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23880/files
- new: https://git.op
Please review this PR and associated CSR which disallows passing null to 4
`DecimalFormat` prefix/suffix setter methods.
Currently these setters do not check the input String for null. When the
prefix/suffix is null, any such DecimalFormat instances are effectively
non-functional as it will thr
On Tue, 25 Feb 2025 23:58:21 GMT, Justin Lu wrote:
> Please review this PR which prevents an `AIOOBE` from leaking out when
> `java.util.Calendar.Builder` is used to build a Japanese calendar with an era
> value too large.
>
> Note that we don't check under `BEFORE_MEIJ
On Thu, 27 Feb 2025 19:39:53 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Naoto review - include strict parsing example. Also remove 'might' wording
>
&g
ng NumberFormat
> subclasses to define this behavior how they want. IMO, I would expect
> `setGroupingUsed(boolean)` to affect both; a subclass could define
> `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed
> solution.
Justin Lu has updated the pull req
On Thu, 27 Feb 2025 16:37:59 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Naoto review - include strict parsing example. Also remove 'might' wording
>
&g
ng NumberFormat
> subclasses to define this behavior how they want. IMO, I would expect
> `setGroupingUsed(boolean)` to affect both; a subclass could define
> `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed
> solution.
Justin Lu has updated the pull req
Please review this PR which clarifies some behavior regarding NumberFormat
grouping specifically in the grouping related methods.
Please see the corresponding CSR for further detail. Note that an alternative
would be to specify this at the DecimalFormat level, allowing NumberFormat
subclasses t
negative values during normalization. See
> `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`.
>
> We also check against `eras.length` over `REIWA`/5 due to the possibility of
> additional eras via the property override or future eras in general.
On Wed, 26 Feb 2025 19:23:06 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Naoto - correct comment regarding REIWA, add test case for IAE check w/
>> additional era
On Wed, 26 Feb 2025 17:20:47 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Naoto - correct comment regarding REIWA, add test case for IAE check w/
>> additional era
negative values during normalization. See
> `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`.
>
> We also check against `eras.length` over `REIWA`/5 due to the possibility of
> additional eras via the property override or future eras in general.
Please review this PR which prevents an `AIOOBE` from leaking out when
`java.util.Calendar.Builder` is used to build a Japanese calendar with an era
value too large.
Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese
calendar ignores negative values during normalization. S
On Wed, 12 Feb 2025 19:34:19 GMT, Justin Lu wrote:
> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking
> out of the range accepting endpoints in `Locale.LanguageRange`.
>
> In the reported error case, the invalid range is a lone "-" which is `s
On Wed, 12 Feb 2025 23:07:26 GMT, Naoto Sato wrote:
>> Fixing the regression caused by the JDK-8342550 fix. Since the logging
>> facility depends on TimeZone class, it should not use the logging facility.
>> Replacing the logging with simple System.err.printf() will fix the issue.
>
> Naoto Sat
On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato wrote:
> Fixing the regression caused by the JDK-8342550 fix. Since the logging
> facility depends on TimeZone class, it should not use the logging facility.
> Replacing the logging with simple System.err.printf() will fix the issue.
lgtm
test/jdk/
On Wed, 12 Feb 2025 21:40:48 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Naoto's review - Include test in LanguageRangeTest instead. Additionally,
>> b
range ends with "-" first, avoids
> indexing the empty array.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
Naoto's review - Include test in LanguageRangeTest instead. Additionally,
bundle existing LRT
Please review this PR which prevents a (non-specified) `AIOOBE` from leaking
out of the range accepting endpoints in `Locale.LanguageRange`.
In the reported error case, the invalid range is a lone "-" which is `split`
into an empty array. Checking if the range ends with "-" first, avoids indexin
On Fri, 7 Feb 2025 20:11:06 GMT, Naoto Sato wrote:
>> src/java.base/share/native/libjli/args.c line 611:
>>
>>> 609: LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t));
>>> 610: if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName,
>>> wcCount) != 0) {
>>> 611:
On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato wrote:
>> This is a follow-on fix to
>> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java
>> launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so
>> the same processing is needed. Also, obsolete code for Win
On Fri, 7 Feb 2025 18:32:26 GMT, Naoto Sato wrote:
>> This is a follow-on fix to
>> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java
>> launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so
>> the same processing is needed. Also, obsolete code for Win
On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu wrote:
> Please review this PR which removes _sun.util.locale.ParseStatus_ which is a
> Locale helper class used for parsing language tags.
>
> Such usages should be replaced by _java.text.ParsePosition_ which has almost
> 1 to 1 beha
On Wed, 5 Feb 2025 22:51:45 GMT, Naoto Sato wrote:
>> Please review this PR which removes _sun.util.locale.ParseStatus_ which is
>> a Locale helper class used for parsing language tags.
>>
>> Such usages should be replaced by _java.text.ParsePosition_ which has almost
>> 1 to 1 behavior. Note
Please review this PR which removes _sun.util.locale.ParseStatus_ which is a
Locale helper class used for parsing language tags.
Such usages should be replaced by _java.text.ParsePosition_ which has almost 1
to 1 behavior. Note that this cleanup changes the exception message in
`Locale.caseFol
On Thu, 30 Jan 2025 19:27:30 GMT, Justin Lu wrote:
> Please review this PR which improves the performance of cut-over date
> checking when the user supplies a properties override via the
> `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a
> _java.time_
On Mon, 3 Feb 2025 19:01:50 GMT, Justin Lu wrote:
>> Please review this PR which improves the performance of cut-over date
>> checking when the user supplies a properties override via the
>> `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a
>>
On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan wrote:
> Hi all,
> The JMH test
> "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
> fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
> could not be parsed at index 17".
> The `ECT` standard for "Am
On Mon, 3 Feb 2025 18:05:51 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/util/Currency.java line 1182:
>>
>>> 1180: private static boolean isPastCutoverDate(String cutOver) {
>>> 1181: return System.currentTimeMillis() >
>>> 1182: LocalDateTi
> faster but not as concise.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
reflect review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23374/files
- new: https://git.openjdk.org/jdk/pull/23374/files/a71a31bc..f80
On Fri, 31 Jan 2025 18:43:58 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> generalize format comment
>
> src/java.base/share/classes/java/util/Currency.java line 1179:
> faster but not as concise.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
generalize format comment
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23374/files
- new: https://git.openjdk.org/jdk/pull/23374/files/0f1c27
On Thu, 30 Jan 2025 18:40:28 GMT, Brian Burkhalter wrote:
>> The change made for
>> [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated
>> `File.getCanonicalPath` to resolve symbolic links on Windows, but its
>> specification was not modified to reflect this. Here it is proposed
Please review this PR which improves the performance of cut-over date checking
when the user supplies a properties override via the `java.util.currency.data`
sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has
better performance. It should be noted that this method is o
On Thu, 16 Jan 2025 22:21:26 GMT, Justin Lu wrote:
> Please review this PR and CSR which adds a method to _java.util.Currency_
> which returns a stream of the available Currencies.
>
> The motivation can be found in the CSR.
This pull request has now been integrated.
Changes
On Wed, 29 Jan 2025 18:35:31 GMT, Justin Lu wrote:
>> Please review this PR and CSR which adds a method to _java.util.Currency_
>> which returns a stream of the available Currencies.
>>
>> The motivation can be found in the CSR.
>
> Justin Lu has updated the pull
On Thu, 30 Jan 2025 15:58:37 GMT, Brian Burkhalter wrote:
>> The change made for
>> [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated
>> `File.getCanonicalPath` to resolve symbolic links on Windows, but its
>> specification was not modified to reflect this. Here it is proposed
On Wed, 29 Jan 2025 20:42:30 GMT, Naoto Sato wrote:
> Force opening "tzmappings" file in text mode. Confirmed the fix with customer
> provided test case. Also replaced the file open function with the safer one.
Fix looks correct to force "text mode". Switch to `fopen_s` also looks good.
--
> Please review this PR and CSR which adds a method to _java.util.Currency_
> which returns a stream of the available Currencies.
>
> The motivation can be found in the CSR.
Justin Lu has updated the pull request with a new target base due to a merge or
a rebase. The pull request
On Thu, 23 Jan 2025 02:49:49 GMT, Justin Lu wrote:
> Please review this PR and CSR which add a pair of methods to
> _java.util.TimeZone_ that return a stream of the available IDs. See the CSR
> for the motivation.
>
> A number of existing tests are modified to use the n
On Fri, 24 Jan 2025 18:00:06 GMT, Justin Lu wrote:
>> Please review this PR and CSR which add a pair of methods to
>> _java.util.TimeZone_ that return a stream of the available IDs. See the CSR
>> for the motivation.
>>
>> A number of existing tests are modifi
On Fri, 24 Jan 2025 23:56:46 GMT, Justin Lu wrote:
> Please review this PR which improves the time measurement for cut-over time
> comparisons when building the available set of currencies in
> _java.util.Currency._ Currently, a new time was measured for each special
> case curre
On Mon, 27 Jan 2025 18:30:39 GMT, Justin Lu wrote:
>> Please review this PR which improves the time measurement for cut-over time
>> comparisons when building the available set of currencies in
>> _java.util.Currency._ Currently, a new time was measured for each special
>
On Mon, 27 Jan 2025 18:03:48 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect review
>
> src/java.base/share/classes/java/util/Currency.java line 447:
&
time for all such
> cases
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
reflect review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23309/files
- new: https://git.openjdk.org/jdk/pull/23309/files/9305f954..c4
On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu wrote:
> Please review this PR which is a backport of
> [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea)
> that updates the l10n translations for jdk24.
>
> The commit being backported was aut
On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu wrote:
> Please review this PR which is a backport of
> [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea)
> that updates the l10n translations for jdk24.
>
> The commit being backported was aut
Please review this PR which improves the time measurement for cut-over time
comparisons when building the available set of currencies in
_java.util.Currency._ Currently, a new time was measured for each special case
currency. This PR updates the behavior to use the same time for all such cases
Please review this PR which is a backport of
[dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea)
that updates the l10n translations for jdk24.
The commit being backported was authored by Justin Lu on 24 Jan 2025 and was
reviewed by Severin Gehwolf, Damon
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branc
On Wed, 22 Jan 2025 18:39:47 GMT, Justin Lu wrote:
>> Please review this PR which contains the l10n translations for between RDP1
>> and RDP2 for the JDK24 stabilization branch.
>>
>> Note that these translations are only associated with changes made to the
>>
DsTest.java_ which tests the new
> methods.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
new methods do not need to be synchronized
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23251/files
- new: https://git
On Thu, 16 Jan 2025 13:02:34 GMT, Andrey Turbanov wrote:
>> There are 3 methods in `java.util.TimeZone` which are `public static` and
>> marked as `synchronized`:
>> 1. getTimeZone(String)
>> 2. getAvailableIDs(int)
>> 3. getAvailableIDs()
>>
>> This means it is a bottle neck for the whole VM.
1 - 100 of 1120 matches
Mail list logo
