From jlu at openjdk.org  Fri Aug  1 00:14:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 00:14:54 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v2]
In-Reply-To: <-jShvVkEpQ1sPrcEvsMOTj-91dL1vm_ZFhw7NSUJ8jE=.7368c6c6-6126-410e-9fa7-b694122c9bc9@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <-jShvVkEpQ1sPrcEvsMOTj-91dL1vm_ZFhw7NSUJ8jE=.7368c6c6-6126-410e-9fa7-b694122c9bc9@github.com>
Message-ID: <Ni6ClTQjiga_f7aTHypy6lZwW3kXtOvuqtCubrInD_Y=.ec492568-d953-4f71-b38c-1064d7b890fb@github.com>

On Thu, 31 Jul 2025 22:04:56 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/text/DecimalFormat.java line 3544:

> 3542:             var t = text.substring(position, Math.min(tlen, position + alen))
> 3543:                 .replaceAll(lmsp, "-");
> 3544:             return t.regionMatches(0, a, 0, alen);

I presume the original solution was regex for all cases, and you made the single char case for the fast path. If you still have the perf benchmark handy, I wonder how a char by char approach would compare instead of regex. It would also simplify the code since it would be combining the slow and fast path. Although the perf is variable based on the affix string length vs lms length (11).


int i = 0;
for (; position + i < Math.min(tlen, position + alen); i++) {
    int tIndex = lms.indexOf(text.charAt(position + i));
    int aIndex = lms.indexOf(affix.charAt(i));
    // Non LMS. Match direct
    if (tIndex < 0 && aIndex < 0) {
        if (text.charAt(position + i) != affix.charAt(i)) {
            return false;
        }
    } else {
        // By here, at least one LMS. Ensure both LMS.
        if (tIndex < 0 || aIndex < 0) {
            return false;
        }
    }
}
// Return true if entire affix was matched
return i == alen;

test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 120:

> 118:         public void testLenientPrefix(String sign) throws ParseException {
> 119:             var df = new DecimalFormat(PREFIX, DFS);
> 120:             df.setStrict(false);

No need to set strict as false since `df` is lenient by default. If it was done for clarity, I think the method name already adequately indicates it is a lenient style test. Applies to CNF test as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246593124
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246491998

From liach at openjdk.org  Fri Aug  1 04:04:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 04:04:52 GMT
Subject: <i18n dev> RFR: 8364370: java.text.DecimalFormat specification
 indentation correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <RtytsHnkKk8cAYqZNrTKANOcYHj4H4Aq5oNmG6ynwlI=.5bf05824-fd37-41bb-95f1-444a9dd7af72@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> 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 indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

I assume this will be backported to 25. This does not happen on 24 but happens on 25 ea.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26585#pullrequestreview-3077580598

From duke at openjdk.org  Fri Aug  1 10:51:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 1 Aug 2025 10:51:54 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v4]
In-Reply-To: <m6z0vmAes7aQk4QpJsPqS18dcLczUkQ-_52aCm7vIvg=.dd097645-37a0-4398-b725-9230efbe9c1b@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <kkvOk-QQEqJ7Wk5E610EIQtemolyXErsu1y-ku1kRmw=.b7a066ef-9856-472f-9dda-0d31495eff9d@github.com>
 <m6z0vmAes7aQk4QpJsPqS18dcLczUkQ-_52aCm7vIvg=.dd097645-37a0-4398-b725-9230efbe9c1b@github.com>
Message-ID: <X_N_11FX5aBJWon5tOFe_knoDl-GeMkLKuD1xz1oRt0=.e97c9c51-98fa-4867-a970-d18f8b95d38d@github.com>

On Thu, 31 Jul 2025 22:08:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 1002:
>> 
>>> 1000: 
>>> 1001:         if (loadNumberData(locale) instanceof Object[] d &&
>>> 1002:             d[0] instanceof String[] numberElements) {
>> 
>> Should the size be validated here, before accessing `d[0]`?
>
> This should be fine, as there would be no situation where empty array would be returned: https://github.com/openjdk/jdk/blob/724e8c076e1aed05de893ef9366af0e62cc2ac2b/src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java#L223
> I modified the `else` case, where the field was not initialized, btw.

Thanks for checking

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2247668339

From jlu at openjdk.org  Fri Aug  1 16:42:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 16:42:56 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v4]
In-Reply-To: <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
Message-ID: <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>

On Thu, 31 Jul 2025 22:30:35 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   flipped again, which was correct

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 lenient
> 422:  * parsing is enabled.

IMO, the following is more clear.

`when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
`interpret minus sign patterns` -> `enable loose matching of minus sign patterns`

Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248412292

From jlu at openjdk.org  Fri Aug  1 17:18:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 17:18:53 GMT
Subject: <i18n dev> RFR: 8364370: java.text.DecimalFormat specification
 indentation correction
In-Reply-To: <cJD3ayzO-dHf5SY1_p1oFpGc9lEwC7XRmo2W12qkO8Q=.7e13b4b7-4769-4303-81ef-7b3873ccb750@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
 <cJD3ayzO-dHf5SY1_p1oFpGc9lEwC7XRmo2W12qkO8Q=.7e13b4b7-4769-4303-81ef-7b3873ccb750@github.com>
Message-ID: <8URx40uS_iH5AxhU_RRIOw7hormoEFui1qFmhfr-_x4=.dcf65c43-5b59-4d64-8a81-78c0501dc50b@github.com>

On Thu, 31 Jul 2025 23:21:17 GMT, Chen Liang <liach at openjdk.org> 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 indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
>> 
>> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.
>
> In fact, per the [specs](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#block-tags):
> 
>> The content of a block tag is any text following the tag up to, but not including, either the next block tag, or the end of the documentation comment.
> 
> It may be surprising that block tags have higher precedence over HTML headers. Just a note for the future.

Thanks @liach  for taking a look. Yes, I don't believe there should be anything preventing this from getting into 25 as well. 

I plan to integrate soon, but I want to make sure @naotoj is OK with the changes as well since he spotted the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26585#issuecomment-3145250840

From naoto at openjdk.org  Fri Aug  1 17:28:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 17:28:57 GMT
Subject: <i18n dev> RFR: 8364370: java.text.DecimalFormat specification
 indentation correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <g1ENZnrZFY3uf6f_nCK0FQepMb_Tksg2jC_gbtyFkMY=.4ae1aa65-a97b-43ef-94fc-be7b2d8ce09f@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> 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 indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

Looks fine. Thanks for the fix!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26585#pullrequestreview-3080033495

From rgiulietti at openjdk.org  Fri Aug  1 17:38:09 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Aug 2025 17:38:09 GMT
Subject: <i18n dev> RFR: 8362448: Make use of the
 Double.toString(double) algorithm in java.text.DecimalFormat [v6]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <TVUEpvw-2J6zEVENjg44GuyLqZ04Ut6CPWnFrHLMkU0=.4ba817f3-c8e5-460f-a676-95de04d20218@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge master.
 - Refactoring to paramaterized tests.
 - Removed temporary comment from tests.
 - Added tests.
 - Added comment to COMPAT static field.
 - Merge branch 'master' into 8362448
 - 8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
 - Remove some unused methods from FloatingDecimal.
 - Renamed compatibility config option.
 - Merge branch 'master' into dtoa
 - ... and 3 more: https://git.openjdk.org/jdk/compare/2ba8a06f...3fe001c1

-------------

Changes: https://git.openjdk.org/jdk/pull/26364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26364&range=05
  Stats: 190 lines in 7 files changed: 140 ins; 7 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/26364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26364/head:pull/26364

PR: https://git.openjdk.org/jdk/pull/26364

From jlu at openjdk.org  Fri Aug  1 18:46:02 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 18:46:02 GMT
Subject: <i18n dev> RFR: 8364370: java.text.DecimalFormat specification
 indentation correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <zcGPE3_eUPxeZ6ltxBpE2WQU2pDln6cADPMnzcn2cNY=.6936b240-af97-4086-ad99-f7c58cbfc480@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> 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 indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

Thanks Chen and Naoto. I will open the 25 stabilization backport shortly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26585#issuecomment-3145444401

From jlu at openjdk.org  Fri Aug  1 18:46:03 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 18:46:03 GMT
Subject: <i18n dev> Integrated: 8364370: java.text.DecimalFormat
 specification indentation correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <1jqueEZsuh8RS7bw5kGxElSzR_1_zd1gPYJ7i5pWezc=.05b3a952-3d7d-4225-bda6-fe76e554f306@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> 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 indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

This pull request has now been integrated.

Changeset: 8e921aee
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e921aee5abb20c240b45cb75b06fb1f316d8a1f
Stats:     13 lines in 1 file changed: 7 ins; 6 del; 0 mod

8364370: java.text.DecimalFormat specification indentation correction

Reviewed-by: liach, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/26585

From naoto at openjdk.org  Fri Aug  1 18:57:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 18:57:13 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v5]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <VYntO9YT8IQ663JWKIdx6ARzLTgTIaDSHiHSCd0pRW8=.37b4cd3e-f431-415e-a7d5-025b48f27557@github.com>

> 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 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 request incrementally with two additional commits since the last revision:

 - Spec update
 - Supplementary/CanonEq tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/38f3286f..d4bd416a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=03-04

  Stats: 36 lines in 3 files changed: 23 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From naoto at openjdk.org  Fri Aug  1 19:05:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 19:05:27 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v6]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>

> 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 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 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
 - Spec update
 - Supplementary/CanonEq tests
 - flipped again, which was correct
 - flipped the size check
 - Address review comments
 - Merge branch 'master' into JDK-8363972-Loose-matching-dash
 - tidying up
 - test location
 - spec update
 - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

-------------

Changes: https://git.openjdk.org/jdk/pull/26580/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=05
  Stats: 409 lines in 8 files changed: 373 ins; 21 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From naoto at openjdk.org  Fri Aug  1 19:11:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 19:11:01 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v4]
In-Reply-To: <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
 <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>
Message-ID: <I8l1yVAH-jRQXDFk9V3VtYqyd9bVpbsXD-BEclHClfE=.d4b76392-220e-4c83-b0e8-293eb086ea1e@github.com>

On Fri, 1 Aug 2025 16:40:27 GMT, Justin Lu <jlu at openjdk.org> 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/DecimalFormat.java line 422:
> 
>> 420:  * @implNote The default implementation follows the LDML specification for
>> 421:  * {@code parseLenient} elements to interpret minus sign patterns when lenient
>> 422:  * parsing is enabled.
> 
> IMO, the following is more clear.
> 
> `when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
> `interpret minus sign patterns` -> `enable loose matching of minus sign patterns`
> 
> Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.

Thanks, modified as you suggested. For the `parseLenient`, the problem is in the LDML document side, as there is no description for it, and their loose matching description is kind of incorrect (use [:DASH:], which is not the case here. So I just dropped it in this iteration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692643

From naoto at openjdk.org  Fri Aug  1 19:11:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 19:11:04 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v2]
In-Reply-To: <Ni6ClTQjiga_f7aTHypy6lZwW3kXtOvuqtCubrInD_Y=.ec492568-d953-4f71-b38c-1064d7b890fb@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <-jShvVkEpQ1sPrcEvsMOTj-91dL1vm_ZFhw7NSUJ8jE=.7368c6c6-6126-410e-9fa7-b694122c9bc9@github.com>
 <Ni6ClTQjiga_f7aTHypy6lZwW3kXtOvuqtCubrInD_Y=.ec492568-d953-4f71-b38c-1064d7b890fb@github.com>
Message-ID: <lgZ0vFWAH7KYZ_L_PS2ogkfKeVKPIjNPeun5eHxK2QM=.b8fce492-6ca6-4cbf-a32b-a2733b40262e@github.com>

On Thu, 31 Jul 2025 23:58:46 GMT, Justin Lu <jlu at openjdk.org> 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 3544:
> 
>> 3542:             var t = text.substring(position, Math.min(tlen, position + alen))
>> 3543:                 .replaceAll(lmsp, "-");
>> 3544:             return t.regionMatches(0, a, 0, alen);
> 
> I presume the original solution was regex for all cases, and you made the single char case for the fast path. If you still have the perf benchmark handy, I wonder how a char by char approach would compare instead of regex. It would also simplify the code since it would be combining the slow and fast path.
> 
> 
> int i = 0;
> for (; position + i < Math.min(tlen, position + alen); i++) {
>     int tIndex = lms.indexOf(text.charAt(position + i));
>     int aIndex = lms.indexOf(affix.charAt(i));
>     // Non LMS. Match direct
>     if (tIndex < 0 && aIndex < 0) {
>         if (text.charAt(position + i) != affix.charAt(i)) {
>             return false;
>         }
>     } else {
>         // By here, at least one LMS. Ensure both LMS.
>         if (tIndex < 0 || aIndex < 0) {
>             return false;
>         }
>     }
> }
> // Return true if entire affix was matched
> return i == alen;

Comparing string char-by-char is problematic, as it cannot handle supplementary and/or normalization, so it is not possible to combine those paths. Yes, regex is slow, but need to rely on it for those reasons. I believe 99.9% of the use cases fall into the affix length == 1, so I think it is OK.

> test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 120:
> 
>> 118:         public void testLenientPrefix(String sign) throws ParseException {
>> 119:             var df = new DecimalFormat(PREFIX, DFS);
>> 120:             df.setStrict(false);
> 
> No need to set strict as false since `df` is lenient by default. If it was done for clarity, I think the method name already adequately indicates it is a lenient style test. Applies to CNF test as well.

This was intentional. Although redundant, I wanted to make sure it is in lenient mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692543
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692479

From jlu at openjdk.org  Fri Aug  1 20:20:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 20:20:31 GMT
Subject: <i18n dev> [jdk25] RFR: 8364370: java.text.DecimalFormat
 specification indentation correction
Message-ID: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>

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 specification of DecimalFormat.

-------------

Commit messages:
 - Backport 8e921aee5abb20c240b45cb75b06fb1f316d8a1f

Changes: https://git.openjdk.org/jdk/pull/26603/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26603&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364370
  Stats: 13 lines in 1 file changed: 7 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26603/head:pull/26603

PR: https://git.openjdk.org/jdk/pull/26603

From jlu at openjdk.org  Fri Aug  1 20:23:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 20:23:00 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v4]
In-Reply-To: <I8l1yVAH-jRQXDFk9V3VtYqyd9bVpbsXD-BEclHClfE=.d4b76392-220e-4c83-b0e8-293eb086ea1e@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>
 <MiG-GBgAmxpwAoSrwD16zeY7QS_QJZkBp6IqLOG2xcA=.86525e07-d632-48ff-bed0-a26ce4d08ab2@github.com>
 <I8l1yVAH-jRQXDFk9V3VtYqyd9bVpbsXD-BEclHClfE=.d4b76392-220e-4c83-b0e8-293eb086ea1e@github.com>
Message-ID: <_16t2LaftunzLITOKdsg1nfd8eGiPjqrEzT_EZa2MVM=.68766205-163d-4969-bff8-5a0ea8a4b983@github.com>

