On Fri, 18 Jul 2025 21:12:41 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:
>
> Refactoring to paramateriz
On Fri, 18 Jul 2025 19:58:30 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:
>
> Removed temporary comment
On Thu, 17 Jul 2025 18:26:14 GMT, Naoto Sato wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> Good to see this enhancement, Raffaell
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 Thu, 17 Jul 2025 07:40:28 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Wording modification
>
> src/java.base/share/classes/java/io/Console.java line 51:
>
On Tue, 15 Jul 2025 17:44:00 GMT, Xueming Shen wrote:
>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard
>> #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/),
>> plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>>
>> This P
On Tue, 15 Jul 2025 15:11:07 GMT, Xueming Shen wrote:
>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard
>> #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/),
>> plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>>
>> This P
On Tue, 15 Jul 2025 14:31:45 GMT, Xueming Shen wrote:
>> Maybe I missed it, but do we have anything to make it clear that it returns
>> null if either stdin or stdout are redirected?
>
> we do have wordings like " If the virtual machine is started from an
> interactive command line without redi
On Mon, 14 Jul 2025 20:13:06 GMT, Xueming Shen wrote:
>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard
>> #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/),
>> plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>>
>> This P
arification and tightening of the `java.io.Console` javadoc
> to reflect this behavior. We are separating the spec clarification because
> the fix itself may be backported to prior LTS releases without requiring a
> Maintenance Review process.
Naoto Sato has updated the pull reques
On Mon, 14 Jul 2025 17:57:22 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update test/jdk/java/io/Console/LocaleTest.java
>>
>> Co-authored-by: Andrey Tu
pl.java`; the rest of the
> changes are adjustments to test cases to reflect the updated behavior. A
> corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reflects review commen
On Mon, 14 Jul 2025 18:56:11 GMT, Justin Lu wrote:
>> This accompanies the fix for
>> [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts
>> `System.console()` to return a `Console` instance only when both standard
>> input and output are connected to a terminal. The ch
On Mon, 14 Jul 2025 07:54:31 GMT, Xueming Shen wrote:
>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard
>> #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/),
>> plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>>
>> This P
This accompanies the fix for
[JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts
`System.console()` to return a `Console` instance only when both standard input
and output are connected to a terminal. The change here is solely a
specification clarification and tightening
pl.java`; the rest of the
> changes are adjustments to test cases to reflect the updated behavior. A
> corresponding CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Update test/jdk/java/io/Console/L
In prior JDK releases, `System.console()` could return a `Console` instance
even when the JVM was not attached to an interactive terminal. This could lead
to confusion, particularly when input was not from a keyboard or output was
redirected, such as to or from a file or pipe, especially when us
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=1479
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=1479
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.system.issuetabpanels%3Acomment-tabpanel#comment-14796714).
On Mon, 7 Jul 2025 19:08:22 GMT, Naoto Sato wrote:
> Refining the description of "Unicode Scalar Value" in the `Character` class.
> The original description referenced the outdated Unicode 3.1 specification,
> which previously included the U+ notation but no longe
On Mon, 7 Jul 2025 20:24:21 GMT, Naoto Sato wrote:
>> Refining the description of "Unicode Scalar Value" in the `Character` class.
>> The original description referenced the outdated Unicode 3.1 specification,
>> which previously included the U+ notation but no
lossary, which defines the term more
> accurately. Additionally, replaced the obsolete `@spec` link to Unicode 3.1.0
> with a reference to the current Unicode Character Database.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
So
Refining the description of "Unicode Scalar Value" in the `Character` class.
The original description referenced the outdated Unicode 3.1 specification,
which previously included the U+ notation but no longer does. Updated the
reference to point to the Unicode glossary, which defines the term
On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote:
> The ICU4J component currently stores binary data files directly in the
> repository. This change replaces them with base64-encoded text files and
> converts them to binary during the build process
This pull request has been close
On Wed, 25 Jun 2025 18:51:52 GMT, Xueming Shen wrote:
> The root cause is an off-by-one bug introduced in an old change we made years
> ago for Pattern.CANON_EQ.
> See https://cr.openjdk.org/~sherman/regexCE/Note.txt for background info.
>
> As described in the writeup above the basic logic of
On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote:
> The ICU4J component currently stores binary data files directly in the
> repository. This change replaces them with base64-encoded text files and
> converts them to binary during the build process
> Just converting a binary fi
The ICU4J component currently stores binary data files directly in the
repository. This change replaces them with base64-encoded text files and
converts them to binary during the build process
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/26027/file
On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional
> commit since the las
On Mon, 23 Jun 2025 20:14:36 GMT, Naoto Sato wrote:
> Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
> where the delimiter is set to `null` even if the method throws an NPE.
This pull request has now been integrated.
Changeset: 74472764
Author: Naoto Sat
On Mon, 23 Jun 2025 20:14:36 GMT, Naoto Sato wrote:
> Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
> where the delimiter is set to `null` even if the method throws an NPE.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull
On Fri, 20 Jun 2025 18:44:47 GMT, Naoto Sato wrote:
>> Refactored the internal handling of `stdin/out/err.encoding` to allow
>> setting them only via command-line options by converting them into
>> `StaticProperty`. This change prevents unexpected behavior caused by
>>
Fixing the side-effect caused by calling `StringTokenizer.nextToken(null)`,
where the delimiter is set to `null` even if the method throws an NPE.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/25942/files
Webrev: https://webrevs.openjdk.org/?repo=j
On Mon, 23 Jun 2025 16:32:21 GMT, Alisen Chung wrote:
>> I am wondering the same thing. Perhaps because it is not intended for
>> general public, it's not in the [JDK tools
>> specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
>> If that was intentionally left
On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato wrote:
> Refactored the internal handling of `stdin/out/err.encoding` to allow setting
> them only via command-line options by converting them into `StaticProperty`.
> This change prevents unexpected behavior caused by applications
On Thu, 19 Jun 2025 11:03:43 GMT, Alan Bateman wrote:
> Latest version looks okay but I think better to drop the change to
> System.initPhase1.
Reverted the changes in the `System` class. Also, there were two sites that
used `StaticProperty` class outside the `java.base` module. I replaced the
.setProperty()`.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reflects review comments. Limits the usage of StaticProperty within java.base
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25860/files
- new: https://git
Hi Pavel,
On 6/18/25 4:29 AM, Pavel Rappo wrote:
The second question is about DateTimeFormatter. I recently had to
parse a date that resembles output of asctime: Sat Jul 16 02:03:55
+ 1994. It's fine and dandy until you parse a date in September.
That time format expects "Sep", while the for
On Wed, 18 Jun 2025 07:08:21 GMT, Volkan Yazici wrote:
> I've verified that all relevant occurrences of `std{in,err,out}.encoding` are
> covered, except the ones `src/java.base/share/classes/java/lang/System.java`,
> which, I presume, is left out intentionally.
Initially I left them as it is t
.setProperty()`.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Replaces a couple more
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25860/files
- new: https://git.openjdk.org/jdk/pull/25860/files/c5c93387..27862
On Wed, 18 Jun 2025 15:03:06 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/module-info.java line 287:
>>
>>> 285: jdk.jpackage,
>>> 286: jdk.jshell,
>>> 287: jdk.net;
>>
>> At some point we will need to re-visit all these qualified exports so that
>> java.base
.setProperty()`.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reflecting review comments
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25860/files
- new: https://git.openjdk.org/jdk/pull/25860/files/9d1dbf3a..c5c93
On Wed, 18 Jun 2025 09:47:57 GMT, Joel Sikström wrote:
> Should the other localizations for the launcher help text (in
> `launcher_.properties`) also be updated? I see that only the German,
> Japanese and Chinese localizations have been updated so far.
Those languages (de/ja/zh-CN) are the one
On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional
> commit since the las
Refactored the internal handling of `stdin/out/err.encoding` to allow setting
them only via command-line options by converting them into `StaticProperty`.
This change prevents unexpected behavior caused by applications modifying these
properties at runtime using `System.setProperty()`.
>
> The commit being backported was authored by Stuart Marks on 16 Jun 2025 and
> was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.
>
> Thanks!
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25858#pullrequestreview-2936524075
On Mon, 16 Jun 2025 16:36:43 GMT, Gautham Krishnan
wrote:
> Some methods in the java.time.chrono interfaces—ChronoLocalDate,
> ChronoLocalDateTime, and ChronoZonedDateTime—override methods from the
> java.time.temporal.Temporal interface that are documented to throw
> UnsupportedTemporalTypeE
On Thu, 12 Jun 2025 23:39:44 GMT, Stuart Marks wrote:
>> Add a note to String.trim pointing to the String.strip family of methods.
>>
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> Stuart Marks has updated the pull request incrementally with one additional
> commit since the
On Wed, 11 Jun 2025 10:43:47 GMT, Volkan Yazici wrote:
>> Passes the `Charset` read from the `stdin.encoding` system property while
>> creating `InputStreamReader` or `Scanner` instances for `System.in`.
>>
>> `stdin.encoding` is a recently added property for Java 25 in
>> [JDK-8350703](https:
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
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
On Thu, 12 Jun 2025 00:34:11 GMT, Stuart Marks wrote:
> I'd describe this as "space plus ASCII control characters." Would something
> like that make more sense?
Yeah, I think so
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25762#discussion_r2141368745
On Wed, 11 Jun 2025 23:43:40 GMT, Brian Burkhalter wrote:
>> Add a note to String.trim pointing to the String.strip family of methods.
>>
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> src/java.base/share/classes/java/lang/String.java line 3837:
>
>> 3835: *
>> 3836:
On Mon, 9 Jun 2025 19:04:23 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
&g
On Wed, 11 Jun 2025 07:46:09 GMT, Justin Lu wrote:
> So we are updating the CLDRConverter to adapt the old COMPAT style pattern:
> "" when using Japanese calendar for LONG or FULL `SimpleDateFormat`
> patterns, such that it can replicate the old "gannen" style which emits the 元.
Yes, that’
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 wh
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
using the character "元" rather than the numeral "1". The issue ari
On Mon, 9 Jun 2025 22:41:21 GMT, Johannes Graham wrote:
>> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not
>> throw NumberFormatException/ArithmeticException, but ParseException, so if
>> this piece of code need to throw something, it should be `ParseException`
>
> The `
On Mon, 9 Jun 2025 22:57:24 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed the bundle
>
> src/java.base/share/classes/sun/util/resources/Local
On Mon, 9 Jun 2025 22:03:37 GMT, Johannes Graham wrote:
>> The existing implementation does not throw
>> `NumberFormatException`/`ArithmeticException`, but `ParseException` if
>> parsing is failing. I would expect the same here.
>
> Sorry, I'm not seeing where the original could throw ParseExce
On Thu, 5 Jun 2025 00:10:57 GMT, Chen Liang wrote:
>> This one is a little odd. The parse methods that call `getLong` are not
>> supposed to throw `NumberFormatException` either. So wherever `getLong` is
>> called, it must be preceded by a check to `fitsIntoLong`, which should avoid
>> any exc
bundles now include those
> resources by default, removing the parallel loading mechanism simplifies the
> implementation
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed the bundle
-
Changes:
- all: https
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 mechanism
has been removed, and the CLDR resource bundles now include tho
On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato wrote:
> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource
> files in `java.base` are supposed to be US English only, but they also need
> to use UTF-8 as some of the names are non-ASCII (e.g., Türkiye)
This pull re
On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato wrote:
>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource
>> files in `java.base` are supposed to be US English only, but they also need
>> to use UTF-8 as some of the names are non-ASCII (e.g., Türkiye)
On Mon, 9 Jun 2025 15:52:24 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
>>
>
> The commit being backported was authored by Stuart Marks on 6 Jun 2025 and
> was reviewed by Naoto Sato.
>
> Thanks!
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25681#pullrequestreview-2906279687
On Fri, 6 Jun 2025 18:34:10 GMT, Stuart Marks wrote:
> Use a link of the form `System##stdin.encoding` to link directly to the
> system property's description.
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25676#pullrequestreview-2906011665
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 are replaced with Stable Values.
>
On Fri, 6 Jun 2025 06:57:20 GMT, Volkan Yazici wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> java.base/Gensrc.gmk comment
>
> make/modules/jdk.localedata/Gensrc.gmk line 49:
>
>
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
On Thu, 5 Jun 2025 18:32:34 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/util/Locale.java line 2578:
>>
>>> 2576: return Set.of(LocaleISOData.ISO3166_3);
>>> 2577: }
>>> 2578: });
>>
>> What about moving these four stable suppliers an
On Thu, 5 Jun 2025 01:42:00 GMT, Naoto Sato wrote:
>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource
>> files in `java.base` are supposed to be US English only, but they also need
>> to use UTF-8 as some of the names are non-ASCII (e.g., Türkiye)
&
> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource
> files in `java.base` are supposed to be US English only, but they also need
> to use UTF-8 as some of the names are non-ASCII (e.g., Türkiye)
Naoto Sato has updated the pull request incrementally with one a
On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato wrote:
> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource
> files in `java.base` are supposed to be US English only, but they also need
> to use UTF-8 as some of the names are non-ASCII (e.g., Türkiye)
Looks like th
On Tue, 3 Jun 2025 16:59:18 GMT, Naoto Sato wrote:
>> Fixing a regression caused by the fix to JDK-8356985. Although the fix in
>> `CharsetTest` was a clean-up and not the gist of the original issue, the
>> change seem to have caused not finding `SkippedException` at runt
On Mon, 2 Jun 2025 21:48:04 GMT, Naoto Sato wrote:
> Fixing a regression caused by the fix to JDK-8356985. Although the fix in
> `CharsetTest` was a clean-up and not the gist of the original issue, the
> change seem to have caused not finding `SkippedException` at runtime in
> c
On Tue, 3 Jun 2025 17:42:37 GMT, Magnus Ihse Bursie wrote:
>> I found a few other places in the code that can be cleaned up after the
>> conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to
> a merge or a rebase. The incremental webrev excludes
On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici wrote:
>> Passes the `Charset` read from the `stdin.encoding` system property while
>> creating `InputStreamReader` or `Scanner` instances for `System.in`.
>>
>> `stdin.encoding` is a recently added property for Java 25 in
>> [JDK-8350703](https:/
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.
Looks good. Reviewed the CSR too, but not sure it would
On Tue, 3 Jun 2025 17:52:13 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. (FALLBACK is the primary pr
On Tue, 3 Jun 2025 17:46:11 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. (FALLBACK is the primary pr
On Tue, 3 Jun 2025 05:48:30 GMT, SendaoYan wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use of OutputAnalyzer.shouldHaveExitValue() where appropriate
>
> test/jdk/java/io/Console/S
On Tue, 3 Jun 2025 06:13:35 GMT, Johannes Döbler wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use of OutputAnalyzer.shouldHaveExitValue() where appropriate
>
> test/jdk/java/io/C
so that the offending
> `SkippedException` can be replaced with JUnit's `Assumptions`. Also renamed
> the test case itself to reflect what's actually tested in it.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Use of Output
Fixing a regression caused by the fix to JDK-8356985. Although the fix in
`CharsetTest` was a clean-up and not the gist of the original issue, the change
seem to have caused not finding `SkippedException` at runtime in certain cases.
Changing the test to JUnit based so that the offending `Skippe
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.
>> Thus, occurrences of "-D
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
This pull request has now been integrated.
Changeset: 4fa4f1
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
Thanks for the reviews!
-
PR Comme
On Fri, 30 May 2025 00:20:26 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, occurrences of "-D
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, occurrences of "-Djava.
On Thu, 29 May 2025 21:19:31 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 manually used and was
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
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/25524/files
Webrev: https://webrevs.o
On Wed, 21 May 2025 20:41:43 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 behavior w
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 also made to the test
On Tue, 27 May 2025 19:32:33 GMT, Shaojin Wen wrote:
>> Classes such as java.lang.CharacterDataXXX have multiple static final
>> arrays, these are immutable, We should add `@Stable` and final to provide
>> information to the optimizer.
>
> Shaojin Wen has updated the pull request incrementally
On Fri, 16 May 2025 18:11:39 GMT, Naoto Sato wrote:
> `java.io.Console` uses the charset specified by the `stdout.encoding` system
> property for both input and output. While this is generally sufficient, since
> Console is intended for interactive terminal use, some platfo
On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato wrote:
>> `java.io.Console` uses the charset specified by the `stdout.encoding` system
>> property for both input and output. While this is generally sufficient,
>> since Console is intended for interactive terminal use, so
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.
LGTM
-
Marked
1 - 100 of 1506 matches
Mail list logo
