On Fri, 1 Aug 2025 22:19:22 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 16 commits:
>>
>> - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>
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 trivial doc-only ch
On Thu, 31 Jul 2025 23:58:46 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 354
On Fri, 1 Aug 2025 16:40:27 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> flipped again, which was correct
>
> src/java.base/share/classes/java/text/DecimalF
ut numbers may fail. This change utilizes CLDR's
> `parseLenient` element for minus signs and loosely matches them with the
> hyphen-minus so that user input numbers can parse. As this is a behavioral
> change, a corresponding CSR has been drafted.
Naoto Sato has updated the pull
ut numbers may fail. This change utilizes CLDR's
> `parseLenient` element for minus signs and loosely matches them with the
> hyphen-minus so that user input numbers can parse. As this is a behavioral
> change, a corresponding CSR has been drafted.
Naoto Sato has updated the
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 has caused slight ind
ut numbers may fail. This change utilizes CLDR's
> `parseLenient` element for minus signs and loosely matches them with the
> hyphen-minus so that user input numbers can parse. As this is a behavioral
> change, a corresponding CSR has been drafted.
Naoto Sato has updated the
ut numbers may fail. This change utilizes CLDR's
> `parseLenient` element for minus signs and loosely matches them with the
> hyphen-minus so that user input numbers can parse. As this is a behavioral
> change, a corresponding CSR has been drafted.
Naoto Sato has updated the
On Thu, 31 Jul 2025 20:55:01 GMT, Francesco Andreuzzi wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/java/text/DecimalFormatSymb
ut numbers may fail. This change utilizes CLDR's
> `parseLenient` element for minus signs and loosely matches them with the
> hyphen-minus so that user input numbers can parse. As this is a behavioral
> change, a corresponding CSR has been drafted.
Naoto Sato has updated the
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
the parsing of user input numbers may fail. This change utilizes
rg/jdk) repository.
>>
>> The commit being backported was authored by Alisen Chung on 30 Jul 2025 and
>> was reviewed by Justin Lu, Naoto Sato, Damon Nguyen and Alexey Semenyuk.
>>
>> Thanks!
>
> Alisen Chung has updated the pull request incrementally with one
On Sun, 27 Jul 2025 10:23:03 GMT, Tatsunori Uchino wrote:
> The addition to CharSequence will require static analysis to check for
> conflicts with implementation. It will also likely impact the CharBuffer spec.
Looking at the original JSR 204 issue:
https://bugs.openjdk.org/browse/JDK-4985217
On Fri, 25 Jul 2025 00:25:01 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.
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/2646
On Wed, 23 Jul 2025 16:48:13 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Obsolete comment correction
>
> src/java.base/share/classes/java/util/Locale.java line 53
> 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
Naoto Sato has updated the pull request incrementally
> 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
Naoto Sato has updated the pull request incrementally
On Tue, 22 Jul 2025 21:29:06 GMT, Justin Lu wrote:
> Should we also remove the test method,
> `ModuleTestUtil.runModuleWithLegacyCode` which passes the now defunct
> property to the process.
I thought about that, but decided to leave it as it is, just to make sure
everything works as before.
> 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
Naoto Sato has updated the pull request incrementally
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 request wi
On Sun, 20 Jul 2025 06:46:01 GMT, Alan Bateman wrote:
>> Since the decision of whether a console exists is dependent on the
>> implementation as specified,
>>
>>> Whether a virtual machine has a console is dependent upon the underlying
>>> platform
>>
>> And the existing wording in this parag
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
-
Commit messages:
- initial commit
Changes: https://g
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
1 - 100 of 1529 matches
Mail list logo