On Fri, 1 Aug 2025 19:08:37 GMT, Naoto Sato <naoto at openjdk.org> 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 lenient
>>> 422:  * parsing is enabled.
>> 
>> IMO, the following is more clear.
>> 
>> `when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
>> `interpret minus sign patterns` -> `enable loose matching of minus sign patterns`
>> 
>> Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.
>
> Thanks, modified as you suggested. For the `parseLenient`, the problem is in the LDML document side, as there is no description for it, and their loose matching description is kind of incorrect (use [:DASH:], which is not the case here. So I just dropped it in this iteration.

I noticed that as well, so I could not think of a better alternative. I think dropping the element name is the right choice, less is more in this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248805340

From liach at openjdk.org  Fri Aug  1 20:25:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 20:25:53 GMT
Subject: <i18n dev> [jdk25] RFR: 8364370: java.text.DecimalFormat
 specification indentation correction
In-Reply-To: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
References: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
Message-ID: <QUQ0aEqnPMHrxRE5KESlpY4i1B6wddtCDNiG2ou-OGI=.a62d6bcf-5f59-42f6-ba40-222259243cc4@github.com>

On Fri, 1 Aug 2025 20:14:46 GMT, Justin Lu <jlu at openjdk.org> 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 change to correct indentation alignment in the class specification of DecimalFormat.

Thanks for this doc-only fix.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26603#pullrequestreview-3080473382

From naoto at openjdk.org  Fri Aug  1 21:05:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 21:05:54 GMT
Subject: <i18n dev> [jdk25] RFR: 8364370: java.text.DecimalFormat
 specification indentation correction
In-Reply-To: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
References: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
Message-ID: <6N64dFtlTH7krbIvCeLKNGcog8pgu-fDg9dteFRM6Tk=.84418e52-61ae-4680-bbe4-ad019e553250@github.com>

On Fri, 1 Aug 2025 20:14:46 GMT, Justin Lu <jlu at openjdk.org> 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 change to correct indentation alignment in the class specification of DecimalFormat.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26603#pullrequestreview-3080560105

From jlu at openjdk.org  Fri Aug  1 21:29:01 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 21:29:01 GMT
Subject: <i18n dev> [jdk25] Integrated: 8364370: java.text.DecimalFormat
 specification indentation correction
In-Reply-To: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
References: <4gIoo8JFxn5Euy0vedO_eiHZi_GxGAYPbPURelnMNZM=.ec8c52f0-b43e-44e9-a16b-3b4a06f1ee2e@github.com>
Message-ID: <_HdjNkbsv0E07OgyrW4gPoahGaHklLreUlXmDdrBnHg=.6ec5d378-de62-4603-be2b-60a793403056@github.com>

On Fri, 1 Aug 2025 20:14:46 GMT, Justin Lu <jlu at openjdk.org> 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 change to correct indentation alignment in the class specification of DecimalFormat.

This pull request has now been integrated.

Changeset: b5bec8db
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5bec8db3f11febcd3c8147571d84e9791c458d9
Stats:     13 lines in 1 file changed: 7 ins; 6 del; 0 mod

8364370: java.text.DecimalFormat specification indentation correction

Reviewed-by: liach, naoto
Backport-of: 8e921aee5abb20c240b45cb75b06fb1f316d8a1f

-------------

PR: https://git.openjdk.org/jdk/pull/26603

From jlu at openjdk.org  Fri Aug  1 22:44:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Aug 2025 22:44:59 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v6]
In-Reply-To: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
Message-ID: <nhUA6ScKF0Dkig1myEl3m5P1C8dnsdioCqTxp6NXm40=.e8629345-3631-4dbf-8f84-416bd9867275@github.com>

On Fri, 1 Aug 2025 19:05:27 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 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
>  - Spec update
>  - Supplementary/CanonEq tests
>  - flipped again, which was correct
>  - flipped the size check
>  - Address review comments
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - tidying up
>  - test location
>  - spec update
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

src/java.base/share/classes/java/text/DecimalFormat.java line 3512:

> 3510: 
> 3511:     /**
> 3512:      * {@return if the text matches the affix} In lenient mode, lenient

It's more clear to state that lenient minus signs in the affix match to lenient minus signs in the text. (Not just match to hyphen-minus.)

src/java.base/share/classes/java/text/DecimalFormat.java line 3543:

> 3541:             var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
> 3542:             var a = lmsp.matcher(affix).replaceAll("-");
> 3543:             var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))

I don't think this works. If you see my other comment regarding the test case and swap it such that `lenientMinusSign` is "-\u00E4" and the pattern (affix) includes "a\u0308" and we parse some text such as "\u00E41.5".

Then we have the following,


var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ); // Returns pattern [-?]
var a = lmsp.matcher(affix).replaceAll("-"); // Gets correctly normalized to "-"
// Incorrectly matches against "?1" and normalized to "-1" since the substring returned is indexed from 0 to 2.
var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))


That is, I think we need to substring after we have performed the normalization. Something such as,


var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
var a = lmsp.matcher(affix).replaceAll("-");
var t = lmsp.matcher(text).replaceAll("-");
return t.startsWith(a, position);


However, we will still run into issues later in DecimalFormat, as the position is incremented by the original prefix length.


        } else if (gotNegative) {
            position += negativePrefix.length();


So for "?1.5" we would start parsing at position = 2, erroneously returning "0.5". So further thought may be needed.

test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 128:

> 126:             .set(dfs, "-\u00E5");
> 127:         var df = new DecimalFormat("#.#;a\u0308#.#", dfs);
> 128:         assertEquals(df.parse("a\u03081.5"), -1.5);

This one confuses me, should it not be parsing "\u00E51.5" such that the test can check if canonical equivalence occurs when matching the text "\u00E5" to the affix "a\u0308"? Otherwise, we are just parsing the exact pattern we set? Also I think it should be "\u00E4", not "\u00E5".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248872126
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248949783
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248892644

From naoto at openjdk.org  Fri Aug  1 23:25:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Aug 2025 23:25:57 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v6]
In-Reply-To: <nhUA6ScKF0Dkig1myEl3m5P1C8dnsdioCqTxp6NXm40=.e8629345-3631-4dbf-8f84-416bd9867275@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
 <nhUA6ScKF0Dkig1myEl3m5P1C8dnsdioCqTxp6NXm40=.e8629345-3631-4dbf-8f84-416bd9867275@github.com>
Message-ID: <umxWb0-DaBBFVa87fkrxiV79LeQ8nH4yxslgOnocFrM=.5ff7950d-32a8-411b-b169-38817e97e86c@github.com>

On Fri, 1 Aug 2025 22:19:22 GMT, Justin Lu <jlu at openjdk.org> 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
>>  - Spec update
>>  - Supplementary/CanonEq tests
>>  - flipped again, which was correct
>>  - flipped the size check
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>>  - tidying up
>>  - test location
>>  - spec update
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 3543:
> 
>> 3541:             var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
>> 3542:             var a = lmsp.matcher(affix).replaceAll("-");
>> 3543:             var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))
> 
> I don't think this works. If you see my other comment regarding the test case and swap it such that `lenientMinusSign` is "-\u00E4" and the pattern (affix) includes "a\u0308" and we parse some text such as "\u00E41.5".
> 
> Then we have the following,
> 
> 
> var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ); // Returns pattern [-?]
> var a = lmsp.matcher(affix).replaceAll("-"); // Gets correctly normalized to "-"
> // Incorrectly matches against "?1" and normalized to "-1" since the substring returned is indexed from 0 to 2.
> var t = lmsp.matcher(text.substring(position, Math.min(tlen, position + alen)))
> 
> 
> That is, I think we need to substring after we have performed the normalization. Something such as,
> 
> 
> var lmsp = Pattern.compile("[" + lms + "]", Pattern.CANON_EQ);
> var a = lmsp.matcher(affix).replaceAll("-");
> var t = lmsp.matcher(text).replaceAll("-");
> return t.startsWith(a, position);
> 
> 
> However, we will still run into issues later in DecimalFormat, as the position is incremented by the original prefix length.
> 
> 
>         } else if (gotNegative) {
>             position += negativePrefix.length();
> 
> 
> So for "?1.5" we would start parsing at position = 2, erroneously returning "0.5". So further thought may be needed.

The current implementations assume the prefix/suffix lengths in a lot of places (no wonder), should be re-examined.

> test/jdk/java/text/Format/NumberFormat/LenientMinusSignTest.java line 128:
> 
>> 126:             .set(dfs, "-\u00E5");
>> 127:         var df = new DecimalFormat("#.#;a\u0308#.#", dfs);
>> 128:         assertEquals(df.parse("a\u03081.5"), -1.5);
> 
> This one confuses me, should it not be parsing "\u00E51.5" such that the test can check if canonical equivalence occurs when matching the text "\u00E5" to the affix "a\u0308"? Otherwise, we are just parsing the exact pattern we set? Also I think it should be "\u00E4", not "\u00E5".

That's correct. I think the simple case is not that simple. Need to rethink.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2249005477
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2249005036

From duke at openjdk.org  Sun Aug  3 13:37:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 3 Aug 2025 13:37:54 GMT
Subject: <i18n dev> RFR: 8364007: Add no-argument codePointCount method
 to CharSequence and String [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <7_hGRPSddpEvGRJxCGREDYZjqQ68_0rIPzHVV-NOjFA=.63974cf2-8f61-451d-a509-60727d065e29@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

Its author may have prioritized the versatility of the APIs.

> `codePointCount(0, length())`

This workaround is only effective if the instance expression is sufficiently short or can afford to be stored to a new temporary variable once. It can be a pain in the neck that you have to write the expression even twice to get the number of code points in the entire string instance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3148429115

From rgiulietti at openjdk.org  Mon Aug  4 13:59:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 4 Aug 2025 13:59:06 GMT
Subject: <i18n dev> RFR: 8362448: Make use of the
 Double.toString(double) algorithm in java.text.DecimalFormat [v7]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <A_9LersslZvDYc_zh6-wNSfB42TQ4xBvCSUc9WjLFqA=.e446b82b-3f5f-40de-a8b4-facd4e25a0e6@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into 8362448
 - Merge master.
 - Refactoring to paramaterized tests.
 - Removed temporary comment from tests.
 - Added tests.
 - Added comment to COMPAT static field.
 - Merge branch 'master' into 8362448
 - 8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
 - Remove some unused methods from FloatingDecimal.
 - Renamed compatibility config option.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/fc475553...d5cb9cf8

-------------

Changes: https://git.openjdk.org/jdk/pull/26364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26364&range=06
  Stats: 190 lines in 7 files changed: 140 ins; 7 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/26364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26364/head:pull/26364

PR: https://git.openjdk.org/jdk/pull/26364

From rriggs at openjdk.org  Mon Aug  4 16:13:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Aug 2025 16:13:57 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v6]
In-Reply-To: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
Message-ID: <e8CHDPohPv6YlEjeHZbS0zxcg9K4vrklc7sYsOr-R7I=.69f89236-7fb7-4192-81bd-350ab4b42626@github.com>

On Fri, 1 Aug 2025 19:05:27 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 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
>  - Spec update
>  - Supplementary/CanonEq tests
>  - flipped again, which was correct
>  - flipped the size check
>  - Address review comments
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - tidying up
>  - test location
>  - spec update
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

The description and CSR should be clearer that lenient parsing is enabled by default.
The CSR compatibility paragraph mentions this as the default "implementation"; it might be more smoothly described as lenient parsing. Mentioning "implementation" implies there might be another/different implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26580#issuecomment-3151397513

From rriggs at openjdk.org  Mon Aug  4 18:06:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Aug 2025 18:06:04 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v6]
In-Reply-To: <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
Message-ID: <eKIqkSeieZJDQQ-MrIF3bmPr4Ru6iQMuhrds2DDTFhs=.83566f80-2960-4c52-aa6f-8aed9fe8a525@github.com>

On Fri, 1 Aug 2025 19:05:27 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 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
>  - Spec update
>  - Supplementary/CanonEq tests
>  - flipped again, which was correct
>  - flipped the size check
>  - Address review comments
>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>  - tidying up
>  - test location
>  - spec update
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d

src/java.base/share/classes/java/text/DecimalFormat.java line 421:

> 419:  * returns a numerically greater value.
> 420:  *
> 421:  * @implNote The default implementation follows the LDML specification

You can remove "default".  `The implementation follows...`.
The default changes the sense to refer to the code implementing this class.

src/java.base/share/classes/java/text/DecimalFormat.java line 3522:

> 3520:         if (alen == 0) {
> 3521:             return true;
> 3522:         }

This seems suspect, a zero length affix seems like an error. And if there is an empty affix, subsequent code should not be doing replacement.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 721:

> 719:      * {@return the lenient minus signs}
> 720:      */
> 721:     String getLenientMinusSign() {

Singular vs plural might be confusing. Is it a single char or a set of chars returned in a string.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252223596
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252228223
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252195256

From naoto at openjdk.org  Mon Aug  4 23:57:28 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Aug 2025 23:57:28 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>

> 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 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 request incrementally with one additional commit since the last revision:

  refrects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/3682484d..31250ee4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=05-06

  Stats: 64 lines in 6 files changed: 21 ins; 13 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From naoto at openjdk.org  Mon Aug  4 23:57:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Aug 2025 23:57:30 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v6]
In-Reply-To: <eKIqkSeieZJDQQ-MrIF3bmPr4Ru6iQMuhrds2DDTFhs=.83566f80-2960-4c52-aa6f-8aed9fe8a525@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <oapagKkmdWrBMjZKfjwriyv2qqUL16z6gB0Q2D_aeig=.5c56f763-fa25-400c-98be-18e10895407a@github.com>
 <eKIqkSeieZJDQQ-MrIF3bmPr4Ru6iQMuhrds2DDTFhs=.83566f80-2960-4c52-aa6f-8aed9fe8a525@github.com>
Message-ID: <lptJJdUHr0ZZyGxmaHpD6QRGXLKLYFxQ5DjtnXlVeXI=.b432abb4-f39d-4ff1-b294-7cfce5f50c34@github.com>

On Mon, 4 Aug 2025 17:58:29 GMT, Roger Riggs <rriggs at openjdk.org> 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
>>  - Spec update
>>  - Supplementary/CanonEq tests
>>  - flipped again, which was correct
>>  - flipped the size check
>>  - Address review comments
>>  - Merge branch 'master' into JDK-8363972-Loose-matching-dash
>>  - tidying up
>>  - test location
>>  - spec update
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8e921aee...3682484d
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 3522:
> 
>> 3520:         if (alen == 0) {
>> 3521:             return true;
>> 3522:         }
> 
> This seems suspect, a zero length affix seems like an error. And if there is an empty affix, subsequent code should not be doing replacement.

This is expected. Since prefix/suffix in the format patterns are optional, empty prefix/suffix should match the text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252809269

From naoto at openjdk.org  Tue Aug  5 00:01:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 00:01:04 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
Message-ID: <eJu0sdtAbon0o_uibpr0DXHz9dJv7QYLvgmCj5KlQrQ=.102252d4-3c11-4ebd-88e6-19099b371c71@github.com>

On Mon, 4 Aug 2025 23:57:28 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   refrects review comments

OK, I decided to explictly exclude those supplementary/normalization cases where the affix lengths would change. If we wanted to make it work with supplementary/normalization, it needs to account for the variable affix length and needs lots of changes in DecimalFormat/CompactNumberFormat, and I think not worth it (complex changes for non-existent leniency). So I adopted Justin's char based iteration (thanks!). Test has been modified to explicitly verify this behavior (for supplementary, normalization is obvious)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26580#issuecomment-3152835000

From vyazici at openjdk.org  Tue Aug  5 08:37:57 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 08:37:57 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set the
 replacement character
Message-ID: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>

Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.

-------------

Commit messages:
 - Add test to verify `CodingErrorAction.REPLACE` for all charsets
 - Fix incorrect `HKSCS::repl` override

Changes: https://git.openjdk.org/jdk/pull/26635/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364365
  Stats: 483 lines in 3 files changed: 472 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26635/head:pull/26635

PR: https://git.openjdk.org/jdk/pull/26635

From vyazici at openjdk.org  Tue Aug  5 08:38:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 08:38:02 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
Message-ID: <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>

On Tue, 5 Aug 2025 08:17:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.

test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 1:

> 1: /*

Without the `HKSCS` fix, this test fails for following charsets:

    Big5-HKSCS
    x-Big5-HKSCS-2001
    x-MS950-HKSCS
    x-MS950-HKSCS-XP

test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 139:

> 137:             return coderResult.isUnmappable();
> 138:         };
> 139:     }

I'd appreciate it if you can double-check these _"Is the given `char[]` unmappable for a particular encoder?"_ test generators.

test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 145:

> 143:      * different from the given unmappable and the default one.
> 144:      */
> 145:     static byte[] findCustomReplacement(CharsetEncoder encoder, byte[] unmappable) {

I'd appreciate it if you can double-check this method.

test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 50:

> 48:  * @build TestEncoderReplaceLatin1
> 49:  * @run junit/timeout=10 TestEncoderReplaceUTF16
> 50:  * @run junit/timeout=10/othervm -XX:-CompactStrings TestEncoderReplaceUTF16

1. Exercising both compact and inflated layouts for UTF-16.
2. Timeouts ensure that if the `CHARSETS_WITHOUT_UNMAPPABLE` fast-path in `findUnmappableNonLatin1()` becomes ineffective, we will get to know

test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 140:

> 138:      * Finds an {@linkplain CoderResult#isUnmappable() unmappable} non-Latin-1 {@code char[]} for the given encoder.
> 139:      */
> 140:     private static char[] findUnmappableNonLatin1(CharsetEncoder encoder) {

I'd appreciate it if you can double-check this method.

test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 146:

> 144:             System.err.println("Character set is known to be absent of unmappable non-Latin-1 characters!");
> 145:             return null;
> 146:         }

Without this fast-path, this test take several minutes to complete due to `findUnmappableNonLatin1()` taking ~20 seconds for each character set absent of unmappable Latin-1 characters.

test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 184:

> 182:         }
> 183:         return sa;
> 184:     }

Used `JavaLangAccess::uncheckedPutCharUTF16` to, given a `char[]`, extract the `byte[]` backing the associated `String`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253526576
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253550878
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253554481
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253532986
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253556174
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253530248
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2253542908

From jlu at openjdk.org  Tue Aug  5 17:15:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Aug 2025 17:15:07 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
Message-ID: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>

On Mon, 4 Aug 2025 23:57:28 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   refrects review comments

Latest changes look good to me. I think ignoring supplementary/normalization is fine and it would have been excessive otherwise. I left some more minor comments.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 219:

> 217:  * </pre></blockquote>
> 218:  *
> 219:  * @implNote The implementation follows the LDML specification to enable loose

Suggestion:

 * @implNote The JDK Reference Implementation follows the LDML specification to enable loose

src/java.base/share/classes/java/text/DecimalFormat.java line 421:

> 419:  * returns a numerically greater value.
> 420:  *
> 421:  * @implNote The implementation follows the LDML specification to enable loose

Suggestion:

 * @implNote The JDK Reference Implementation follows the LDML specification to enable loose

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 719:

> 717: 
> 718:     /**
> 719:      * {@return the lenient minus signs} Multiple lenient minus signs

Do we have an idea of when a given locale would not have access to the lenient minus signs provided by parseLenient element? If the vast majority of times it will, then it is fine. Otherwise IMO, `getLenientMinusSigns()` should probably call out the fact that it may not always be a concatenation of multiple minus _signs_, and it may be a single minus _sign_ (as assigned by `minusSignText`). Since that detail is only apparent by digging around the code that assigns `lenientMinusSigns`.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 720:

> 718:     /**
> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
> 720:      * are concatenated to form the returned string.

The surrounding package private methods use since tags.

Suggestion:

     * are concatenated to form the returned string.
     * @since 26

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 852:

> 850: 
> 851:         // Lenient minus signs
> 852:         lenientMinusSigns = numberElements.length < 14 ? minusSignText : numberElements[13];

BTW, if I remove this check and always assign to `numberElements[13]`, I do not observe any failures in the java_text/Format suite. It would be nice to have an idea of why this check is needed. (I understand it is following the same length checks of monetarySeparator and monetaryGroupingSeparator.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/26580#pullrequestreview-3086137609
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2252827372
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254807654
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254847469
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254792967
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254846860

From rriggs at openjdk.org  Tue Aug  5 17:42:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 17:42:50 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
Message-ID: <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>

On Tue, 5 Aug 2025 00:12:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refrects review comments
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 219:
> 
>> 217:  * </pre></blockquote>
>> 218:  *
>> 219:  * @implNote The implementation follows the LDML specification to enable loose
> 
> Suggestion:
> 
>  * @implNote The JDK Reference Implementation follows the LDML specification to enable loose

However,  "The JDK Reference Implementation" is a very specific and separate deliverable of the JCP.
That's why I suggest just stating that lenient is enabled without trying to attach it to an artifact.
As at line 421.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254949045

From rriggs at openjdk.org  Tue Aug  5 17:55:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 17:55:05 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
Message-ID: <0AgAaLT3JhkEFbK5q7INzdxBjPPlJUaTVBz9REtNzz4=.b0dced9c-49b1-42c3-af57-b4d58645383a@github.com>

On Mon, 4 Aug 2025 23:57:28 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   refrects review comments

src/java.base/share/classes/java/text/DecimalFormat.java line 3518:

> 3516:      * @implNote The implementation does not account for lenient minuses
> 3517:      * in non-BMP ranges or normalizations, as these could change the affix
> 3518:      * length.

@implNote isn't really appropriate here since this is a non-javadoc method.
And I don't understand what "does not account" mean in this context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254956628

From rriggs at openjdk.org  Tue Aug  5 17:55:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 17:55:06 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
Message-ID: <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>

On Tue, 5 Aug 2025 16:28:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refrects review comments
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 720:
> 
>> 718:     /**
>> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
>> 720:      * are concatenated to form the returned string.
> 
> The surrounding package private methods use since tags.
> 
> Suggestion:
> 
>      * are concatenated to form the returned string.
>      * @since 26

It might be clearer to say that each character of the string is a valid minus sign character.
If you want to preserve the option for full support for surrogates it could say codepoints instead of character.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2254967444

From jlu at openjdk.org  Tue Aug  5 18:26:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Aug 2025 18:26:06 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>
Message-ID: <nCCgWWShuRVNzrf0KoUo34L7NiWDZj2yp2izVXGHDUQ=.7ccc8ff9-8d37-4747-adf3-e7d7dd61af45@github.com>

On Tue, 5 Aug 2025 17:49:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 720:
>> 
>>> 718:     /**
>>> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
>>> 720:      * are concatenated to form the returned string.
>> 
>> The surrounding package private methods use since tags.
>> 
>> Suggestion:
>> 
>>      * are concatenated to form the returned string.
>>      * @since 26
>
> It might be clearer to say that each character of the string is a valid minus sign character.
> If you want to preserve the option for full support for surrogates it could say codepoints instead of character.

I agree. I think that is a good wording update which naturally covers both the single and multiple minus signs case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255034183

From jlu at openjdk.org  Tue Aug  5 18:39:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Aug 2025 18:39:08 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
Message-ID: <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>

On Tue, 5 Aug 2025 17:39:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 219:
>> 
>>> 217:  * </pre></blockquote>
>>> 218:  *
>>> 219:  * @implNote The implementation follows the LDML specification to enable loose
>> 
>> Suggestion:
>> 
>>  * @implNote The JDK Reference Implementation follows the LDML specification to enable loose
>
> However,  "The JDK Reference Implementation" is a very specific and separate deliverable of the JCP.
> That's why I suggest just stating that lenient is enabled without trying to attach it to an artifact.
> As at line 421.

The way I interpreted this was that Naoto was not trying to imply that the default behavior of the class enabled loose matching of lenient minus parsing signs. Rather, he was describing that the JDK reference implementation of DecimalFormat and CompactNumberFormat support the ability for loose matching of minus sign patterns (and other JDKs need not implement this particular LMDL behavior).

If I interpreted that wrong and his intentions were the former, then I agree it is best to just mention leniency.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255058461

From rriggs at openjdk.org  Tue Aug  5 19:44:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Aug 2025 19:44:09 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
 <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>
Message-ID: <owQ-_K_KjtaFQr7GFYri3wWxKEFIDI_eeTg1rwDg7vU=.ceb602b2-fefa-4651-83f6-16ec861a75e9@github.com>

On Tue, 5 Aug 2025 18:36:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> However,  "The JDK Reference Implementation" is a very specific and separate deliverable of the JCP.
>> That's why I suggest just stating that lenient is enabled without trying to attach it to an artifact.
>> As at line 421.
>
> The way I interpreted this was that Naoto was not trying to imply that the default behavior of the class enabled loose matching of lenient minus parsing signs. Rather, he was describing that the JDK reference implementation of DecimalFormat and CompactNumberFormat support the ability for loose matching of minus sign patterns (and other JDKs need not implement this particular LMDL behavior).
> 
> If I interpreted that wrong and his intentions were the former, then I agree it is best to just mention leniency.

The spec for enabling lenient matching in parsing of minus signs belongs with the other comments about leniency in the `parse()` method. Its behavior depends on the settings in the isStrict and setStrict methods.
It looks a bit out of context in the class javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255182114

From naoto at openjdk.org  Tue Aug  5 22:35:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:35:58 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v8]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>

> 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 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 request incrementally with one additional commit since the last revision:

  Refining docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/31250ee4..b9b0820f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=06-07

  Stats: 24 lines in 3 files changed: 10 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From naoto at openjdk.org  Tue Aug  5 22:56:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:56:03 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <owQ-_K_KjtaFQr7GFYri3wWxKEFIDI_eeTg1rwDg7vU=.ceb602b2-fefa-4651-83f6-16ec861a75e9@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <H177jhbRYSWJovxly3sMnc9rUoKWwusX65a7wQyaOgE=.8f1cbc4f-3c73-4270-8577-36863ea32b42@github.com>
 <RywjGlwSqZ46Mh6g-c4i1RbCwD0McZBiQCTzq4jREp4=.4b92904e-c745-4a4f-85b2-fde0ceab2538@github.com>
 <owQ-_K_KjtaFQr7GFYri3wWxKEFIDI_eeTg1rwDg7vU=.ceb602b2-fefa-4651-83f6-16ec861a75e9@github.com>
Message-ID: <5b4PScAq8QXuOFqkhBsNMe2y7VyccYORtE_IIOkA-ro=.38736426-7fcd-4d26-a990-098721bb3b46@github.com>

On Tue, 5 Aug 2025 19:41:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The way I interpreted this was that Naoto was not trying to imply that the default behavior of the class enabled loose matching of lenient minus parsing signs. Rather, he was describing that the JDK reference implementation of DecimalFormat and CompactNumberFormat support the ability for loose matching of minus sign patterns (and other JDKs need not implement this particular LMDL behavior).
>> 
>> If I interpreted that wrong and his intentions were the former, then I agree it is best to just mention leniency.
>
> The spec for enabling lenient matching in parsing of minus signs belongs with the other comments about leniency in the `parse()` method. Its behavior depends on the settings in the isStrict and setStrict methods.
> It looks a bit out of context in the class javadoc.

Moved the description into each concrete classes' "Negative Subpattern" section, dropping the implNote and adding the link to the leniency section in `NumberFormat`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492346

From naoto at openjdk.org  Tue Aug  5 22:56:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:56:05 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
Message-ID: <akqzBE4RPlOWiNXxFB1uksD4hPhVS5yxZUJMsgGYnzs=.c7d67a06-0d44-4a27-ac7e-fcd073247e37@github.com>

On Tue, 5 Aug 2025 16:53:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refrects review comments
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 719:
> 
>> 717: 
>> 718:     /**
>> 719:      * {@return the lenient minus signs} Multiple lenient minus signs
> 
> Do we have an idea of when a given locale would not have access to the lenient minus signs provided by parseLenient element? If the vast majority of times it will, then it is fine. Otherwise IMO, `getLenientMinusSigns()` should probably call out the fact that it may not always be a concatenation of multiple minus _signs_, and it may be a single minus _sign_ (as assigned by `minusSignText`). Since that detail is only apparent by digging around the code that assigns `lenientMinusSigns`.

The lenient minus signs are embedded in number elements for the Laitn script (latn.NumberElements), so they are mostly in each locale data.

> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 852:
> 
>> 850: 
>> 851:         // Lenient minus signs
>> 852:         lenientMinusSigns = numberElements.length < 14 ? minusSignText : numberElements[13];
> 
> BTW, if I remove this check and always assign to `numberElements[13]`, I do not observe any failures in the java_text/Format suite. It would be nice to have an idea of why this check is needed. (I understand it is following the same length checks of monetarySeparator and monetaryGroupingSeparator.)

The FALLBACK locale provider does not provide those elements, so the check is needed. Some tests in java/sun.util tests that specify HOST provider would fail without it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492762
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492528

From naoto at openjdk.org  Tue Aug  5 22:56:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Aug 2025 22:56:05 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <nCCgWWShuRVNzrf0KoUo34L7NiWDZj2yp2izVXGHDUQ=.7ccc8ff9-8d37-4747-adf3-e7d7dd61af45@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <IcLAo7eeyILz7PVdfKlMnGKWR7b-skbDyvFgRe5XRkU=.bae8b1f4-d0dd-4ae8-aa32-bac05a1beafd@github.com>
 <nCCgWWShuRVNzrf0KoUo34L7NiWDZj2yp2izVXGHDUQ=.7ccc8ff9-8d37-4747-adf3-e7d7dd61af45@github.com>
Message-ID: <c4BFgvOK7uP64cQbg3ocK_mRQZrmSkjZ5CXzl1KYcUo=.bc6d99bb-44a0-4234-93dc-a87e487746f9@github.com>

On Tue, 5 Aug 2025 18:23:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> It might be clearer to say that each character of the string is a valid minus sign character.
>> If you want to preserve the option for full support for surrogates it could say codepoints instead of character.
>
> I agree. I think that is a good wording update which naturally covers both the single and multiple minus signs case.

Clarified. (did not add @since, as this is an internal method)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255494170

From sherman at openjdk.org  Wed Aug  6 00:29:04 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 6 Aug 2025 00:29:04 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
Message-ID: <V-7Iy_-V_6dMGXFsLNxNuTKtxtpfGrteQTSL33NH6d4=.d333533a-2b5c-4ab7-9afd-da51c5b37c53@github.com>

On Tue, 5 Aug 2025 08:29:21 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.
>
> test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 139:
> 
>> 137:             return coderResult.isUnmappable();
>> 138:         };
>> 139:     }
> 
> I'd appreciate it if you can double-check these _"Is the given `char[]` unmappable for a particular encoder?"_ test generators.

I might be missing something you're trying to do here,  but any reason why we can't just go

  return c -> !encoder.canEncode(c[0]);

as the predicate? I think we are doing 'single char', no surrogates,  here, right?

or simply do with

    private static char[] findUnmappable(CharsetEncoder encoder) {
        for (char c = 0; c < 0xff; c++) {
            if (!encoder.canEncode(c))
                return new char[]{c};
        }
        System.err.println("Could not find an unmappable character!");
        return null;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2255587104

From sherman at openjdk.org  Wed Aug  6 01:54:14 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 6 Aug 2025 01:54:14 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
Message-ID: <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com>

On Tue, 5 Aug 2025 08:31:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.
>
> test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 140:
> 
>> 138:      * Finds an {@linkplain CoderResult#isUnmappable() unmappable} non-Latin-1 {@code char[]} for the given encoder.
>> 139:      */
>> 140:     private static char[] findUnmappableNonLatin1(CharsetEncoder encoder) {
> 
> I'd appreciate it if you can double-check this method.

I would assume your "double char" actually means the "surrogate pair"?

I believe for the first pass of scanning you might want to skip the 'surrogate",  as a single dangling surrogate char should trigger a "malformed" error, instead of 'unmappable", if the charset is implemented to handle supplementary character. 

        for (char c = 0xFF; c < 0xFFFF; c++) {
            if (Character.isSurrogate(c))
                continue;
            if (!encoder.canEncode(c))
                return new char[]{c};
        }

And for the second pass for the 'surrogates", I think we can just pick any non-bmp panel, which should always be translated into a surrogate pair and check if the charset can map/encode it, if not, it's our candidate.

        for (int i = 0x10000; i < 0x1FFFF; i++) {
            char[] cc = Character.toChars(i);
            if (!encoder.canEncode(new String(cc)))
              return cc;
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2255682596

From sherman at openjdk.org  Wed Aug  6 02:20:03 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 6 Aug 2025 02:20:03 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
Message-ID: <xcPMFVVW7tezdLCj0s5yacP0ciiY0DQN1pXIklzxlEE=.7cd8ec56-459a-48df-abe4-fa8eef5db32f@github.com>

On Tue, 5 Aug 2025 08:20:55 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.
>
> test/jdk/sun/nio/cs/TestEncoderReplaceUTF16.java line 146:
> 
>> 144:             System.err.println("Character set is known to be absent of unmappable non-Latin-1 characters!");
>> 145:             return null;
>> 146:         }
> 
> Without this fast-path, this test take several minutes to complete due to `findUnmappableNonLatin1()` taking ~20 seconds for each character set absent of unmappable Latin-1 characters.

we definitely want to exclude 'some' charsets here. yes, all unicode variants probably should be excluded, as they are expected to have a 'mapping' for every unicode character. Additionally, many charsets have an "internal status", meaning they might shift in and shift out its status based on input. See https://www.rfc-editor.org/rfc/rfc1468.html for an example. The encoder might/should add the shift-in/out escape sequence characters on top of the 'replacement', if the replacement character's target sub-charset does not match the 'existing' sub-charset. i would assume this is really out of the scope of this pr though :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2255705386

From swen at openjdk.org  Wed Aug  6 05:52:09 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Aug 2025 05:52:09 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v8]
In-Reply-To: <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
Message-ID: <-YJY-8webwGnyO0DUcRgJADfTRN2CSBvtsN611zLr6k=.be5c885a-e164-401b-a126-53813f94ba23@github.com>

On Tue, 5 Aug 2025 22:35:58 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   Refining docs

make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java line 860:

> 858:             if (currentContainer instanceof KeyContainer kc &&
> 859:                 kc.getKey().equals("number") &&
> 860:                 attributes.getValue("sample").equals("-")) {

Suggestion:

            if (currentContainer instanceof KeyContainer kc
                && kc.getKey().equals("number")
                && attributes.getValue("sample").equals("-")) {

Similar to lines 813 to 817 above, the `&&` operator is placed in front to make the style consistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255928504

From vyazici at openjdk.org  Wed Aug  6 10:01:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 6 Aug 2025 10:01:13 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <xcPMFVVW7tezdLCj0s5yacP0ciiY0DQN1pXIklzxlEE=.7cd8ec56-459a-48df-abe4-fa8eef5db32f@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
 <xcPMFVVW7tezdLCj0s5yacP0ciiY0DQN1pXIklzxlEE=.7cd8ec56-459a-48df-abe4-fa8eef5db32f@github.com>
Message-ID: <lEztBFi4-979aioVan5X8qMUKVRpiJ7X7kDxvX_fT48=.5881ffa1-e854-42c8-87fc-5ed19545c95c@github.com>

On Wed, 6 Aug 2025 02:17:15 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> if the replacement character's target sub-charset does not match the 'existing' sub-charset

In such a `replacement`, does `CharsetEncoder::isLegalReplacement` still return `true`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2256646879

From vyazici at openjdk.org  Wed Aug  6 10:55:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 6 Aug 2025 10:55:02 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
 <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com>
Message-ID: <EBb28f86kPcpaMc17wyDeAfZGhz3_fDstCOzzCxTJMM=.afe3b7b9-ac19-4129-9efa-447242c4601c@github.com>

On Wed, 6 Aug 2025 01:51:54 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> for (char c = 0xFF; c < 0xFFFF; c++)

Doesn't this exclude `0xFFFF`, which is a valid (single-`char`, non-surrogate) BMP character?

> ... we can just pick any non-bmp panel ...
> ```
> for (int i = 0x10000; i < 0x1FFFF; i++) { ...
> ```

Doesn't the non-BMP range rather end with 0x10FFFF?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2256774007

From sherman at openjdk.org  Wed Aug  6 18:04:28 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 6 Aug 2025 18:04:28 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <EBb28f86kPcpaMc17wyDeAfZGhz3_fDstCOzzCxTJMM=.afe3b7b9-ac19-4129-9efa-447242c4601c@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
 <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com>
 <EBb28f86kPcpaMc17wyDeAfZGhz3_fDstCOzzCxTJMM=.afe3b7b9-ac19-4129-9efa-447242c4601c@github.com>
Message-ID: <D9HoeP0o5EjXgECjET3pSUta2Ka-E2KsqB8dqY0zzwo=.ac522f4b-f4c9-4e4a-a75f-dc5b9b2db064@github.com>

On Wed, 6 Aug 2025 10:52:00 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> I would assume your "double char" actually means the "surrogate pair"?
>> 
>> I believe for the first pass of scanning you might want to skip the 'surrogate",  as a single dangling surrogate char should trigger a "malformed" error, instead of 'unmappable", if the charset is implemented to handle supplementary character. 
>> 
>>         for (char c = 0xFF; c < 0xFFFF; c++) {
>>             if (Character.isSurrogate(c))
>>                 continue;
>>             if (!encoder.canEncode(c))
>>                 return new char[]{c};
>>         }
>> 
>> And for the second pass for the 'surrogates", I think we can just pick any non-bmp panel, which should always be translated into a surrogate pair and check if the charset can map/encode it, if not, it's our candidate.
>> 
>>         for (int i = 0x10000; i < 0x1FFFF; i++) {
>>             char[] cc = Character.toChars(i);
>>             if (!encoder.canEncode(new String(cc)))
>>               return cc;
>>         }
>
>> for (char c = 0xFF; c < 0xFFFF; c++)
> 
> Doesn't this exclude `0xFFFF`, which is a valid (single-`char`, non-surrogate) BMP character?
> 
>> ... we can just pick any non-bmp panel ...
>> ```
>> for (int i = 0x10000; i < 0x1FFFF; i++) { ...
>> ```
> 
> Doesn't the non-BMP range rather end with 0x10FFFF?

(1) we might want to include 0xffff in first pass
(2) we just need to pick any unmappable non-bmp character, i would assume that it should be pretty safe we will find one in the first non-bmp panel that is not encoded by a specific charset.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2257902674

From sherman at openjdk.org  Wed Aug  6 18:35:16 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 6 Aug 2025 18:35:16 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <lEztBFi4-979aioVan5X8qMUKVRpiJ7X7kDxvX_fT48=.5881ffa1-e854-42c8-87fc-5ed19545c95c@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
 <xcPMFVVW7tezdLCj0s5yacP0ciiY0DQN1pXIklzxlEE=.7cd8ec56-459a-48df-abe4-fa8eef5db32f@github.com>
 <lEztBFi4-979aioVan5X8qMUKVRpiJ7X7kDxvX_fT48=.5881ffa1-e854-42c8-87fc-5ed19545c95c@github.com>
Message-ID: <TnIH2Ne8CPssBO4WN4ysuOY_UF9_dJuZrug-AiQKhMc=.8e797d91-3876-43ca-9d12-88eb82fa3b56@github.com>

On Wed, 6 Aug 2025 09:58:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> we definitely want to exclude 'some' charsets here. yes, all unicode variants probably should be excluded, as they are expected to have a 'mapping' for every unicode character. Additionally, many charsets have an "internal status", meaning they might shift in and shift out its status based on input. See https://www.rfc-editor.org/rfc/rfc1468.html for an example. The encoder might/should add the shift-in/out escape sequence characters on top of the 'replacement', if the replacement character's target sub-charset does not match the 'existing' sub-charset. i would assume this is really out of the scope of this pr though :-)
>
>> if the replacement character's target sub-charset does not match the 'existing' sub-charset
> 
> In such a `replacement`, does `CharsetEncoder::isLegalReplacement` still return `true`?

it's 'tricky' :-)  some charsets have a default initial status, ascii-charset for example, this might trigger false return if the replacement is set without the appropriate shift-in/out esc-seq when target-sub-charset and existing charset are not matched.  I'm not confident that all our implementations really handle it correctly :-)  it might be interested (not really :-) given these charsets might not be that important these days and it's rare people try to change the default replacement bytes) to do full-scan-check, but again probably is not in-scope of this change.  

iso2022-jp is one such charset. we attempt to shift-in to the correct sub-charset by keeping the requested mode in **_implReplaceWith_**

        protected void implReplaceWith(byte[] newReplacement) {
            /* It's almost impossible to decide which charset they belong
               to. The best thing we can do here is to "guess" based on
               the length of newReplacement.
             */
            if (newReplacement.length == 1) {
                replaceMode = ASCII;
            } else if (newReplacement.length == 2) {
                replaceMode = JISX0208_1983;
            }
        } 

then during encoding

                            if (unmappableCharacterAction()
                                == CodingErrorAction.REPLACE
                                && currentMode != replaceMode) {
                                if (dl - dp < 3)
                                    return CoderResult.OVERFLOW;
                                if (replaceMode == ASCII) {
                                    da[dp++] = (byte)0x1b;
                                    da[dp++] = (byte)0x28;
                                    da[dp++] = (byte)0x42;
                                } else {
                                    da[dp++] = (byte)0x1b;
                                    da[dp++] = (byte)0x24;
                                    da[dp++] = (byte)0x42;
                                }
                                currentMode = replaceMode;
                            }

i believe this might not be really bulletproved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2257966394

From naoto at openjdk.org  Wed Aug  6 19:02:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Aug 2025 19:02:52 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v9]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <VrFo_KT8vWATMfgnDkT3MU3BGPyBW1oCHbBoTRSVRI4=.2d313175-1e85-48b4-84ae-37a605db0643@github.com>

> 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 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 request incrementally with one additional commit since the last revision:

  Update make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java
  
  Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/b9b0820f..e0fb990a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From jlu at openjdk.org  Wed Aug  6 19:02:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 6 Aug 2025 19:02:52 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v8]
In-Reply-To: <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
Message-ID: <XAq82lnY12Fn2AANZ-PCYQ_c-omZCJAunJOlWlYmINw=.4fcbd21e-5965-4b1c-9870-ea76944b3921@github.com>

On Tue, 5 Aug 2025 22:35:58 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   Refining docs

src/java.base/share/classes/java/text/DecimalFormat.java line 310:

> 308:  * minimal digits, and other characteristics are all the same as the positive
> 309:  * pattern. That means that {@code "#,##0.0#;(#)"} produces precisely
> 310:  * the same behavior as {@code "#,##0.0#;(#,##0.0#)"}. In

I think it is appropriate to have this here since it regards the negative sub pattern. However, we should either  link to this info or add additional info in the parse method. (Since the `parse` method covers behavior when strict/lenient.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2258014200

From jlu at openjdk.org  Wed Aug  6 19:02:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 6 Aug 2025 19:02:53 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v7]
In-Reply-To: <akqzBE4RPlOWiNXxFB1uksD4hPhVS5yxZUJMsgGYnzs=.c7d67a06-0d44-4a27-ac7e-fcd073247e37@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <rUOSugSIN-tck_2gAHq5B0UdjUITjGWD1vH9S3hv_3I=.88de08d8-5cbf-479c-8891-2143d39bee8f@github.com>
 <UsH08IcWc_rntd2IOWALXDOsQypFl_lq0N7ry9ecGdI=.661a98cb-00b1-41d9-ab50-c28622f09ebc@github.com>
 <akqzBE4RPlOWiNXxFB1uksD4hPhVS5yxZUJMsgGYnzs=.c7d67a06-0d44-4a27-ac7e-fcd073247e37@github.com>
Message-ID: <8FTrupvQ067NOi7acXu_eYHTdGc930zdDzjJWnxtZiQ=.d93cfca8-ba0e-41ac-8385-f57d58c8bcbb@github.com>

On Tue, 5 Aug 2025 22:51:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 852:
>> 
>>> 850: 
>>> 851:         // Lenient minus signs
>>> 852:         lenientMinusSigns = numberElements.length < 14 ? minusSignText : numberElements[13];
>> 
>> BTW, if I remove this check and always assign to `numberElements[13]`, I do not observe any failures in the java_text/Format suite. It would be nice to have an idea of why this check is needed. (I understand it is following the same length checks of monetarySeparator and monetaryGroupingSeparator.)
>
> The FALLBACK locale provider does not provide those elements, so the check is needed. Some tests in java/sun.util tests that specify HOST provider would fail without it.

I did not check that test suite, thanks that's good to know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2258008674

From eirbjo at openjdk.org  Wed Aug  6 19:52:15 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 6 Aug 2025 19:52:15 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v9]
In-Reply-To: <VrFo_KT8vWATMfgnDkT3MU3BGPyBW1oCHbBoTRSVRI4=.2d313175-1e85-48b4-84ae-37a605db0643@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <VrFo_KT8vWATMfgnDkT3MU3BGPyBW1oCHbBoTRSVRI4=.2d313175-1e85-48b4-84ae-37a605db0643@github.com>
Message-ID: <0PRHJpzfsYxyE4aCPtGe36MbjfSc0R8OgibILfaawJ4=.331c60ef-1a9a-460f-a5b8-c5ca700de7cb@github.com>

On Wed, 6 Aug 2025 19:02:52 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   Update make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java
>   
>   Co-authored-by: Shaojin Wen <shaojin.wensj at alibaba-inc.com>

Nit: Maybe using ?lenient? instead of ?loose? in the JBS/PR title would provide a more precise, correct and searchable description of the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26580#issuecomment-3161391423

From naoto at openjdk.org  Wed Aug  6 20:24:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Aug 2025 20:24:32 GMT
Subject: <i18n dev> RFR: 8363972: Loose matching of dash/minusSign in
 number parsing [v10]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>

> 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 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 request incrementally with one additional commit since the last revision:

  Added description in `parse()`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/e0fb990a..a0c4b9cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=08-09

  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From naoto at openjdk.org  Wed Aug  6 20:28:21 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Aug 2025 20:28:21 GMT
Subject: <i18n dev> RFR: 8363972: Lenient parsing of minus sign pattern
 in DecimalFormat/CompactNumberFormat [v8]
In-Reply-To: <XAq82lnY12Fn2AANZ-PCYQ_c-omZCJAunJOlWlYmINw=.4fcbd21e-5965-4b1c-9870-ea76944b3921@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <UmmAh4KhxwSZB34-IRtEu917Kwgt9bimnBV-BLQkJ_I=.d659b0f3-7e7d-4a08-91f5-b089450adfb2@github.com>
 <XAq82lnY12Fn2AANZ-PCYQ_c-omZCJAunJOlWlYmINw=.4fcbd21e-5965-4b1c-9870-ea76944b3921@github.com>
Message-ID: <xXwKPIJYe-BK7cir9kEnQW2mCccW8kTcUHz61Gk1FXs=.65c329f1-8203-4061-a2f7-83d4c8817d58@github.com>

On Wed, 6 Aug 2025 18:56:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refining docs
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 310:
> 
>> 308:  * minimal digits, and other characteristics are all the same as the positive
>> 309:  * pattern. That means that {@code "#,##0.0#;(#)"} produces precisely
>> 310:  * the same behavior as {@code "#,##0.0#;(#,##0.0#)"}. In
> 
> I think it is appropriate to have this here since it regards the negative sub pattern. However, we should either  link to this info or add additional info in the parse method. (Since the `parse` method covers behavior when strict/lenient.)

Since the leniency relates to not only `parse()` but also `is/setStrict()` methods, I wanted to consolidate the minus sign leniency in the class descrption. But yes describing it additionally in `parse()` would not hurt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2258215992

From vyazici at openjdk.org  Thu Aug  7 15:07:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 7 Aug 2025 15:07:08 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v2]
In-Reply-To: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
Message-ID: <jpvJx4Wa6X02NF7ovbjL3n3iq_lOLp6771bg-yM85m0=.1ca3b0bf-da96-415c-b62b-0f61d24044b2@github.com>

> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Improve double-`char` unmappable search
 - Improve single-`char` unmappable search

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26635/files
  - new: https://git.openjdk.org/jdk/pull/26635/files/4956a5b1..f567f2c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26635&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26635&range=00-01

  Stats: 55 lines in 2 files changed: 3 ins; 37 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26635/head:pull/26635

PR: https://git.openjdk.org/jdk/pull/26635

From vyazici at openjdk.org  Thu Aug  7 15:07:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 7 Aug 2025 15:07:10 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v2]
In-Reply-To: <V-7Iy_-V_6dMGXFsLNxNuTKtxtpfGrteQTSL33NH6d4=.d333533a-2b5c-4ab7-9afd-da51c5b37c53@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
 <V-7Iy_-V_6dMGXFsLNxNuTKtxtpfGrteQTSL33NH6d4=.d333533a-2b5c-4ab7-9afd-da51c5b37c53@github.com>
Message-ID: <9pnkM5rC_Exr8vfI4RKcvA_0YFj84V9qMPnQLD45qq4=.3899a66f-0418-4117-afae-9fd7fc12f1b8@github.com>

On Wed, 6 Aug 2025 00:25:58 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 139:
>> 
>>> 137:             return coderResult.isUnmappable();
>>> 138:         };
>>> 139:     }
>> 
>> I'd appreciate it if you can double-check these _"Is the given `char[]` unmappable for a particular encoder?"_ test generators.
>
> I might be missing something you're trying to do here,  but any reason why we can't just do
> 
>   return c -> !encoder.canEncode(c[0]);
> 
> as the predicate? I think we are doing 'single char', no surrogates,  here, right?
> 
> or simply go with
> 
>     private static char[] findUnmappable(CharsetEncoder encoder) {
>         for (char c = 0; c <= 0xff; c++) {
>             if (!encoder.canEncode(c))
>                 return new char[]{c};
>         }
>         System.err.println("Could not find an unmappable character!");
>         return null;
>     }

You're right. Simplified as suggested in ba1e5ff4de6.

I wanted to use `{Single,Double}Byte.Encoder` methods deliberately, since those were the ones triggering the failure. Though `CharsetEncoder#canEncode(char)` should do the trick, plus, it is public.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2260610086

From vyazici at openjdk.org  Thu Aug  7 15:07:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 7 Aug 2025 15:07:11 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v2]
In-Reply-To: <D9HoeP0o5EjXgECjET3pSUta2Ka-E2KsqB8dqY0zzwo=.ac522f4b-f4c9-4e4a-a75f-dc5b9b2db064@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <Br_anEb2OU47QiPqwZpz59rwsGP3zJp029qMhMqkkaY=.2408f4f0-add7-411e-a8fa-d98e6a6974e3@github.com>
 <7s4yftGeq4vQ9KGg-Ir2kYeGB14AM5NO2-7cFrMyweA=.985d6857-b33d-4c4a-a901-a0c42f06849d@github.com>
 <EBb28f86kPcpaMc17wyDeAfZGhz3_fDstCOzzCxTJMM=.afe3b7b9-ac19-4129-9efa-447242c4601c@github.com>
 <D9HoeP0o5EjXgECjET3pSUta2Ka-E2KsqB8dqY0zzwo=.ac522f4b-f4c9-4e4a-a75f-dc5b9b2db064@github.com>
Message-ID: <LHjWtOq51tZA7pHqUvBk61upy1upej_ap1QHy4Y_yxk=.e6f2c2c2-5f40-4d92-9977-42319c2e0bf7@github.com>

On Wed, 6 Aug 2025 18:00:00 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>>> for (char c = 0xFF; c < 0xFFFF; c++)
>> 
>> Doesn't this exclude `0xFFFF`, which is a valid (single-`char`, non-surrogate) BMP character?
>> 
>>> ... we can just pick any non-bmp panel ...
>>> ```
>>> for (int i = 0x10000; i < 0x1FFFF; i++) { ...
>>> ```
>> 
>> Doesn't the non-BMP range rather end with 0x10FFFF?
>
> (1) we might want to include 0xffff in first pass
> (2) we just need to pick any unmappable non-bmp character, i would assume that it should be pretty safe we will find one in the first non-bmp panel that is not encoded by a specific charset.

In f567f2c81a3, improved `findUnmappableNonLatin1()` as suggested:

Single-`char`:

    for (int i = 0xFF; i <= 0xFFFF; i++) {
        char c = (char) i;

Double-`char` (i.e., surrogate pair):

    int[] nonBmpRange = {0x10000, 0x10FFFF};
    for (int i = nonBmpRange[0]; i < nonBmpRange[1]; i++) {

Note that I took the incentive to use 0x10FFFF as the non-BMP range end ? easier to understand the exhaustive search.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2260609569

From jlu at openjdk.org  Thu Aug  7 18:10:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 18:10:16 GMT
Subject: <i18n dev> RFR: 8363972: Lenient parsing of minus sign pattern
 in DecimalFormat/CompactNumberFormat [v10]
In-Reply-To: <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <fL10ZLA1KeHGufyjiTHLLC9HBCNzWEGFeXbv0klsLW8=.d9136fb0-a20e-41f3-a985-56aea04d19cc@github.com>
Message-ID: <laSObByiKBK-Yt3AeQR__Ef9GWJ2NyPqe-q0NwA6FLM=.c56af02e-cc09-4281-8727-4af9e48928e8@github.com>

On Wed, 6 Aug 2025 20:24:32 GMT, Naoto Sato <naoto at openjdk.org> 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 the parsing of user input 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 request incrementally with one additional commit since the last revision:
> 
>   Added description in `parse()`

The current form looks good to me, thanks for all the changes. Approved CSR as well.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26580#pullrequestreview-3098263842

From sherman at openjdk.org  Thu Aug  7 19:19:16 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Thu, 7 Aug 2025 19:19:16 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v2]
In-Reply-To: <jpvJx4Wa6X02NF7ovbjL3n3iq_lOLp6771bg-yM85m0=.1ca3b0bf-da96-415c-b62b-0f61d24044b2@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <jpvJx4Wa6X02NF7ovbjL3n3iq_lOLp6771bg-yM85m0=.1ca3b0bf-da96-415c-b62b-0f61d24044b2@github.com>
Message-ID: <ut6G6Bz5jMUa9A0SKH1CmpFI8fkCi0QEZsewJoDKaRk=.050e7bac-f9b3-4e7d-b1a1-3fecabb3db7c@github.com>

On Thu, 7 Aug 2025 15:07:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve double-`char` unmappable search
>  - Improve single-`char` unmappable search

test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 251:

> 249:             sb.append("%sU+%04X".formatted(i > 0 ? ", " : "", (int) c));
> 250:         }
> 251:         return sb.append(']').toString();

just for fun :-)

return IntStream.range(0, cs.length)
                            .mapToObj(i -> String.format("U+%04X", (int) cs[i]))
                            .collect(Collectors.joining(", ", "[", "]"));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2261207568

From jlu at openjdk.org  Thu Aug  7 21:53:23 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 21:53:23 GMT
Subject: <i18n dev> RFR: 8364780: Ambiguity in DecimalFormatSymbols Unicode
 extension priority
Message-ID: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>

This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.

Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

-------------

Commit messages:
 - copyright year
 - drive-by style changes
 - init

Changes: https://git.openjdk.org/jdk/pull/26683/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364780
  Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26683/head:pull/26683

PR: https://git.openjdk.org/jdk/pull/26683

From naoto at openjdk.org  Thu Aug  7 22:33:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Aug 2025 22:33:11 GMT
Subject: <i18n dev> RFR: 8364780: Ambiguity in DecimalFormatSymbols
 Unicode extension priority
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>

On Thu, 7 Aug 2025 21:47:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
> 
> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

Thanks for cleaning this. This is definitely a leftover from [JDK-8186697](https://bugs.openjdk.org/browse/JDK-8186697). I think "cu" needs to have the same wording?

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 62:

> 60:  * your {@code DecimalFormat} and modify it.
> 61:  *
> 62:  * <p> The "rg" (region override) and "nu" (numbering system) {@code Locale}

Nit: extra space before "The"

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 93:

> 91:      */
> 92:     public DecimalFormatSymbols() {
> 93:         initialize(Locale.getDefault(Locale.Category.FORMAT));

Taking this opportunity, remove the surrounding spaces in the method itself: (L:817)

-------------

PR Review: https://git.openjdk.org/jdk/pull/26683#pullrequestreview-3098950525
PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2261559787
PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2261577832

From jlu at openjdk.org  Thu Aug  7 23:12:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 23:12:52 GMT
Subject: <i18n dev> RFR: 8364780: Ambiguity in DecimalFormatSymbols
 Unicode extension priority [v2]
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <ImEKgNnTaT7q4fFbDnfjcLBpnSr0laakJ1olywKN_fM=.669c94cf-7aac-4541-833a-c9a9abf6ffed@github.com>

> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
> 
> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26683/files
  - new: https://git.openjdk.org/jdk/pull/26683/files/cc8766c2..78b223a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26683&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26683&range=00-01

  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26683/head:pull/26683

PR: https://git.openjdk.org/jdk/pull/26683

From jlu at openjdk.org  Thu Aug  7 23:13:03 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 23:13:03 GMT
Subject: <i18n dev> RFR: 8364780: Ambiguity in DecimalFormatSymbols
 Unicode extension priority [v2]
In-Reply-To: <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
Message-ID: <1VnbrlavShyntUVeidofp3HvKiGbYRD3lR5zfY_5wcs=.92322406-1422-4f10-acd1-0b08c8a6a254@github.com>

On Thu, 7 Aug 2025 22:30:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect comments
>
> Thanks for cleaning this. This is definitely a leftover from [JDK-8186697](https://bugs.openjdk.org/browse/JDK-8186697). I think "cu" needs to have the same wording?

@naotoj You are right regarding "cu"; updated the PR as such. I am wondering if NumberFormat should also mention "cu" as well then under its own Unicode Extensions section, (which I can include in this change).

Let me know if the new wording changes make sense to you, or if you have a different way of implying that "nu" and "cu" both have priority over "rg" for their respective values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26683#issuecomment-3166098671

From naoto at openjdk.org  Thu Aug  7 23:21:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Aug 2025 23:21:10 GMT
Subject: <i18n dev> RFR: 8364780: Ambiguity in DecimalFormatSymbols
 Unicode extension priority [v2]
In-Reply-To: <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <WYzOuF0GTcUdyLf_QHqQFJDxh_DprGA4XdzKXqPquOE=.e9adc414-74a9-4476-b1e0-44dd5187381b@github.com>
Message-ID: <4HXOlgVnTz7CJwc0PX5FmxIbCLttl1Hs39biCakF7qc=.4cbc152c-aaa4-4a7e-af70-8dfa13faeffd@github.com>

On Thu, 7 Aug 2025 22:30:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect comments
>
> Thanks for cleaning this. This is definitely a leftover from [JDK-8186697](https://bugs.openjdk.org/browse/JDK-8186697). I think "cu" needs to have the same wording?

> @naotoj You are right regarding "cu"; updated the PR as such. I am wondering if NumberFormat should also mention "cu" as well then under its own Unicode Extensions section, (which I can include in this change).

I think so. NumberFormat can also be affected by "cu" extension.

> Let me know if the new wording changes make sense to you, or if you have a different way of implying that "nu" and "cu" both have priority over "rg" for their respective values.

The wording is fine to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26683#issuecomment-3166111072

From jlu at openjdk.org  Thu Aug  7 23:39:23 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Aug 2025 23:39:23 GMT
Subject: <i18n dev> RFR: 8364780: Ambiguity in DecimalFormatSymbols
 Unicode extension priority [v3]
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>

> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
> 
> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Updating NumberFormat with cu as well

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26683/files
  - new: https://git.openjdk.org/jdk/pull/26683/files/78b223a1..3a1e6ab2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26683&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26683&range=01-02

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26683/head:pull/26683

PR: https://git.openjdk.org/jdk/pull/26683

From vyazici at openjdk.org  Fri Aug  8 11:45:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 11:45:04 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v3]
In-Reply-To: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
Message-ID: <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>

> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve pretty-printers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26635/files
  - new: https://git.openjdk.org/jdk/pull/26635/files/f567f2c8..f056028a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26635&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26635&range=01-02

  Stats: 14 lines in 1 file changed: 2 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26635/head:pull/26635

PR: https://git.openjdk.org/jdk/pull/26635

From vyazici at openjdk.org  Fri Aug  8 11:45:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 11:45:05 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v3]
In-Reply-To: <ut6G6Bz5jMUa9A0SKH1CmpFI8fkCi0QEZsewJoDKaRk=.050e7bac-f9b3-4e7d-b1a1-3fecabb3db7c@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <jpvJx4Wa6X02NF7ovbjL3n3iq_lOLp6771bg-yM85m0=.1ca3b0bf-da96-415c-b62b-0f61d24044b2@github.com>
 <ut6G6Bz5jMUa9A0SKH1CmpFI8fkCi0QEZsewJoDKaRk=.050e7bac-f9b3-4e7d-b1a1-3fecabb3db7c@github.com>
Message-ID: <GwTOG-IdkL-KHuNnDljdrKjt8MMiiHfZ6LhUlAXn_o4=.9503bc8f-afdb-4157-ad74-c292e00f7dac@github.com>

On Thu, 7 Aug 2025 19:17:03 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve pretty-printers
>
> test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 251:
> 
>> 249:             sb.append("%sU+%04X".formatted(i > 0 ? ", " : "", (int) c));
>> 250:         }
>> 251:         return sb.append(']').toString();
> 
> just for fun :-)
> 
> return IntStream.range(0, cs.length)
>                             .mapToObj(i -> String.format("U+%04X", (int) cs[i]))
>                             .collect(Collectors.joining(", ", "[", "]"));

Applied suggestion to both `prettyPrint{Bytes,Chars}` in f056028a.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2262713842

From naoto at openjdk.org  Fri Aug  8 16:44:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Aug 2025 16:44:14 GMT
Subject: <i18n dev> RFR: 8364780: Unicode extension clarifications for
 NumberFormat/DecimalFormatSymbols [v3]
In-Reply-To: <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>
Message-ID: <sKgwE2gHLcqXRsvblteZmFO-TrI6dCvxv3HgnCEJ3YE=.0ec354fe-4a2a-46fe-87fb-0c8935d7082a@github.com>

On Thu, 7 Aug 2025 23:39:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR clarifies the Unicode extension wording in the DecimalFormatSymbols class description to make apparent that the "nu" extension is supported in addition to the "rg" extension. There already exists "nu" commentary in the specification of the  Locale accepting method APIs, the main purpose of this change is to clarify the behavior when both extensions are supplied.
>> 
>> Note that "may" wording is intentionally used, as symbols are only overridden if the JRE implementation provides support.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating NumberFormat with cu as well

LGTM. Reviewed the CSR too.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 64:

> 62:  * <p>The "rg" (region override), "nu" (numbering system), and "cu" (currency)
> 63:  * {@code Locale} <a href="../util/Locale.html#def_locale_extension">Unicode
> 64:  * extensions</a> are supported which may override values within the symbols.

This can be replaced with `{@link Locale##def_locale_extension Unicode extensions}`. There are multiple locations for this, and it is obviously out of this PR's scope, it can be cleaned up with a separate issue.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26683#pullrequestreview-3101534352
PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2263516692

From jlu at openjdk.org  Fri Aug  8 16:53:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Aug 2025 16:53:11 GMT
Subject: <i18n dev> RFR: 8364780: Unicode extension clarifications for
 NumberFormat/DecimalFormatSymbols [v3]
In-Reply-To: <sKgwE2gHLcqXRsvblteZmFO-TrI6dCvxv3HgnCEJ3YE=.0ec354fe-4a2a-46fe-87fb-0c8935d7082a@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
 <6LGXcj0ZtmN5ptgfuAtg9uznc9gdAz6K78xzYrQjEOg=.93b9b720-d32b-48c2-a442-0b5134c24d53@github.com>
 <sKgwE2gHLcqXRsvblteZmFO-TrI6dCvxv3HgnCEJ3YE=.0ec354fe-4a2a-46fe-87fb-0c8935d7082a@github.com>
Message-ID: <ZA7pmYCNH4pkgVpQNQbil821_dNAB7kl1zLniKFINkg=.3a142211-e818-4360-92c0-71315142cee1@github.com>

On Fri, 8 Aug 2025 16:38:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating NumberFormat with cu as well
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 64:
> 
>> 62:  * <p>The "rg" (region override), "nu" (numbering system), and "cu" (currency)
>> 63:  * {@code Locale} <a href="../util/Locale.html#def_locale_extension">Unicode
>> 64:  * extensions</a> are supported which may override values within the symbols.
> 
> This can be replaced with `{@link Locale##def_locale_extension Unicode extensions}`. There are multiple locations for this, and it is obviously out of this PR's scope, it can be cleaned up with a separate issue.

Filed https://bugs.openjdk.org/browse/JDK-8365175 for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26683#discussion_r2263547997

From sherman at openjdk.org  Fri Aug  8 18:59:12 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 8 Aug 2025 18:59:12 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v3]
In-Reply-To: <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>
Message-ID: <5G5uoIjwsDxy9oxYpH66W53yh2TFmJDYyqSR57ugD78=.cac5b223-f07e-4c73-afc5-7277ee6a6810@github.com>

On Fri, 8 Aug 2025 11:45:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve pretty-printers

LGTM

test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 132:

> 130:             replacement1[0] = (byte) i;
> 131:             // Skip the default value, since we're verifying if a custom one works
> 132:             if (replacement1[0] == replacementD[0]) {

nit-pick?
if (replacementD.length == 1 && replacement1[0] == replacementD[0]) { ...}

-------------

PR Review: https://git.openjdk.org/jdk/pull/26635#pullrequestreview-3101869911
PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2263778167

From prr at openjdk.org  Fri Aug  8 21:48:33 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Aug 2025 21:48:33 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize()
Message-ID: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>

Remove finalize() from WInputMethod.java - it is used to free a native id.
Also the reason dispose() didn't free it seems no longer relevant.
Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.

-------------

Commit messages:
 - 8365180

Changes: https://git.openjdk.org/jdk/pull/26706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365180
  Stats: 28 lines in 2 files changed: 12 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/26706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26706/head:pull/26706

PR: https://git.openjdk.org/jdk/pull/26706

From sherman at openjdk.org  Fri Aug  8 22:15:13 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 8 Aug 2025 22:15:13 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v3]
In-Reply-To: <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>
Message-ID: <dqcGJ4Y9CUGHvEdP3Ltm7CyNDjM7X8grU22CYJfB0jA=.728c9850-6a90-4094-bb4a-82b417ec156c@github.com>

On Fri, 8 Aug 2025 11:45:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve pretty-printers

lgtm

-------------

Marked as reviewed by sherman (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26635#pullrequestreview-3102242861

From naoto at openjdk.org  Fri Aug  8 22:47:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Aug 2025 22:47:47 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse all
 ISO 8601 date formats
Message-ID: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>

`Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/26708/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364752
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From swen at openjdk.org  Sat Aug  9 05:17:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:17:55 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust
Message-ID: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>

By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.


@ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big


By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

-------------

Commit messages:
 - from @jodastephen
 - from @jodastephen
 - Separate exception handling into two separate methods to make codeSize < 325

Changes: https://git.openjdk.org/jdk/pull/26633/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365186
  Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26633/head:pull/26633

PR: https://git.openjdk.org/jdk/pull/26633

From vyazici at openjdk.org  Sat Aug  9 05:17:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Sat, 9 Aug 2025 05:17:55 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <m9Iko23FLJq2bePRvN7yKMILTNUOgrgXS6be0lpTLFM=.296782c3-8c78-4bfc-83f2-f40a9447a8af@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

Would you mind sharing the details about the performance improvement you observed, please? On which platforms? Using which benchmarks? (Any in `test/micro/org/openjdk/bench/java/time/format`?)

Using 99425bc, I can observe a noteworthy improvement on all tested platforms:

| Benchmark | Linux aarch64 | Linux x64 | MacOSX aarch64 | MacOSX x64 | Windows x64 |
| --------- |:-------------:|:---------:|:--------------:|:----------:|:-----------:|
| DateTimeFormatterBench.formatInstants-pattern:HH_mm_ss | 0.75% | 7.33% | 7.60% | 8.30% | 9.16% |
| DateTimeFormatterBench.formatInstants-pattern:HH_mm_ss_SSS | 1.13% | 0.74% | 10.24% | 4.03% | -2.67% |
| DateTimeFormatterBench.formatInstants-pattern:yyyy_MM_ddTHH_mm_ss | 0.17% | 14.31% | 9.00% | 13.69% | 18.66% |
| DateTimeFormatterBench.formatInstants-pattern:yyyy_MM_ddTHH_mm_ss_SSS | -0.66% | 3.26% | 5.98% | 2.91% | -1.12% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:HH_mm_ss | 5.17% | 6.54% | -1.61% | 1.55% | 7.25% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:HH_mm_ss_SSS | 3.99% | 1.45% | 4.14% | 1.79% | 1.36% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:yyyy_MM_ddTHH_mm_ss | 2.13% | 15.56% | -2.01% | 2.72% | 17.47% |
| DateTimeFormatterBench.formatZonedDateTime-pattern:yyyy_MM_ddTHH_mm_ss_SSS | 2.41% | 1.54% | 1.43% | 2.29% | 1.61% |
| DateTimeFormatterWithPaddingBench.formatWithPadding | 0.88% | 2.52% | 16.97% | 3.91% | 1.30% |
| DateTimeFormatterWithPaddingBench.formatWithPaddingLengthOne | -0.80% | 6.28% | 3.21% | 5.32% | 6.09% |
| DateTimeFormatterWithPaddingBench.formatWithPaddingLengthZero | 4.87% | 3.11% | 31.32% | 11.31% | 4.12% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3154162461
PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3167557811

From swen at openjdk.org  Sat Aug  9 05:17:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:17:55 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <Wdop9f_vC6k8leNgy18topOueJCbEWIJpzYoCMZ8aoI=.60a17ea5-ace0-4782-a1dd-e257e88e739c@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

By running DateTimeFormatterBench, we can see that the current proposal can improve performance by about 5% in multiple scenarios. The detailed data is as follows

# 1. Running performance test scripts

# before
git checkout 158e59ab9184127089f9693ce256001f64b5945c
make test TEST="micro:java.time.format.DateTimeFormatterBench"

# after
git checkout 0278bba135bed6e99a9e9f99cb656275c27f8465
make test TEST="micro:java.time.format.DateTimeFormatterBench"


# 2. Performance results in multiple architectures
## 2.1. MacBook M1 Pro (aarch64)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  15.053 ? 0.281  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  10.664 ? 0.119  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   8.994 ? 0.579  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.943 ? 0.370  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  22.938 ? 0.056  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  15.882 ? 0.144  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  13.302 ? 0.518  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  10.153 ? 0.075  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  16.083 ? 0.178  ops/ms +6.84%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  11.548 ? 0.171  ops/ms +8.28%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.835 ? 0.064  ops/ms +9.35%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.344 ? 0.308  ops/ms +5.77%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  22.500 ? 0.147  ops/ms -1.90%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  16.592 ? 0.086  ops/ms +4.47%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  13.182 ? 0.829  ops/ms -0.90%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  10.127 ? 0.140  ops/ms -0.25%


## 2.2. aliyun_c8y (aarch64 CPU Aliyun_Yitian 710)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15   9.916 ? 0.073  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   7.416 ? 0.013  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   6.248 ? 0.082  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   4.988 ? 0.042  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  13.653 ? 0.073  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15   9.435 ? 0.033  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   7.550 ? 0.145  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.096 ? 0.301  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  10.897 ? 0.047  ops/ms +9.89%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   7.449 ? 0.086  ops/ms +0.44%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   6.979 ? 0.025  ops/ms +11.69%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   4.950 ? 0.024  ops/ms -0.76%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  14.206 ? 0.206  ops/ms +4.05%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15   9.957 ? 0.182  ops/ms +5.53%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   7.705 ? 0.093  ops/ms +2.05%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.222 ? 0.235  ops/ms +2.06%


## 2.3. OrangePi 5 (aarch64 CPU RK3588)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt  Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  6.118 ? 0.417  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  4.312 ? 0.202  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  4.047 ? 0.107  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  2.773 ? 0.204  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  9.228 ? 0.232  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  5.640 ? 0.223  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  5.109 ? 0.076  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  3.407 ? 0.168  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt  Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  6.080 ? 0.451  ops/ms -0.62%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  4.341 ? 0.219  ops/ms +0.67%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  4.009 ? 0.207  ops/ms -0.93%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  2.928 ? 0.104  ops/ms +5.58%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  9.670 ? 0.139  ops/ms +4.78%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  5.835 ? 0.234  ops/ms +3.45%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  5.149 ? 0.153  ops/ms +0.78%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  3.553 ? 0.131  ops/ms +4.28%


## 2.4 aliyun_c9i (x64 CPU Intel Xeon Granite Rapids)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  15.718 ? 1.343  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  11.758 ? 0.638  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  10.529 ? 0.057  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.945 ? 0.304  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  20.441 ? 0.067  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  13.975 ? 0.062  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  11.721 ? 0.070  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   8.604 ? 0.073  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  16.745 ? 0.129  ops/ms +6.53%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  11.571 ? 1.085  ops/ms -1.52%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  10.591 ? 0.046  ops/ms +0.58%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.899 ? 0.323  ops/ms -0.57%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  20.993 ? 0.082  ops/ms +2.70%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  14.123 ? 0.094  ops/ms +1.05%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  11.781 ? 0.054  ops/ms +0.51%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   8.723 ? 0.055  ops/ms +1.38%



## 2.5 MacBook 2019 (x64 intel i9)

-# before
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  12.393 ? 0.985  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   9.658 ? 0.220  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   8.321 ? 0.098  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.575 ? 0.073  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  18.946 ? 0.387  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  12.156 ? 0.316  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.980 ? 0.115  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.729 ? 0.160  ops/ms

+# after
+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  13.942 ? 0.257  ops/ms +12.49%
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   9.882 ? 0.327  ops/ms +2.42%
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.234 ? 0.240  ops/ms +10.97%
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   6.594 ? 0.074  ops/ms +2.89%
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  19.482 ? 0.385  ops/ms +2.82%
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  12.917 ? 0.244  ops/ms +6.26%
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  10.196 ? 0.142  ops/ms +2.16%
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.793 ? 0.136  ops/ms +8.28%

* Run the test script

make test TEST="micro:java.time.format.DateTimeFormatterWithPaddingBench"


* Test results on aliyun_c9i (x64 CPU Intel Xeon Granite Rapids)


-# before
-Benchmark                                                       Mode  Cnt      Score     Error   Units
-DateTimeFormatterWithPaddingBench.formatWithPadding            thrpt   15  11823.795 ? 221.488  ops/ms
-DateTimeFormatterWithPaddingBench.formatWithPaddingLengthOne   thrpt   15  34634.499 ?  91.144  ops/ms
-DateTimeFormatterWithPaddingBench.formatWithPaddingLengthZero  thrpt   15  39070.959 ? 198.192  ops/ms

+# after
+Benchmark                                                       Mode  Cnt      Score     Error   Units
+DateTimeFormatterWithPaddingBench.formatWithPadding            thrpt   15  12257.729 ?  49.449  ops/ms +3.67%
+DateTimeFormatterWithPaddingBench.formatWithPaddingLengthOne   thrpt   15  37689.494 ? 117.526  ops/ms +8.82%
+DateTimeFormatterWithPaddingBench.formatWithPaddingLengthZero  thrpt   15  43628.181 ? 493.395  ops/ms +11.66%


In DateTimeFormatterWithPaddingBench, I found that this proposal improved performance even more.

This is because DateTimeFormatter is statically defined as final, and DateTimeFormatter::getChronology and DateTimeFormatter::getZone used in the adjust method are final fields. This eliminates dead code branches during inlining by the C2 optimizer.

* The following code is the formatter definition in DateTimeFormatterWithPaddingBench. The modifiers of the fields FORMATTER_WITH_PADDING/FORMATTER_WITH_PADDING_ZERO/FORMATTER_WITH_PADDING_ONE are static final.

public class DateTimeFormatterWithPaddingBench {

    private static final DateTimeFormatter FORMATTER_WITH_PADDING = new DateTimeFormatterBuilder()
            .appendLiteral("Date:")
            .padNext(20, ' ')
            .append(DateTimeFormatter.ISO_DATE)
            .toFormatter();

    private static final DateTimeFormatter FORMATTER_WITH_PADDING_ZERO = new DateTimeFormatterBuilder()
            .appendLiteral("Year:")
            .padNext(4)
            .appendValue(ChronoField.YEAR)
            .toFormatter();

    private static final DateTimeFormatter FORMATTER_WITH_PADDING_ONE = new DateTimeFormatterBuilder()
            .appendLiteral("Year:")
            .padNext(5)
            .appendValue(ChronoField.YEAR)
            .toFormatter();


* In the DateTimeFormatter related code, the modifiers of the chrono/zone fields are also final

final class DateTimeFormatter {
	private final Chronology chrono;
	private final ZoneId zone;

    public Chronology getChronology() {
        return chrono;
    }

    public ZoneId getZone() {
        return zone;
    }
}


* The following code in the DateTimePrintContext::adjust method uses chrono and zone. When adjust can be inlined, dead code branches can be eliminated to improve performance.


final class DateTimePrintContext {
    private static TemporalAccessor adjust(final TemporalAccessor temporal, DateTimeFormatter formatter) {
        Chronology overrideChrono = formatter.getChronology();
        ZoneId overrideZone = formatter.getZone();
        if (overrideChrono == null && overrideZone == null) {
            return temporal;
        }
        // ....
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3155866814
PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3158585653

From swen at openjdk.org  Sat Aug  9 05:17:56 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:17:56 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust
In-Reply-To: <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
Message-ID: <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>

On Wed, 6 Aug 2025 09:20:30 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
>> 
>> 
>> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
>> 
>> 
>> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.
>
> src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 152:
> 
>> 150:                 return chrono.zonedDateTime(Instant.from(temporal), overrideZone);
>> 151:             }
>> 152:         }
> 
> Have you tested the split at different locations? I would expect line 143 or line 130 to perform best. There may be a case for splitting multiple times. You will also need a comment to indicate why the method is split.

In theory, the smaller the method, the greater the opportunity for performance improvement, but in DateTimeFormatterWithPaddingBench and DateTimeFormatterBench, the improvement is the same.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2256949893

From scolebourne at openjdk.org  Sat Aug  9 05:17:56 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sat, 9 Aug 2025 05:17:56 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 152:

> 150:                 return chrono.zonedDateTime(Instant.from(temporal), overrideZone);
> 151:             }
> 152:         }

Have you tested the split at different locations? I would expect line 143 or line 130 to perform best. There may be a case for splitting multiple times. You will also need a comment to indicate why the method is split.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2256531178

From rriggs at openjdk.org  Sat Aug  9 05:17:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 9 Aug 2025 05:17:56 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <KglEougN2PRMrtlte1UnYv10ezjSvhe9AAuq7tzu-ow=.50d3bfcb-ed85-4216-b706-bb161e35ac71@github.com>

On Tue, 5 Aug 2025 01:23:17 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

Do you intend to move this PR from Draft to Open?

src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 164:

> 162:     }
> 163: 
> 164:     private static TemporalAccessor adjust(

Please fold the parameters into fewer (1) lines and briefly document the rationale for the internal method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26633#issuecomment-3168340810
PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2263021841

From swen at openjdk.org  Sat Aug  9 05:55:11 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 05:55:11 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust
In-Reply-To: <KglEougN2PRMrtlte1UnYv10ezjSvhe9AAuq7tzu-ow=.50d3bfcb-ed85-4216-b706-bb161e35ac71@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <KglEougN2PRMrtlte1UnYv10ezjSvhe9AAuq7tzu-ow=.50d3bfcb-ed85-4216-b706-bb161e35ac71@github.com>
Message-ID: <l_8A8PeHldebcTEOgrchJIez2NQwwAlmP3GgVe8nqYo=.da686020-eea6-4ce8-bdb2-8a4a20be345a@github.com>

On Fri, 8 Aug 2025 13:42:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
>> 
>> 
>> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
>> 
>> 
>> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.
>
> src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 164:
> 
>> 162:     }
>> 163: 
>> 164:     private static TemporalAccessor adjust(
> 
> Please fold the parameters into fewer (1) lines and briefly document the rationale for the internal method.

If the third adjust method parameter is placed on the same line, the line will have 195 characters (it is generally recommended to be less than 120).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2264536335

From vyazici at openjdk.org  Sat Aug  9 08:53:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Sat, 9 Aug 2025 08:53:20 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v3]
In-Reply-To: <5G5uoIjwsDxy9oxYpH66W53yh2TFmJDYyqSR57ugD78=.cac5b223-f07e-4c73-afc5-7277ee6a6810@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>
 <5G5uoIjwsDxy9oxYpH66W53yh2TFmJDYyqSR57ugD78=.cac5b223-f07e-4c73-afc5-7277ee6a6810@github.com>
Message-ID: <KpMJ9TexcXT7ukO0TEmUOWCdhz4oOOggjw2a79eCIX0=.235ecb8c-ecc5-4d10-9d7f-49be009430c9@github.com>

On Fri, 8 Aug 2025 18:48:43 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve pretty-printers
>
> test/jdk/sun/nio/cs/TestEncoderReplaceLatin1.java line 132:
> 
>> 130:             replacement1[0] = (byte) i;
>> 131:             // Skip the default value, since we're verifying if a custom one works
>> 132:             if (replacement1[0] == replacementD[0]) {
> 
> nit-pick?
> if (replacementD.length == 1 && replacement1[0] == replacementD[0]) { ...}

`replacementD` is obtained from `CharsetEncoder#replacement()` and its Javadoc states the following:

     * @return  This encoder's current replacement,
     *          which is never {@code null} and is never empty

I had decided to fail when spec. doesn't hold, instead of being lenient against its violation, in particular, since this is a test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26635#discussion_r2264610149

From swen at openjdk.org  Sat Aug  9 12:13:13 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 12:13:13 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust [v2]
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <tlIMAnT3TCZd7sApMtTt6gJJ_wvdA_z7rj3z0ds9J9w=.e7d61469-290e-4349-a6b7-6c4b3f377674@github.com>

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add java doc comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26633/files
  - new: https://git.openjdk.org/jdk/pull/26633/files/99425bcb..170cf788

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26633&range=00-01

  Stats: 70 lines in 1 file changed: 70 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26633/head:pull/26633

PR: https://git.openjdk.org/jdk/pull/26633

From duke at openjdk.org  Sat Aug  9 13:55:09 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 9 Aug 2025 13:55:09 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <55UQCywpNB4OPfqAgJhIcrJa9AIgxxQRe_gxZKWHj14=.9c7f3a6b-73d2-4b66-9054-a4dccc7c57ae@github.com>

On Fri, 8 Aug 2025 22:37:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

How?about using different patterns for?parsing and?printing instead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3170782773

From liach at openjdk.org  Sun Aug 10 02:34:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Aug 2025 02:34:12 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust [v2]
In-Reply-To: <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
 <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>
Message-ID: <PbnDP5Bvcje1gjtjpxjwsXUIC7rs4aZHl-SPFGAjMH4=.b9c036be-d2c6-4814-905d-ed2595c940b4@github.com>

On Wed, 6 Aug 2025 12:10:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimePrintContext.java line 152:
>> 
>>> 150:                 return chrono.zonedDateTime(Instant.from(temporal), overrideZone);
>>> 151:             }
>>> 152:         }
>> 
>> Have you tested the split at different locations? I would expect line 143 or line 130 to perform best. There may be a case for splitting multiple times. You will also need a comment to indicate why the method is split.
>
> In theory, the smaller the method, the greater the opportunity for performance improvement, but in DateTimeFormatterWithPaddingBench and DateTimeFormatterBench, the improvement is the same.

This depends on how often Formatters override chrono and zone, and how often these overrides are no-op so we can still fast return. if both shortcuts are significant, it may well be reasonable to set up a series of small shortcut methods and end with a "slow tail" (See the example of `ClassValue::get`, `getFromBackup`, and `getFromHashMap`).

Given that example, I recommend renaming the two new split `adjust` into `adjustWithOverride` and `adjustSlow` to distinguish from the actual `adjust` method.

In addition, I agree with @jodastephen that line 130 intuitively seems like the best place to break methods. Do you know if the "if have zone and instant" case is so frequent that it should be included in the 2nd method instead of the 3rd? The goal of inlining, as far as I know, is to include minimal hot code to be compiled, instead of tweaking the method size so it exactly falls into FreqInlineSize, so the less code to compile for C2 the better and faster it compiles.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2265087021

From swen at openjdk.org  Sun Aug 10 03:36:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 10 Aug 2025 03:36:06 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust [v3]
In-Reply-To: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
Message-ID: <y8vmYNc7ul7YQHkujvSffSg692k4JyJHzVXhfUnrOVg=.bbeb8e03-acd9-4126-b1b5-904c4525575f@github.com>

> By adding the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining` and analyzing the printed log information, and found that the code size of the j.t.f.DateTimePrintContext::adjust method is 382, which is greater than 325, causing inlining failure.
> 
> 
> @ 7   java.time.format.DateTimePrintContext::adjust (382 bytes)   failed to inline: hot method too big
> 
> 
> By splitting the code into `common/uncommon`, and moving the uncommon code into adjust0, the adjust method is kept small and can be inlined by the C2 optimizer.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26633/files
  - new: https://git.openjdk.org/jdk/pull/26633/files/170cf788..22ae4c83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26633&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26633&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26633/head:pull/26633

PR: https://git.openjdk.org/jdk/pull/26633

From swen at openjdk.org  Sun Aug 10 05:10:14 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 10 Aug 2025 05:10:14 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust [v3]
In-Reply-To: <PbnDP5Bvcje1gjtjpxjwsXUIC7rs4aZHl-SPFGAjMH4=.b9c036be-d2c6-4814-905d-ed2595c940b4@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <vpN3BgFjicMC_2ktmeV09CgG2ZtzOQujrg9xLWUDzlw=.794c1e7f-0848-47ac-8760-17ee89a0d66a@github.com>
 <un3Gj_C38VJpZWEoR2FzXs_YyJ5DJAO1ihghn3tSbAc=.659182be-6f21-422f-b150-175970f4b3a4@github.com>
 <PbnDP5Bvcje1gjtjpxjwsXUIC7rs4aZHl-SPFGAjMH4=.b9c036be-d2c6-4814-905d-ed2595c940b4@github.com>
Message-ID: <o9Kfa0-VjE_In8KhVsXDyMWVdGhwxIvz2dj_uxBlmeE=.acecab70-0f34-46f5-9dc5-13ae34dd7849@github.com>

On Sun, 10 Aug 2025 02:31:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In theory, the smaller the method, the greater the opportunity for performance improvement, but in DateTimeFormatterWithPaddingBench and DateTimeFormatterBench, the improvement is the same.
>
> This depends on how often Formatters override chrono and zone, and how often these overrides are no-op so we can still fast return. if both shortcuts are significant, it may well be reasonable to set up a series of small shortcut methods and end with a "slow tail" (See the example of `ClassValue::get`, `getFromBackup`, and `getFromHashMap`).
> 
> Given that example, I recommend renaming the two new split `adjust` into `adjustWithOverride` and `adjustSlow` to distinguish from the actual `adjust` method.
> 
> In addition, I agree with @jodastephen that line 130 intuitively seems like the best place to break methods. Do you know if the "if have zone and instant" case is so frequent that it should be included in the 2nd method instead of the 3rd? The goal of inlining, as far as I know, is to include minimal hot code to be compiled, instead of tweaking the method size so it exactly falls into FreqInlineSize, so the less code to compile for C2 the better and faster it compiles.

The `adjust` method has a code size of 27, covering the most common scenarios and capable of handling C1.

The `adjustWithOverride` method has a code size of 123, which can also be handled by C2 and covers the use of formatters with zones in the DateTimeFormatterBench.

This split ensures a balanced approach to startup performance and optimizations for the most common scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2265116221

From vyazici at openjdk.org  Mon Aug 11 07:13:21 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 07:13:21 GMT
Subject: <i18n dev> RFR: 8364365: HKSCS encoder does not properly set
 the replacement character [v3]
In-Reply-To: <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
 <vz1Ro8KmgVxq8qJMcdWB6KePblFdrcPrOuUOi-E0VaE=.26b5e40a-5ca0-4ad1-9768-973767cf2327@github.com>
Message-ID: <qErTL8IU5QCRj8Hbh6uk740FoYsh5nvumshnJ_H_uAc=.afa58f1d-7d49-4dcd-a8d9-211b4b1bebb0@github.com>

On Fri, 8 Aug 2025 11:45:04 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve pretty-printers

Internally verified `tier1,2,3` runs successfully complete.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26635#issuecomment-3173510451

From vyazici at openjdk.org  Mon Aug 11 07:13:22 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 07:13:22 GMT
Subject: <i18n dev> Integrated: 8364365: HKSCS encoder does not properly set
 the replacement character
In-Reply-To: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
References: <3PIGaLpFxVwtChhNZPyo0Xi-ndm0_yWMz6aRvTtY0vs=.8eb2a779-3f94-482d-a6df-8754da1cb9dd@github.com>
Message-ID: <kz6LsaMaYdFHCvkG2TWjJ3qxGzeLWoylHJAIRxYmNsw=.f4ca5b38-898a-4cdd-9071-6227e160e373@github.com>

On Tue, 5 Aug 2025 08:17:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fix `HKSCS` encoder to correctly set the replacement character, and add tests to verify the `CodingErrorAction.REPLACE` behavior of all available encoders.

This pull request has now been integrated.

Changeset: c31f4861
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c31f4861fb6c85c31348ac3e99ccf754d9ee1a60
Stats:     445 lines in 3 files changed: 434 ins; 9 del; 2 mod

8364365: HKSCS encoder does not properly set the replacement character

Reviewed-by: sherman

-------------

PR: https://git.openjdk.org/jdk/pull/26635

From vyazici at openjdk.org  Mon Aug 11 09:12:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 09:12:20 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <DSOlcRGOZfhCrFYl8vDxGlyVcwfVf_HNqr8XoYcl0Bo=.8ec0f273-e39f-498e-af5c-ad87106e6616@github.com>

On Fri, 8 Aug 2025 22:37:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Shall we accompany the changes with a set of tests that verifies `java.time.Instant::parse` against all all ISO 8601 date formats?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3173872658

From naoto at openjdk.org  Mon Aug 11 16:42:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Aug 2025 16:42:09 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats
In-Reply-To: <55UQCywpNB4OPfqAgJhIcrJa9AIgxxQRe_gxZKWHj14=.9c7f3a6b-73d2-4b66-9054-a4dccc7c57ae@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <55UQCywpNB4OPfqAgJhIcrJa9AIgxxQRe_gxZKWHj14=.9c7f3a6b-73d2-4b66-9054-a4dccc7c57ae@github.com>
Message-ID: <lv1IywieSZztKrtgYlvOXSob_8GB8Vqsvpyer7wt5n0=.a2393b7c-792d-4da9-86d9-8aa6890d4b8c@github.com>

On Sat, 9 Aug 2025 13:52:45 GMT, ExE Boss <duke at openjdk.org> wrote:

> How?about using different patterns for?parsing and?printing instead?

In fact, the current `DateTimeFormatterBuilder.InstantPrinterParser` already use different behavior for formatting, i.e., only print time in "Z" (no offset).

The following change:

--- a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
+++ b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
@@ -3887,7 +3887,7 @@ public int parse(DateTimeParseContext context, CharSequence text, int position)
                     .appendValue(MINUTE_OF_HOUR, 2).appendLiteral(':')
                     .appendValue(SECOND_OF_MINUTE, 2)
                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
-                    .appendOffsetId()
+                    .appendOffset("+HH:mm:ss", "Z")
                     .toFormatter().toPrinterParser(false);
             DateTimeParseContext newContext = context.copy();
             int pos = parser.parse(newContext, text, position);

will parse hour-only offset for `Instant.parse()` but I am not sure we would go for this, as other `ISO` formatters all use "MM" for minutes. @jodastephen any suggestions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3175834055

From naoto at openjdk.org  Mon Aug 11 16:47:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Aug 2025 16:47:09 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats
In-Reply-To: <DSOlcRGOZfhCrFYl8vDxGlyVcwfVf_HNqr8XoYcl0Bo=.8ec0f273-e39f-498e-af5c-ad87106e6616@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <DSOlcRGOZfhCrFYl8vDxGlyVcwfVf_HNqr8XoYcl0Bo=.8ec0f273-e39f-498e-af5c-ad87106e6616@github.com>
Message-ID: <DXfslHuZDSV4zDO08UEoFH1y2bCnWtzWOQVpAsOp7QA=.2c0ea2b6-08cc-4f67-bf3a-9ba917efcbfe@github.com>

On Mon, 11 Aug 2025 09:09:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Shall we accompany the changes with a set of tests that verifies `java.time.Instant::parse` against all all ISO 8601 date formats?

I don't think `Instant.parse()` allows all permitted zone offset styles in ISO, only allowing "+HH:MM:ss" in strict mode. If the user wants to allow all of the format, they would be able to create a custom formatter in lenient mode and use the pattern "+HH" for offset parsing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3175848523

From chen.l.liang at oracle.com  Mon Aug 11 22:29:46 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 11 Aug 2025 22:29:46 +0000
Subject: <i18n dev> I'd like add no-argument overloads to CharSequence,
 String, and StringBuilder  (JDK-8364007)
In-Reply-To: <TYVPR01MB11356758C6F8D586191C3061B9120A@TYVPR01MB11356.jpnprd01.prod.outlook.com>
References: <TYVPR01MB11356758C6F8D586191C3061B9120A@TYVPR01MB11356.jpnprd01.prod.outlook.com>
Message-ID: <SJ2PR10MB766948E7FF95F8E1862CD113A228A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Uchino, I think your request is sensible in general.

Do you intend to require a beginIndex for the codePointCount for String? I think a no-arg version suffices.

Also forwarding this to i18n-dev as it is the locale-related list.

P.S. When you reply, make sure you click "Reply all" so all the recipients of this current mail gets your reply. Otherwise, the reply is only sent to me, and others on the list won't see your reply.

Regards, Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Uchino Tatsunori <tats.u at live.jp>
Sent: Monday, August 11, 2025 6:54 AM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: I'd like add no-argument overloads to CharSequence, String, and StringBuilder (JDK-8364007)

Dear core-libs developers,

I'd like to add the following overloads:

? Character.codePointCount(CharSequence seq)
? Character.codePointCount(char[] a)
? String.codePointCount(int beginIndex)
? StringBuffer.codePointCount()
? StringBuilder.codePointCount()

and created a patch (https://github.com/openjdk/jdk/pull/26461).

Why:

There have already been similar overloads with the start and end indicies by JSR 204 (JDK-4985217). They are thought to have been designed with a priority on versatility. They make the specification of indices mandatory, but have the following disadvantages:

1. The string expression have to be written twice. Unlike C#, Java has no equivalent of extended methods.
2. Unneccesary boundary checks are mixed in.
3. The most userland code tries to calculate the number of code points in the entire stirng.
4. Some other languages can count the number of code points in a single function without extra arguments (e.g. len() in Python3)

For 3., e.g.:

? VARCHAR in MySQL & PostgreSQL counts the number of characters in the unit of code points. e.g. VARCHAR(20) means that the limit is 20 code points, not 20 UTF-16 code units (20 chars in Java)
? NIST Special Publication 800-63B stiplates that the password length must be counted as the unit of code points. (Quote from https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers : "For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.")

I would like to get agreement on these changes and would like to know what I have to do outside of GitHub (e.g how to submit CSRs). If you have a GitHub account, it would be helpful if you could reply to the PR. If not, you can reply directly to this email.

Best Regards,

Tatsunori Uchino
https://github.com/tats-u/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/i18n-dev/attachments/20250811/dbac2adf/attachment-0001.htm>

From tats.u at live.jp  Mon Aug 11 23:37:48 2025
From: tats.u at live.jp (Uchino Tatsunori)
Date: Tue, 12 Aug 2025 08:37:48 +0900
Subject: <i18n dev> I'd like add no-argument overloads to CharSequence,
 String, and StringBuilder  (JDK-8364007)
In-Reply-To: <SJ2PR10MB766948E7FF95F8E1862CD113A228A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <TYVPR01MB11356224F9CB1EF0786E2E6829128A@TYVPR01MB11356.jpnprd01.prod.outlook.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/i18n-dev/attachments/20250812/2af56ad0/attachment-0001.htm>

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from 4
 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>

This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).

My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have ploughed through test cases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

After the review, I will update the copyrights.

I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

I got 4 timing related faults:
1) runtime/Thread/TestThreadDumpMonitorContention.java
   This is probably: https://bugs.openjdk.org/browse/JDK-8361370
2) sun/tools/jhsdb/BasicLauncherTest.java
   I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
3) gc/stress/TestReclaimStringsLeaksMemory.java
   I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
4) sun/security/ssl/X509KeyManager/CertChecking.java
   This is a new test that I got on last rebase. I have added a timeout of 480 to it.

In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.

>From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

-------------

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> sun/tools/jhsdb/BasicLauncherTest.java
> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.

@lkorinth Can you send me a link to the failure?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271883564

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271888024

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3114280042

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2272745651

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273410872

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > sun/tools/jhsdb/BasicLauncherTest.java
> > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273468852

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  After suggestions from Erik and Andrey

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From lkorinth at openjdk.org  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273621868

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273614076

From dnsimon at openjdk.org  Thu Aug 14 19:33:15 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Aug 2025 19:33:15 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v2]
In-Reply-To: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
Message-ID: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>

On Wed, 13 Aug 2025 14:22:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   After suggestions from Erik and Andrey

> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

Would you mind also running tier9 to avoid surprises there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422

From serb at openjdk.org  Thu Aug 14 22:16:11 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 14 Aug 2025 22:16:11 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize()
In-Reply-To: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
Message-ID: <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>

On Fri, 8 Aug 2025 21:38:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize() from WInputMethod.java - it is used to free a native id.
> Also the reason dispose() didn't free it seems no longer relevant.
> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.

src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java line 165:

> 163:     @Override
> 164:     public void dispose() {
> 165:         disposerRecord.dispose();

The native dispose will call `ImmDestroyContext` which is specified as:
> However, before calling ImmDestroyContext, the application must remove the input context from any association with windows in the thread by using the [ImmAssociateContext](https://learn.microsoft.com/en-us/windows/desktop/api/imm/nf-imm-immassociatecontext) function.

I did not check the code, but maybe we are calling `ImmAssociateContext` in the wrong moment and have to postpone this "dispose" until all the object is really unused?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2277816637

From naoto at openjdk.org  Thu Aug 14 23:28:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:28:26 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v2]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <OU40d8bs-zjJAWpFLKa4VjqmzU5-_0Mdh0Sxnl6NlUY=.e4238b1c-8879-4219-a600-819478143d2a@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  allow hour-only offsets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/7fc267a3..5658f255

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=00-01

  Stats: 43 lines in 3 files changed: 36 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Thu Aug 14 23:37:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:37:53 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v3]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <jKqMDS6cJwTbsYUJb9Espr37TAVd6axWXzMAbyhAeXo=.1fc66658-4c77-49da-ace0-bd2e5d96c4d1@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  allow all ISO 8601 offsets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/5658f255..048f5eab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=01-02

  Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Thu Aug 14 23:49:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:49:25 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v4]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  test cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/048f5eab..fa198b88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=02-03

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From naoto at openjdk.org  Thu Aug 14 23:53:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Aug 2025 23:53:16 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v4]
In-Reply-To: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
Message-ID: <S7qhOknwX7bKJWtUs66Jim_nB4MdyU_aecjkkc2rypw=.6d77f8d3-2223-4ae9-8206-1beefebb3a80@github.com>

On Thu, 14 Aug 2025 23:49:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases

Changed the proposed fix to leniently allow all ISO 8601 offsets by using "+HH" as the pattern.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26708#issuecomment-3190223880

From vyazici at openjdk.org  Fri Aug 15 09:12:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 15 Aug 2025 09:12:13 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v4]
In-Reply-To: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
Message-ID: <SA4mEI5wxD2hBNl-gUQJJM_cqpd7LJes27I3hRsKcVU=.93131aea-6d17-4892-8c3c-eda41b47124f@github.com>

On Thu, 14 Aug 2025 23:49:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases

Thanks for adding the tests. In its current state, it LGTM based on my limited understanding. I'll leave the final approval to those more knowledgeable in this area.

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1:

> 1: /*

Doesn't copyright year need a bump?

test/jdk/java/time/test/java/time/TestInstant.java line 179:

> 177:             {"2017-01-01T00:00:00.000+0"},
> 178:             {"2017-01-01T00:00:00.000+0:"},
> 179:             {"2017-01-01T00:00:00.000+02:"},

It is nice that leniency allows `0200` (i.e., missing white space), but not `02:` or `02:00:` (i.e., trailing separators).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3123312615
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2278580535
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2278597174

From scolebourne at openjdk.org  Fri Aug 15 10:34:15 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Fri, 15 Aug 2025 10:34:15 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v4]
In-Reply-To: <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <dEJAiHGecqjv9B5H478TDw4N_u8dRI-fBrcMr0b32EU=.69d9f074-4d5c-469d-8049-56a247b240a0@github.com>
Message-ID: <aElY2nzXve1s-OajB_H8StlgnZehnkkHMCB5GJbgH6U=.21f9b2e4-a469-47df-aee1-122fa7088fa2@github.com>

On Thu, 14 Aug 2025 23:49:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases

Looks like a good solution to the problem, thanks.

-------------

Marked as reviewed by scolebourne (Author).

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3123565912

From lkorinth at openjdk.org  Fri Aug 15 11:43:33 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:43:33 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From lkorinth at openjdk.org  Fri Aug 15 11:59:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:59:12 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <iWlp9Azqc_MsGBnk-PK8OYZqpcnhSASRJmnz8IgzTQI=.965cedce-3e5a-40e5-9e86-9b1f5c2d2021@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Added three new `/timeout=480` after the last run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090

From syan at openjdk.org  Fri Aug 15 14:08:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 14:08:12 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2279056261

From naoto at openjdk.org  Fri Aug 15 16:52:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Aug 2025 16:52:01 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v5]
In-Reply-To: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
Message-ID: <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>

> `Instant.parse()` is expected to use the offset zone pattern `+HH:mm:ss` (as defined by `DateTimeFormatterBuilder.appendOffsetId()`), but it fails to parse hour-only offsets such as `+02`. This is because the actual implementation uses `+HH:MM:ss` as the pattern. While replacing the pattern in the implementation as with the specification would allow hour-only offsets, it would also introduce compatibility issues, i.e., printing would omit the minutes field when it is zero. So, it is preferable to update the specification to match the implementation. A CSR has also been drafted for this change.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/fa198b88..7523e344

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26708&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26708/head:pull/26708

PR: https://git.openjdk.org/jdk/pull/26708

From prr at openjdk.org  Fri Aug 15 19:02:10 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Aug 2025 19:02:10 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize()
In-Reply-To: <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>
Message-ID: <haYFtgNWOsWdvIIASSVV3jrxG9ThC-6_RQB4h-FPkm4=.3e5b5cfb-7fd5-40a4-8e1c-edfb6b35aa31@github.com>

On Thu, 14 Aug 2025 22:13:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Remove finalize() from WInputMethod.java - it is used to free a native id.
>> Also the reason dispose() didn't free it seems no longer relevant.
>> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
>> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.
>
> src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java line 165:
> 
>> 163:     @Override
>> 164:     public void dispose() {
>> 165:         disposerRecord.dispose();
> 
> The native dispose will call `ImmDestroyContext` which is specified as:
>> However, before calling ImmDestroyContext, the application must remove the input context from any association with windows in the thread by using the [ImmAssociateContext](https://learn.microsoft.com/en-us/windows/desktop/api/imm/nf-imm-immassociatecontext) function.
> 
> I did not check the code, but maybe we are calling `ImmAssociateContext` in the wrong moment and have to postpone this "dispose" until all the object is really unused?

This seems to be done by a native method WInputMethod.disableNativeIME(..) - which sets the IME for the window to NULL.  The native method is called from various places in WInputMethod.
I can't see that dispose or finalize would do anything to ensure that is called, or introduce any timing issues either way. So if there's a problem it is un-related.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2279695793

From serb at openjdk.org  Fri Aug 15 20:13:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Aug 2025 20:13:09 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize()
In-Reply-To: <haYFtgNWOsWdvIIASSVV3jrxG9ThC-6_RQB4h-FPkm4=.3e5b5cfb-7fd5-40a4-8e1c-edfb6b35aa31@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>
 <haYFtgNWOsWdvIIASSVV3jrxG9ThC-6_RQB4h-FPkm4=.3e5b5cfb-7fd5-40a4-8e1c-edfb6b35aa31@github.com>
Message-ID: <mvREF1kqmZjo-lY7XzSfcS-HcXMIjBW5QMkvIwnlx1w=.5b527fa4-6617-485d-ac23-2bc159b6bac8@github.com>

On Fri, 15 Aug 2025 18:59:22 GMT, Phil Race <prr at openjdk.org> wrote:

>I can't see that dispose or finalize would do anything to ensure that is called, or introduce any timing issues either way. So if there's a problem it is un-related.

Maybe disableNativeIME is called when the top level Window is disposed, and after that there are no more references to WInputMethod? In that case, it is safe to call it from finalize(), but it might not be as safe to call it from dispose(), which mighe be called before "WInputMethod.disableNativeIME"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2279803095