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

From lkorinth at openjdk.org  Mon Aug 18 09:10:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:10:13 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
Message-ID: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>

On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> 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()

It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:18:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:18:12 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
Message-ID: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>

On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> 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()
>
> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

It is also something that can be changed later, in a follow up fix.

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

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

From vyazici at openjdk.org  Mon Aug 18 09:21:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 18 Aug 2025 09:21:12 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v5]
In-Reply-To: <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
Message-ID: <3v62VnuJiyQ7CWHZt2fcDULp6ToDtFLr1G8IXqAFkx0=.875ef0ae-c69d-4993-a758-621dab89d123@github.com>

On Fri, 15 Aug 2025 16:52:01 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:
> 
>   copyright year update

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3127527503

From lkorinth at openjdk.org  Mon Aug 18 09:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:36:13 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v2]
In-Reply-To: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
 <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com>

On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > 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.

I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list).

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:43:14 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:43:14 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: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@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

If there are no mayor objections, I will update the copyrights before I leave work today.

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

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

From dfuchs at openjdk.org  Mon Aug 18 11:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 11:38:14 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: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@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

Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:


	java/net/httpclient/CancelledResponse.java
	java/net/httpclient/whitebox/FlowTestDriver.java


The	first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

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

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

From rgiulietti at openjdk.org  Mon Aug 18 13:08:11 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Aug 2025 13:08:11 GMT
Subject: <i18n dev> RFR: 8362448: Make use of the
 Double.toString(double) algorithm in java.text.DecimalFormat [v2]
In-Reply-To: <SgyqhFlGbzacV_bV9cWNYUiwfVeIwt9PaQnbFSzyc3c=.52676b13-0e61-49d4-bfbf-528c3fd67934@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
 <o9PEv-AjuFI373A-GJqunNxwL_xxxm4erHyqFn2uEVs=.404dd4e1-cd90-4db5-bc27-254d1c740fb0@github.com>
 <SgyqhFlGbzacV_bV9cWNYUiwfVeIwt9PaQnbFSzyc3c=.52676b13-0e61-49d4-bfbf-528c3fd67934@github.com>
Message-ID: <zzQJxUf8uS-jS6-_Oi34rVO952yeaB7cQnwkv86BAyU=.d8646525-32aa-4984-bebb-e61d69d85f7d@github.com>

On Thu, 17 Jul 2025 19:37:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Good to see this enhancement, Raffaello. Are you planning to provide some test cases for the change, confirming the implementation switches between old/new depending on the system property?
>
>> @naotoj Do you mean adding a test with values known to have slightly different outcomes? Sure, will do.
> 
> Yes, as in the JBS issue

@naotoj I'm requesting a review because of a merge with conflict resolved by hand. Tier1-3 pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/26364#issuecomment-3196750262

From rriggs at openjdk.org  Mon Aug 18 13:15:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 13:15:11 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: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@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

Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings.  The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

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

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

From rgiulietti at openjdk.org  Mon Aug 18 13:26:12 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Aug 2025 13:26:12 GMT
Subject: <i18n dev> RFR: 8362448: Make use of the
 Double.toString(double) algorithm in java.text.DecimalFormat [v8]
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: <hsOgY6PV7oL6hnf9Hei5fouDy80tDnVMox4Wm7cpInE=.35f5aec4-fe97-46b5-9dad-bdeee878c1a9@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 15 commits:

 - Merge branch 'master' into 8362448
 - 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.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/c1198bba...52bff4c1

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

Changes: https://git.openjdk.org/jdk/pull/26364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26364&range=07
  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 lkorinth at openjdk.org  Mon Aug 18 14:34:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 14:34:12 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
Message-ID: <lSUzoh2lhdmeEPYY2eAAGIycS8QSm5_9BLFy7FgOfFw=.f7a8acc4-ead5-4625-9d3c-83a345212193@github.com>

On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change!

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

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

From lmesnik at openjdk.org  Mon Aug 18 15:01:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 18 Aug 2025 15:01: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: <O_WRSR2Q7KM1CWMYPxfXyFQI3lU9AjTOklWNVYAxvUk=.387e933f-0eed-43d8-a2eb-dbe2dd98cc75@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

Thank you for fixing this! I think the changes are good.

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

Marked as reviewed by lmesnik (Reviewer).

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

From naoto at openjdk.org  Mon Aug 18 16:02:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 16:02:13 GMT
Subject: <i18n dev> RFR: 8362448: Make use of the
 Double.toString(double) algorithm in java.text.DecimalFormat [v8]
In-Reply-To: <hsOgY6PV7oL6hnf9Hei5fouDy80tDnVMox4Wm7cpInE=.35f5aec4-fe97-46b5-9dad-bdeee878c1a9@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <hsOgY6PV7oL6hnf9Hei5fouDy80tDnVMox4Wm7cpInE=.35f5aec4-fe97-46b5-9dad-bdeee878c1a9@github.com>
Message-ID: <Aysngd8BySGcY89JAJXQc3aO8ez9579YttgivCwx96Q=.3667deb4-481c-4fbd-b1bd-5461c3e510c5@github.com>

On Mon, 18 Aug 2025 13:26:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> 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 15 commits:
> 
>  - Merge branch 'master' into 8362448
>  - 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.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/c1198bba...52bff4c1

LGTM as before

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26364#pullrequestreview-3128984140

From rgiulietti at openjdk.org  Mon Aug 18 16:15:25 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Aug 2025 16:15:25 GMT
Subject: <i18n dev> Integrated: 8362448: Make use of the
 Double.toString(double) algorithm in java.text.DecimalFormat
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: <TT6983mEefZmoqXlgcmHwY6OHgrPFxSlH-0eOSRu3rU=.235c7ca5-947b-4231-bedf-9baf093645ed@github.com>

On Thu, 17 Jul 2025 10:04:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 285adff2
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/285adff24e869b62397d4d1c14e6e969f3285836
Stats:     190 lines in 7 files changed: 140 ins; 7 del; 43 mod

8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat

Reviewed-by: naoto, jlu

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

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

From lkorinth at openjdk.org  Mon Aug 18 16:34:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:21 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@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 suggestion from Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/8fa40e7d..286a2cc6

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

  Stats: 3 lines in 2 files 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  Mon Aug 18 16:34:22 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:22 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
Message-ID: <KNNxBq11P7lT_D16Mzwx-_VHkNITiw5wQbuYCf58yQI=.cdcf7871-b20c-4e44-b10e-c6108e647afb@github.com>

On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:
> 
> ```
> 	java/net/httpclient/CancelledResponse.java
> 	java/net/httpclient/whitebox/FlowTestDriver.java
> ```
> 
> The first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

Fixed! Thanks for helping!

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

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

From dfuchs at openjdk.org  Mon Aug 18 16:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 16:46:13 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <a3CwlSQwHYj_F3fC30zoiDhXf9G-cn5xK8ZwVFmxBd0=.afdaf352-e494-4bc6-adf2-dc5afa0dd4b9@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

Thanks! Changes to JNDI / net / httpclient LGTM.

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

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

From rriggs at openjdk.org  Mon Aug 18 18:16:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 18:16:17 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v5]
In-Reply-To: <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
Message-ID: <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>

On Fri, 15 Aug 2025 16:52:01 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:
> 
>   copyright year update

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1205:

> 1203:      * {@link DateTimeFormatterBuilder#appendOffset(String, String)
> 1204:      * appendOffset("+HH", "Z")} in lenient mode will be used to parse the offset,
> 1205:      * converting the instant to UTC as necessary.

Suggestion:

     * When parsing, the lenient mode behavior of
     * {@link DateTimeFormatterBuilder#appendOffset(String, String)
     * appendOffset("+HH", "Z")} will be used to parse the offset,
     * converting the instant to UTC as necessary.

The phrase "in lenient mode" after the mention of appendOffset made me think the caller had to set lenient mode.
Here and below in DateTimeFormatterBiulder.java.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3893:

> 3891:                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
> 3892:                     .parseLenient()
> 3893:                     .appendOffset("+HH", "Z")

The "+HH" pattern is supposed to be ignoring minutes and seconds but it does not appear to.  In jshell, I see:

jshell> Instant.parse("2017-01-01T00:00:00.000-02:10:12")
$8 ==> 2017-01-01T02:10:12Z

It would be more consistent with the original pattern to use `"+HH:mm:ss"`

test/jdk/java/time/test/java/time/TestInstant.java line 170:

> 168:     @Test(dataProvider = "valid_instants")
> 169:     public void test_parse_valid(String instant) {
> 170:         Instant.parse(instant);

The test should verify the correct time is parsed.
And include cases where the minute and second are non-zero.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283043042
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283113795
PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283096548

From naoto at openjdk.org  Mon Aug 18 19:14:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 19:14:08 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v6]
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: <1IFvzeiRjMlxZsy5dKIb-owi972J3jgN-K9Vry3E78g=.1afc0e1e-70ff-4712-a1ae-44f4b5039ffa@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:

  Update src/java.base/share/classes/java/time/format/DateTimeFormatter.java
  
  Right. Changing to your suggested wording
  
  Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/7523e344..8bc222af

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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  Mon Aug 18 19:19:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 19:19:08 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v7]
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: <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - DateTimeFormatterBuilder wording
 - Added non-zero offset test cases
 - Merge branch 'master' into JDK-8364752-Instant-ISO8601
 - Update src/java.base/share/classes/java/time/format/DateTimeFormatter.java
   
   Right. Changing to your suggested wording
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - copyright year update
 - test cases
 - allow all ISO 8601 offsets
 - allow hour-only offsets
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26708/files
  - new: https://git.openjdk.org/jdk/pull/26708/files/8bc222af..0d78a520

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

  Stats: 16207 lines in 511 files changed: 8985 ins; 5233 del; 1989 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  Mon Aug 18 19:19:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 19:19:17 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v5]
In-Reply-To: <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
 <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
Message-ID: <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>

On Mon, 18 Aug 2025 18:12:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year update
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3893:
> 
>> 3891:                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
>> 3892:                     .parseLenient()
>> 3893:                     .appendOffset("+HH", "Z")
> 
> The "+HH" pattern is supposed to be ignoring minutes and seconds but it does not appear to.  In jshell, I see:
> 
> jshell> Instant.parse("2017-01-01T00:00:00.000-02:10:12")
> $8 ==> 2017-01-01T02:10:12Z
> 
> It would be more consistent with the original pattern to use `"+HH:mm:ss"`

IIUC, "ignoring minutes and seconds" refers to formatting, i.e, "-02:10:12" only prints "-02" Parsing offsets in lenient mode always parses minute/seconds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283235663

From jlu at openjdk.org  Mon Aug 18 22:13:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Aug 2025 22:13:53 GMT
Subject: <i18n dev> Integrated: 8364780: Unicode extension clarifications
 for NumberFormat/DecimalFormatSymbols
In-Reply-To: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
References: <snTBit55f0jn39c-7lRHG1bnq7JsIxkjSKmhWEn9BRo=.ce610445-eda3-4d13-a5bf-825980ee9951@github.com>
Message-ID: <2lsuTxa7zfKW1N3K8UzlF2Mcz1InCvkgN60Kb3t7gLE=.cfb04e36-33b2-4547-a897-ba2703780684@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.

This pull request has now been integrated.

Changeset: a0053012
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0053012a4423725eac2411239bd28642ff3b321
Stats:     16 lines in 2 files changed: 6 ins; 0 del; 10 mod

8364780: Unicode extension clarifications for NumberFormat/DecimalFormatSymbols

Reviewed-by: naoto

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

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

From rriggs at openjdk.org  Mon Aug 18 22:31:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 22:31:50 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v5]
In-Reply-To: <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
 <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
 <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>
Message-ID: <wtUNw3nQaxX4ibMQy9JVjm6M0e2uszjLON6Xkl6C6nE=.ccd1d557-915e-4a9c-ae1b-868b04b5e604@github.com>

On Mon, 18 Aug 2025 19:17:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3893:
>> 
>>> 3891:                     .appendFraction(NANO_OF_SECOND, minDigits, maxDigits, true)
>>> 3892:                     .parseLenient()
>>> 3893:                     .appendOffset("+HH", "Z")
>> 
>> The "+HH" pattern is supposed to be ignoring minutes and seconds but it does not appear to.  In jshell, I see:
>> 
>> jshell> Instant.parse("2017-01-01T00:00:00.000-02:10:12")
>> $8 ==> 2017-01-01T02:10:12Z
>> 
>> It would be more consistent with the original pattern to use `"+HH:mm:ss"`
>
> IIUC, "ignoring minutes and seconds" refers to formatting, i.e, "-02:10:12" only prints "-02" Parsing offsets in lenient mode always parses minute/seconds.

True, but you have to read further into the `appendOffset` prose to know that the minutes and sections can be present. Using the full pattern would convey more quickly the full syntax being parsed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283632033

From naoto at openjdk.org  Mon Aug 18 22:43:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Aug 2025 22:43:39 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v5]
In-Reply-To: <wtUNw3nQaxX4ibMQy9JVjm6M0e2uszjLON6Xkl6C6nE=.ccd1d557-915e-4a9c-ae1b-868b04b5e604@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <xCRW0lAI5SXmnYnmUQfRM-2HsdlXEvHDYQrALtnQ15Y=.2560c1c1-4467-42b3-a5ff-007e807172f0@github.com>
 <i_4V4Hn_DwkOYIrpddbP3SNjcJkOUS9ndQRR7MAbzQs=.94815b5e-415c-4b4e-be55-7f32dfe6809a@github.com>
 <OiWEUvmIMQdPXE9gPc004jGGJqmlj5-WVlTioYxFOBw=.27ffcbcd-54b5-4fb4-a80c-a73911a28b4c@github.com>
 <wtUNw3nQaxX4ibMQy9JVjm6M0e2uszjLON6Xkl6C6nE=.ccd1d557-915e-4a9c-ae1b-868b04b5e604@github.com>
Message-ID: <vfKT5-XqbFNY0MuGSm4fjDwW0-RudyXXRf9RrswQ2as=.c40382dc-308c-4269-af32-558fef419164@github.com>

On Mon, 18 Aug 2025 22:28:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> IIUC, "ignoring minutes and seconds" refers to formatting, i.e, "-02:10:12" only prints "-02" Parsing offsets in lenient mode always parses minute/seconds.
>
> True, but you have to read further into the `appendOffset` prose to know that the minutes and sections can be present. Using the full pattern would convey more quickly the full syntax being parsed.

Using the full pattern means the colons may not be optional. The `appendOffset` spec reads:

If the specified pattern is "+HH", the presence of colons is determined by whether the character after the hour digits is a colon or not.

Among the supported patterns, only "+HH" (and I believe "+H" too) take the colons optional in lenient mode, i.e, both "+02:00" and "+0200" are allowed, which suits the ISO 8601 offset format.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26708#discussion_r2283644271

From syan at openjdk.org  Tue Aug 19 03:34:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 03:34:47 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
Message-ID: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>

On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.
>
> It is also something that can be changed later, in a follow up fix.

Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable.

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

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

From dholmes at openjdk.org  Tue Aug 19 05:25:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:25:40 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
Message-ID: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> It is also something that can be changed later, in a follow up fix.
>
> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.

> It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. 

What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources.

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

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

From dholmes at openjdk.org  Tue Aug 19 05:49:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:49:44 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

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

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

From dholmes at openjdk.org  Tue Aug 19 06:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:07:44 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
Message-ID: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
>> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.
>
> DELETED - I confused the timeout with the timeout-factor. New comment below.

No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 

However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

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

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

From syan at openjdk.org  Tue Aug 19 06:40:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 06:40:45 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>

On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
> 
> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.

The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

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

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

From lkorinth at openjdk.org  Tue Aug 19 09:02:36 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:02:36 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
Message-ID: <uOH12UfZUHixcxSAx8lP66zvzxKr50yUj8x4_x22Su0=.31769f01-81c4-48b0-9050-f642c562deb5@github.com>

On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while.

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

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

From lkorinth at openjdk.org  Tue Aug 19 09:19:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:19:45 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <BM1P_203-vMLbBYxbzigREy0NuHWoZqfgQvmGV0SH7I=.bf66ee89-19a9-4212-b800-08e7c835f4de@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.

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

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

From prr at openjdk.org  Tue Aug 19 16:47:43 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Aug 2025 16:47:43 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
Message-ID: <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@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.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8365180

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26706/files
  - new: https://git.openjdk.org/jdk/pull/26706/files/fc422aa0..3c8c9cb4

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 prr at openjdk.org  Tue Aug 19 16:47:44 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Aug 2025 16:47:44 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <mvREF1kqmZjo-lY7XzSfcS-HcXMIjBW5QMkvIwnlx1w=.5b527fa4-6617-485d-ac23-2bc159b6bac8@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>
 <mvREF1kqmZjo-lY7XzSfcS-HcXMIjBW5QMkvIwnlx1w=.5b527fa4-6617-485d-ac23-2bc159b6bac8@github.com>
Message-ID: <e8mTx75CXVhsoHJMihw2dd5rpAyqqBXWIkNHx-8ths0=.a5c06de6-f8c4-464a-b6c6-a0f39537acff@github.com>

On Fri, 15 Aug 2025 20:10:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Maybe disableNativeIME is called when the top level Window is disposed, 

No it is not.  

 Nothing calls disableNativeIME when the window is disposed. I tried this with the disposer removed and finalize restored just to be sure.

Also it needs to be called 'early' but not 'too early' during WIndow.dispose()
If the input method is active when you try to dispose it via APIs like disableNativeIM() then an exception is thrown.

If you call it too late - after removeNotify()  then it will not be sent because the peer is now nulled out.


src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp
@@ -1082,6 +1082,7 @@ LRESULT CALLBACK AwtToolkit::WndProc(HWND hWnd, UINT message,
           AwtComponent* comp = (AwtComponent*)JNI_GET_PDATA(peer);
           if (comp != NULL)
           {
               comp->SetInputMethod(self, useNativeCompWindow);
comp->ImmAssociateContext((HIMC)((intptr_t)context));
           }

Since we never call it, then this migration to disposer changes nothing.
If we do call it I  think it should be called in WInputMethod.removeNotify() which will clearly be before dispose().
I will add that and we'll be better off then we were before this change.

 I also found that if the window has focus when it is dispose()'d that it will receive a focus lost event which ironically creates a new WInputMethod because Window.dispose() had nulled out the existing one 

Either don't null out the disposed one, or do something else to avoid re-creation, or decide that it is harmless .
For now I will leave that as it seems to be harmless, pre-existing and un-related to this change, although a little wasteful. It also would be more than a windows-only change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2285798990

From rriggs at openjdk.org  Tue Aug 19 18:24:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 18:24:39 GMT
Subject: <i18n dev> RFR: 8364752: Class java.time.Instant cannot parse
 all ISO 8601 date formats [v7]
In-Reply-To: <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@github.com>
Message-ID: <s6qohQ84R83TldxAsQgwbuw7c_kd3zgicMU3eLRs8Sc=.d40bb109-9d53-46af-bae9-cbe5d2ecb72c@github.com>

On Mon, 18 Aug 2025 19:19:08 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - DateTimeFormatterBuilder wording
>  - Added non-zero offset test cases
>  - Merge branch 'master' into JDK-8364752-Instant-ISO8601
>  - Update src/java.base/share/classes/java/time/format/DateTimeFormatter.java
>    
>    Right. Changing to your suggested wording
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - copyright year update
>  - test cases
>  - allow all ISO 8601 offsets
>  - allow hour-only offsets
>  - initial commit

Looks good, thanks for the explanation of the parsing format.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26708#pullrequestreview-3133368081

From serb at openjdk.org  Wed Aug 20 02:33:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 20 Aug 2025 02:33:38 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
Message-ID: <nRMLpo0Ge-P1-3KnOxc9MOaeE1zgeel4fMUGWGae_uw=.cd663f4d-c64e-47a9-9939-48fc03fde072@github.com>

On Tue, 19 Aug 2025 16:47:43 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.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365180

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26706#pullrequestreview-3134581026

From dholmes at openjdk.org  Wed Aug 20 12:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:55:43 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

@sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

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

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

From syan at openjdk.org  Wed Aug 20 14:28:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 14:28:43 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
Message-ID: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>

On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
>> 
>> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.

So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).

I do agree this change, what I mean is this change has some side effect.

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

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

From ihse at openjdk.org  Wed Aug 20 15:19:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:19:42 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

I don't think there is any point linking to the build source code. 

Suggestion:

certain amount of time will apply this factor. If you run in
forced compilation mode (`-Xcomp`) using `make test`, it
will automatically adjust this factor to compensate for the
interpreter not being as fast as JITed code. Defaults to 1.

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

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

From ihse at openjdk.org  Wed Aug 20 15:24:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:24:39 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.

I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 

Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

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

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

From lkorinth at openjdk.org  Wed Aug 20 16:27:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 16:27:39 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
Message-ID: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>

On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> I don't think there is any point linking to the build source code. 
> 
> Suggestion:
> 
> certain amount of time will apply this factor. If you run in
> forced compilation mode (`-Xcomp`) using `make test`, it
> will automatically adjust this factor to compensate for the
> interpreter not being as fast as JITed code. Defaults to 1.

I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

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

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

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@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:

  update testing.md, remove makefile link, fix bad text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72

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

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 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 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
 <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com>

On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> I don't think there is any point linking to the build source code. 
>> 
>> Suggestion:
>> 
>> certain amount of time will apply this factor. If you run in
>> forced compilation mode (`-Xcomp`) using `make test`, it
>> will automatically adjust this factor to compensate for the
>> interpreter not being as fast as JITed code. Defaults to 1.
>
> I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

fixed

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

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

From rriggs at openjdk.org  Wed Aug 20 18:50:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Aug 2025 18:50:38 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: <fYYfecViE1BAbpAbognD5xYVaKOXUT2p9tW1s-UEdBo=.80a4044f-2e67-455b-a779-0418e48116f7@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()`

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

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

From ihse at openjdk.org  Wed Aug 20 19:36:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 19:36:44 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <Pw1uYaqAPK95BsoZ0xgNA1c3rsXjxHCiz-xACzocwqA=.e6cb7fcf-4438-4e4a-aeef-7d9c707c87c8@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

Build changes look good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

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

From dholmes at openjdk.org  Wed Aug 20 21:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 21:32:39 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <j5ndr4sR6OHgBGlCY-e1I-VdfMKpG2GS98Wv2qbshtU=.d5aad200-1bc2-4080-ad71-218c59a7e491@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, 

@magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally).

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

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

From rriggs at openjdk.org  Wed Aug 20 21:38:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Aug 2025 21:38:41 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust [v3]
In-Reply-To: <y8vmYNc7ul7YQHkujvSffSg692k4JyJHzVXhfUnrOVg=.bbeb8e03-acd9-4126-b1b5-904c4525575f@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <y8vmYNc7ul7YQHkujvSffSg692k4JyJHzVXhfUnrOVg=.bbeb8e03-acd9-4126-b1b5-904c4525575f@github.com>
Message-ID: <zLExeDkIr47YdlPNVpwOy6rujn3hI7UZQhphSORXpnU=.8cb63f42-028c-4904-b169-6f613a4ac064@github.com>

On Sun, 10 Aug 2025 03:36:06 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.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @liach

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

> 132:      * @return the adjusted temporal, or the original if no overrides are present in the formatter
> 133:      * @implNote Optimizes for the common case where formatters don't specify chronology/time-zone
> 134:      *           by avoiding unnecessary processing. Most formatters have null for these properties.

@implNote should be before @param

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

> 144:         // The chronology and zone fields of Formatter are usually null,
> 145:         // so the non-null processing code is placed in a separate method
> 146:         return adjustWithOverride(temporal, overrideChrono, overrideZone);

The "so..." doesn't explain much, perhaps:
Placing the non-null cases in a separate method allows more flexible code optimizations"

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

> 239:             Chronology effectiveChrono,
> 240:             Chronology temporalChrono
> 241:     ) {

Join with previous line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2289343238
PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2289347338
PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2289356956

From swen at openjdk.org  Thu Aug 21 01:30:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 21 Aug 2025 01:30:52 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust [v4]
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: <KLDiI409LXdPnnWHas1azEznSgbvgxN1XG8QI6Nd_Vg=.500e93c1-69cb-4fca-91f2-a63ffc36c284@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 two additional commits since the last revision:

 - code style
 - implNote before param, from @RogerRiggs

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

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

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

  Stats: 12 lines in 1 file changed: 2 ins; 7 del; 3 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 lkorinth at openjdk.org  Thu Aug 21 09:12:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 21 Aug 2025 09:12:57 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
Message-ID: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>

On Wed, 20 Aug 2025 14:25:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.
>
> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
> 
> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
> 
> I do agree this change, what I mean is this change has some side effect.
> 
>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
> 
> I think I can try it in a new PR.

I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.

I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

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

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

From syan at openjdk.org  Thu Aug 21 09:52:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 21 Aug 2025 09:52:54 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v3]
In-Reply-To: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
 <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
Message-ID: <N_1V36WztAVi1O6SdDaGQXa4b8TGB7xGpz5T1TbxL9I=.ea0293e3-eb0b-4d96-bd40-d5c9c4e3fd1d@github.com>

On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
>> 
>> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
>> 
>> I do agree this change, what I mean is this change has some side effect.
>> 
>>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
>> 
>> I think I can try it in a new PR.
>
> I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.
> 
> I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

@lkorinth Thanks for your advice sincerely. I think you are right, we need more evaluate cautiously before start to change the timeoutFactor for -Xcomp.

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

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

From ihse at openjdk.org  Thu Aug 21 12:21:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Aug 2025 12:21:00 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <zgu5mLb1mA-ca4wxmJJjLNmmq3sJFwWtfjY4yRnmYFQ=.81a024ea-41ce-42cc-9038-3ef40e483793@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.
> 
> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 
> 
> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

> @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

That is surprising and a bit disappointing. I guess it is not worth the effort to try and figure out why this is the case; it could probably vary from test to test and be difficult to track for little gain. Still, it makes you wonder.

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

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

From rriggs at openjdk.org  Thu Aug 21 18:10:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Aug 2025 18:10:53 GMT
Subject: <i18n dev> RFR: 8365186: Reduce size of
 j.t.f.DateTimePrintContext::adjust [v4]
In-Reply-To: <KLDiI409LXdPnnWHas1azEznSgbvgxN1XG8QI6Nd_Vg=.500e93c1-69cb-4fca-91f2-a63ffc36c284@github.com>
References: <2_Fsw-CynfvnWaAnoJQoFbosirZOsM3PlwFjXdxSijI=.8b7eb403-69c5-4175-b409-2478803be5cb@github.com>
 <KLDiI409LXdPnnWHas1azEznSgbvgxN1XG8QI6Nd_Vg=.500e93c1-69cb-4fca-91f2-a63ffc36c284@github.com>
Message-ID: <TtF5MXQz3g4pYk-lLKGlRfGdSCqpdLca5IIzmH9mbPA=.a8696a3f-a5e3-443b-b76c-d74e73b4e86e@github.com>

On Thu, 21 Aug 2025 01:30:52 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.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - code style
>  - implNote before param, from @RogerRiggs

Looks fine

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26633#pullrequestreview-3141789230

From azvegint at openjdk.org  Fri Aug 22 00:30:51 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Aug 2025 00:30:51 GMT
Subject: <i18n dev> RFR: 8365180: Remove
 sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
Message-ID: <CULULS4-D9zUEfYnJn_E05E8ReSzYFUByOD8ll8MlEA=.5b65f494-04f3-4363-98ae-edd53aba84db@github.com>

On Tue, 19 Aug 2025 16:47:43 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.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365180

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26706#pullrequestreview-3142655536

From prr at openjdk.org  Fri Aug 22 04:31:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 04:31:55 GMT
Subject: <i18n dev> Integrated: 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: <NGFTDdTSnG7Hd7iRtUcKXOHrXwJS4K_JTeXSc_J9404=.1daff851-833d-450f-8342-2bacef4a0862@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.

This pull request has now been integrated.

Changeset: 8e448569
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e4485699235caff0074c4d25ee78539e57da63a
Stats:     29 lines in 2 files changed: 13 ins; 3 del; 13 mod

8365180: Remove sun.awt.windows.WInputMethod.finalize()

Reviewed-by: serb, azvegint

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

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

From prr at openjdk.org  Fri Aug 22 05:54:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 05:54:55 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:

> 48:  * @summary URL.getContent() should return SoundClip for supported formats
> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
> 50:  */

I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

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

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

From dholmes at openjdk.org  Fri Aug 22 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 06:38:56 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <GGszb14v2jX1mI4BbHtgkXQDlgFehKYtLl3yUr0zX40=.1952e76e-0a5c-4be9-944a-505f84d89624@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

@prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

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

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

From swen at openjdk.org  Fri Aug 22 15:59:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 22 Aug 2025 15:59:58 GMT
Subject: <i18n dev> Integrated: 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: <9sIIT8eDMKTzfnU8vZ81Ze5m8J7GkqIdfSrvqsEhvt0=.4fd77cdd-a259-4259-9132-863ee9272964@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.

This pull request has now been integrated.

Changeset: f5f414f9
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5f414f9fc67e55acb83e04ea270d39041cb6198
Stats:     87 lines in 1 file changed: 86 ins; 0 del; 1 mod

8365186: Reduce size of j.t.f.DateTimePrintContext::adjust

Reviewed-by: rriggs

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

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

From ayang at openjdk.org  Fri Aug 22 16:10:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 16:10:58 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

> Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480.

I identified some cases that doesn't follow this. Unclear whether they are intentional.

test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:

> 34:  * @build jdk.test.whitebox.WhiteBox
> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation

Why not `480` in this case?

test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:

> 38:  * @requires vm.cds
> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses

I was expecting `500 * 4 = 2000`, instead of `8000` here.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31:

> 29:  * @compile SuspendResume2.java
> 30:  * @run driver jdk.test.lib.FileInstaller . .
> 31:  * @run main/othervm/native/timeout=700

Why `700` instead of `480` in this file?

test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:

> 57: public class DGCDeadLock implements Runnable {
> 58:     final static public int HOLD_TARGET_TIME = 25000;
> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);

Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:

> 58:  * @comment skip running this test on 32 bit VM
> 59:  * @requires vm.bits == "64"
> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest

Why not `480`?

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:

> 32:  * @build com.foobar.Utils
> 33:  *        com.bar.*
> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest

Why not `480`?

test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:

> 47:  * @library /test/lib /test/jdk
> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription

Why not `480`?

test/jdk/tools/jpackage/share/InstallDirTest.java line 69:

> 67:  * @compile -Xlint:all -Werror InstallDirTest.java
> 68:  * @requires (jpackage.test.SQETest != null)
> 69:  * @run main/othervm/timeout=4000 -Xmx512m jdk.jpackage.test.Main

Why more than `4x` in this file?

test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:

> 36: class HangingRemoteAgent extends RemoteExecutionControl {
> 37: 
> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

why not `Utils.TIMEOUT_FACTOR`?

test/langtools/jdk/jshell/UITesting.java line 148:

> 146:     }
> 147: 
> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

Why not `Utils.TIMEOUT_FACTOR`?

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

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3144985957
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294077875
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294085201
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294089550
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294108202
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294110136
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294113670
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294116148
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294119800
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294128741
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294129243

From prr at openjdk.org  Fri Aug 22 17:20:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 17:20:57 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

I don't agree.
If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

I am also questioning whether such a time out was demonstrated for this test.
I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
I can send you my query off-line so you can check it. Maybe it is incomplete.

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

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

From ayang at openjdk.org  Fri Aug 22 18:45:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 18:45:53 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> or don't do it.

Adding `/timeout=480` is more or less don't do anything.

The default timeout (if omitting `/timeout=...`) is 120, so:

master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

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

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

From alanb at openjdk.org  Sun Aug 24 09:58:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 24 Aug 2025 09:58:52 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
 <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
Message-ID: <VveE9LwNHbACMKjKW97dxBek0d1JtVSmaLzxJ1d_gKg=.ebe2da86-b1c5-4ca5-890b-693ddbb1dac7@github.com>

On Fri, 22 Aug 2025 18:43:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
>> 
>> I don't agree.
>> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
>> 
>> I am also questioning whether such a time out was demonstrated for this test.
>> I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
>> I can send you my query off-line so you can check it. Maybe it is incomplete.
>
>> or don't do it.
> 
> Adding `/timeout=480` is more or less don't do anything.
> 
> The default timeout (if omitting `/timeout=...`) is 120, so:
> 
> master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
> patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

There are several comments in this PR pointing out again and again that adding "/timeout=480" doesn't change anything with the new proposed default timeout and timeoutFactor. I was initially puzzled as to why these were being added to a lot of tests but I think Leo's runs with a timeoutFactor of 0.7 explains it. If the timeoutFactor is reduced then we risk timeouts from tests that are run close to the limit today. The method used to find these tests seems reasonable. So I think the approach is good and we should try to help him get this change integrated to avoid needing to keep it up to date while tests change in main line.

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

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

From dholmes at openjdk.org  Sun Aug 24 22:54:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 24 Aug 2025 22:54:03 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>

On Fri, 22 Aug 2025 15:41:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
> 
>> 34:  * @build jdk.test.whitebox.WhiteBox
>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
> 
> Why not `480` in this case?

Leo also states in the description:

> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

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

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

From lkorinth at openjdk.org  Mon Aug 25 10:52:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:01 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
Message-ID: <AFdpOMl_1ooSkxayT06rLAB2YAqOdpOVArSwLFhr5RI=.9ad37969-d90c-44e8-8839-2efb60f9f0a0@github.com>

On Sun, 24 Aug 2025 22:51:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
>> 
>>> 34:  * @build jdk.test.whitebox.WhiteBox
>>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
>> 
>> Why not `480` in this case?
>
> Leo also states in the description:
> 
>> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

In a few places, I have got timeouts after adjusting the timeout value. This is most likely because I have used a timeout factor of 0.7 to minimise "flickering" behaviour before finally changing to a timeout factor of 1. One consequence of this is that a few test cases will have double the original timeout (those test that would not pass a reduction to 0.7). So in all the instances when the timeout factor is exactly two times the size, the reason is that I have realised that I have already adjusted the timeout and I do not want to quad it again.

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

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

From lkorinth at openjdk.org  Mon Aug 25 10:52:09 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:09 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <vSDcN6CwSbjugZPSWSankLFy31FA2rVoSuJidKO-yLQ=.e2955c07-efad-498c-9606-cb9ab46ed327@github.com>

On Fri, 22 Aug 2025 15:44:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:
> 
>> 38:  * @requires vm.cds
>> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
>> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses
> 
> I was expecting `500 * 4 = 2000`, instead of `8000` here.

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:
> 
>> 58:  * @comment skip running this test on 32 bit VM
>> 59:  * @requires vm.bits == "64"
>> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:
> 
>> 32:  * @build com.foobar.Utils
>> 33:  *        com.bar.*
>> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:
> 
>> 47:  * @library /test/lib /test/jdk
>> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
>> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297768577
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773391
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773648
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297774209

From lkorinth at openjdk.org  Mon Aug 25 11:04:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:04:00 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <nlwJNUKGatY6Irnw2NlsOMfSpPv_kE_dY8mY_cggDy8=.5136bc97-670f-4b23-bbf5-6277ddd7de3d@github.com>

On Fri, 22 Aug 2025 16:06:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:
> 
>> 36: class HangingRemoteAgent extends RemoteExecutionControl {
>> 37: 
>> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> why not `Utils.TIMEOUT_FACTOR`?

There are a few places where I have changed java files that are not jtreg tests themself. The code is used by a jtreg test, but is not the "entry" into a test. Those files have no way to specify `@library` annotations, as no "test annotations" are parsed. It is a pity that a jtreg "library" can not specify dependencies to other "libraries".

> test/langtools/jdk/jshell/UITesting.java line 148:
> 
>> 146:     }
>> 147: 
>> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> Why not `Utils.TIMEOUT_FACTOR`?

[see above](https://github.com/openjdk/jdk/pull/26749#discussion_r2297800775)

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

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

From lkorinth at openjdk.org  Mon Aug 25 11:19:53 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:19:53 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <cORbSIzlWv8wgHca57OZ7Mm1wGDOGrYFEoUvNKLjcU0=.00ee4953-8c94-4812-89a5-f710dbe570d1@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

I am awaiting Oracle internal feedback if you wonder why I have still not updated copyright and integrated.  Target date for integration is second of September.

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

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

From lkorinth at openjdk.org  Mon Aug 25 11:43:54 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:43:54 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>

On Fri, 22 Aug 2025 15:55:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:
> 
>> 57: public class DGCDeadLock implements Runnable {
>> 58:     final static public int HOLD_TARGET_TIME = 25000;
>> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);
> 
> Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4).

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

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

From ayang at openjdk.org  Mon Aug 25 13:50:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 25 Aug 2025 13:50:55 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
Message-ID: <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>

On Mon, 25 Aug 2025 11:40:56 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> while not multiplying a 10x factor with four resulting in a 40x factor.

Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000)  * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO.

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

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

From mdonovan at openjdk.org  Tue Aug 26 17:08:38 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 26 Aug 2025 17:08:38 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/sun/security/krb5/name/Constructors.java line 28:

> 26:  * @summary Make PrincipalName and Realm immutable
> 27:  * @modules java.security.jgss/sun.security.krb5
> 28:  * @run main/othervm Constructors

Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

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

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

From naoto at openjdk.org  Tue Aug 26 21:52:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Aug 2025 21:52:47 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: <1QGbXOxkv7tUEpnNo7lBaTa8yRJB8qEM9UwRgLHJK10=.41cac33e-cea2-427c-80b6-dc2a97d00c4f@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()`

Thanks for the reviews!

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

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

From naoto at openjdk.org  Tue Aug 26 21:52:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Aug 2025 21:52:48 GMT
Subject: <i18n dev> Integrated: 8363972: Lenient parsing of minus sign
 pattern in DecimalFormat/CompactNumberFormat
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <bTtrPIB80mtgW66IG-mKEoLYZ4YPW2s2VTnwJ0iCgQ8=.af90d90f-6ac0-4936-8601-c3e0684ca729@github.com>

On Thu, 31 Jul 2025 18:41:47 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.

This pull request has now been integrated.

Changeset: 23670fd4
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23670fd41895ccc38931f836d218ff7392a6065a
Stats:     426 lines in 8 files changed: 388 ins; 20 del; 18 mod

8363972: Lenient parsing of minus sign pattern in DecimalFormat/CompactNumberFormat

Reviewed-by: jlu, rriggs

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

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

From naoto at openjdk.org  Tue Aug 26 21:54:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Aug 2025 21:54:45 GMT
Subject: <i18n dev> RFR: 8364752: java.time.Instant should be able to
 parse ISO 8601 offsets of the form HH:mm:ss [v7]
In-Reply-To: <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@github.com>
References: <ADam5FcvRsAjTSmB__4OI_pFUv7yl0LJcQmfMYmNYEo=.d2053525-3342-4d4a-a047-e93d7faa5a73@github.com>
 <7C6nMpOBczEFuUsCqtJjz1V_5ylyvL9-3PLcXjolg0g=.26469091-6b8a-43b1-a81a-b525691c1d55@github.com>
Message-ID: <f7Gi1xDSEhl4K6zZkSuvZ71Ynwde5K87o5YGDKf4_e0=.36b02eb2-5083-45be-8447-756f04981d9a@github.com>

On Mon, 18 Aug 2025 19:19:08 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - DateTimeFormatterBuilder wording
>  - Added non-zero offset test cases
>  - Merge branch 'master' into JDK-8364752-Instant-ISO8601
>  - Update src/java.base/share/classes/java/time/format/DateTimeFormatter.java
>    
>    Right. Changing to your suggested wording
>    
>    Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
>  - copyright year update
>  - test cases
>  - allow all ISO 8601 offsets
>  - allow hour-only offsets
>  - initial commit

Thanks for the reviews!

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

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

From naoto at openjdk.org  Tue Aug 26 21:54:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Aug 2025 21:54:46 GMT
Subject: <i18n dev> Integrated: 8364752: java.time.Instant should be able to
 parse ISO 8601 offsets of the form HH:mm:ss
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: <EqVQKfJKeejJb478avtGitf4QPt5hQRTSRlc34PQrBg=.388a07a6-44e4-4bd9-9e2d-a0ed5926ec06@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.

This pull request has now been integrated.

Changeset: 1ff73cb2
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ff73cb2ec41612d316921e852f29e7fa4dc9109
Stats:     71 lines in 3 files changed: 62 ins; 0 del; 9 mod

8364752: java.time.Instant should be able to parse ISO 8601 offsets of the form HH:mm:ss

Reviewed-by: rriggs, vyazici, scolebourne

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

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

From lkorinth at openjdk.org  Thu Aug 28 13:05:51 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:05:51 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <EJdxiot32oUpUVtRSTMTXFSFI9pOkmb17vwLGEKmuK0=.a14f9df8-b05a-4a59-a5c0-039070d059ff@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> > @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
> 
> I don't agree. If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
> 
> I am also questioning whether such a time out was demonstrated for this test. I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test. I can send you my query off-line so you can check it. Maybe it is incomplete.

I will revert this change. Thanks for finding it. I think the timeout was found in a local run with a timeout factor of 0.5 and a local fix to "CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE". CI history tells me that the run time of the test is stable and that we have a margin.

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

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

From lkorinth at openjdk.org  Thu Aug 28 13:12:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:45 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v6]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <mygrl66-jtLOCitZE1y7w005QUUFmtZ0QDWPO5FD8pQ=.9558b892-2b3a-4c1e-b898-51b86d61beb0@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 two additional commits since the last revision:

 - revert added timeout, it is not needed
 - feedback from Mark Sheppard

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/f24a1e72..365454d2

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

  Stats: 62 lines in 41 files changed: 3 ins; 0 del; 59 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  Thu Aug 28 13:12:46 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:46 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <O2hQ5ow7drkJOD-QiVkoDFa9ChZmv3WEOTqLgH3r8lQ=.b12f1c30-cfe8-4797-a964-67429193f9d9@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

I have added some updates. I will try to merge latest, update copyrights and run tests over the weekend.

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

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

From jlu at openjdk.org  Thu Aug 28 20:28:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Aug 2025 20:28:52 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor elements
 with link tag
Message-ID: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>

This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.

This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/26996/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365175
  Stats: 36 lines in 12 files changed: 0 ins; 0 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/26996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26996/head:pull/26996

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

From iris at openjdk.org  Thu Aug 28 20:56:40 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 28 Aug 2025 20:56:40 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag
In-Reply-To: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
Message-ID: <rum405M8w6Cdj7Q1WunBQL4IecQCC30ppdv0Eq9TAc4=.691659af-8a38-499b-9485-1dadd5caf5a4@github.com>

On Thu, 28 Aug 2025 20:23:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.
> 
> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26996#pullrequestreview-3166480191

From naoto at openjdk.org  Thu Aug 28 21:47:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 28 Aug 2025 21:47:43 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag
In-Reply-To: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
Message-ID: <xQV7aCwu3Kqo0XcDk_px-OQWSug52-TYQktPfZLwQDE=.62cbb2c0-df0c-4684-8241-f89f4be36a3f@github.com>

On Thu, 28 Aug 2025 20:23:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.
> 
> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.

Thanks for the cleanup!

src/java.base/share/classes/java/util/Calendar.java line 1650:

> 1648:      * <p>
> 1649:      * If the locale contains the time zone with "tz"
> 1650:      * {@link Locale##def_locale_extensionUnicode extension},

Needs a space

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

PR Review: https://git.openjdk.org/jdk/pull/26996#pullrequestreview-3166629812
PR Review Comment: https://git.openjdk.org/jdk/pull/26996#discussion_r2308617433

From jlu at openjdk.org  Thu Aug 28 22:10:19 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Aug 2025 22:10:19 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag [v2]
In-Reply-To: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
Message-ID: <L1TDMk38klY30tqFkCCoIsBiFHpyDX97WK0nl2uUnDM=.a69908a9-b9ac-4fcf-9466-fdbbe494383a@github.com>

> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.
> 
> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.

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

  Missing space in Calendar update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26996/files
  - new: https://git.openjdk.org/jdk/pull/26996/files/a9208477..5ce79b86

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

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

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

From naoto at openjdk.org  Thu Aug 28 22:39:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 28 Aug 2025 22:39:42 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag [v2]
In-Reply-To: <L1TDMk38klY30tqFkCCoIsBiFHpyDX97WK0nl2uUnDM=.a69908a9-b9ac-4fcf-9466-fdbbe494383a@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
 <L1TDMk38klY30tqFkCCoIsBiFHpyDX97WK0nl2uUnDM=.a69908a9-b9ac-4fcf-9466-fdbbe494383a@github.com>
Message-ID: <9RESq-fs9vLcnElByN6C2vaEYrUjXUGqY_Mw1Lt4L9U=.75d33af2-e7c6-403f-a91c-dea0614d55e5@github.com>

On Thu, 28 Aug 2025 22:10:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.
>> 
>> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing space in Calendar update

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26996#pullrequestreview-3166750759

From liach at openjdk.org  Thu Aug 28 23:23:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Aug 2025 23:23:42 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag [v2]
In-Reply-To: <L1TDMk38klY30tqFkCCoIsBiFHpyDX97WK0nl2uUnDM=.a69908a9-b9ac-4fcf-9466-fdbbe494383a@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
 <L1TDMk38klY30tqFkCCoIsBiFHpyDX97WK0nl2uUnDM=.a69908a9-b9ac-4fcf-9466-fdbbe494383a@github.com>
Message-ID: <db7XFjzDlOFLdBQeMwk7YxY3uJxE2oQYrqNhU3o_fIE=.0ea5752a-6dcd-4479-9fe6-63c6e08d5865@github.com>

On Thu, 28 Aug 2025 22:10:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.
>> 
>> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing space in Calendar update

src/java.base/share/classes/java/text/DateFormat.java line 104:

> 102:  *
> 103:  * <p>If the specified locale contains "ca" (calendar), "rg" (region override),
> 104:  * and/or "tz" (timezone) {@link Locale##def_locale_extension Unicode

`{@link}` renders in code font. Is that intended? You can use `{@linkplain}` for plain font.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26996#discussion_r2308763278

From lkorinth at openjdk.org  Fri Aug 29 14:41:48 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 14:41:48 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v6]
In-Reply-To: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
Message-ID: <U44eId1pfiGjDkIlPM5vo-4Y_Oq-QdjIdCTFbD5O94E=.0f31a90c-9106-4cf5-a50f-4e7551eb14ff@github.com>

On Tue, 26 Aug 2025 17:06:08 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert added timeout, it is not needed
>>  - feedback from Mark Sheppard
>
> test/jdk/sun/security/krb5/name/Constructors.java line 28:
> 
>> 26:  * @summary Make PrincipalName and Realm immutable
>> 27:  * @modules java.security.jgss/sun.security.krb5
>> 28:  * @run main/othervm Constructors
> 
> Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

I have not analysed why. I can see 1013 occurrences in our test history where the test takes 2 minutes or more. On different CPU platforms.

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

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

From jlu at openjdk.org  Fri Aug 29 18:06:18 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Aug 2025 18:06:18 GMT
Subject: <i18n dev> RFR: 8366401: JCK test
 api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after
 JDK-8363972
Message-ID: <zAaz3nEwujeGkbjEvHEBVfHiU7cjDolZjgANFvWLXqM=.5618c4c2-791f-4faa-a55e-d1002292cad1@github.com>

This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`.

Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`.

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

Commit messages:
 - init

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

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

From lkorinth at openjdk.org  Fri Aug 29 18:45:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 18:45:45 GMT
Subject: <i18n dev> RFR: 8260555: Change the default TIMEOUT_FACTOR from
 4 to 1 [v7]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <2IfOGWu0Kfw8qdRmYLkMEdF5kvlC5lcuc-USAovOTFM=.f6d2a6c9-160d-478e-aa5c-1086b40e52bd@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:

  update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/365454d2..4b33904a

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

  Stats: 233 lines in 233 files changed: 0 ins; 0 del; 233 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 naoto at openjdk.org  Fri Aug 29 19:50:41 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 29 Aug 2025 19:50:41 GMT
Subject: <i18n dev> RFR: 8366401: JCK test
 api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after
 JDK-8363972
In-Reply-To: <zAaz3nEwujeGkbjEvHEBVfHiU7cjDolZjgANFvWLXqM=.5618c4c2-791f-4faa-a55e-d1002292cad1@github.com>
References: <zAaz3nEwujeGkbjEvHEBVfHiU7cjDolZjgANFvWLXqM=.5618c4c2-791f-4faa-a55e-d1002292cad1@github.com>
Message-ID: <5_MSPIBvf1Umkk2FJdq5FvUKmnSjXtQ51xNOj--QZiQ=.9ba3c1b7-9108-43b8-8b7c-bfdf8b962cd3@github.com>

On Fri, 29 Aug 2025 18:00:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`.
> 
> Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`.

Since this is avoiding non-standard situations either solutions should be acceptable.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27008#pullrequestreview-3169931280

From duke at openjdk.org  Fri Aug 29 20:17:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 29 Aug 2025 20:17:54 GMT
Subject: <i18n dev> RFR: 8361593: Commented dead code in JDK-8342868 can be
 removed
Message-ID: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>

[JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

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

Commit messages:
 - remove commented code

Changes: https://git.openjdk.org/jdk/pull/27012/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361593
  Stats: 16 lines in 3 files changed: 0 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27012.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27012/head:pull/27012

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

From jlu at openjdk.org  Fri Aug 29 20:44:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Aug 2025 20:44:00 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag [v3]
In-Reply-To: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
Message-ID: <0t5YDtu6ylWIPC8qsRpR49hwn6xGWRub8ebABKKD5DY=.42d97385-3974-4eb8-93da-da7ec64c274f@github.com>

> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.
> 
> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.

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

  link -> linkplain

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26996/files
  - new: https://git.openjdk.org/jdk/pull/26996/files/5ce79b86..cc0c2594

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

  Stats: 21 lines in 12 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/26996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26996/head:pull/26996

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

From jlu at openjdk.org  Fri Aug 29 20:44:01 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Aug 2025 20:44:01 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag [v2]
In-Reply-To: <db7XFjzDlOFLdBQeMwk7YxY3uJxE2oQYrqNhU3o_fIE=.0ea5752a-6dcd-4479-9fe6-63c6e08d5865@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
 <L1TDMk38klY30tqFkCCoIsBiFHpyDX97WK0nl2uUnDM=.a69908a9-b9ac-4fcf-9466-fdbbe494383a@github.com>
 <db7XFjzDlOFLdBQeMwk7YxY3uJxE2oQYrqNhU3o_fIE=.0ea5752a-6dcd-4479-9fe6-63c6e08d5865@github.com>
Message-ID: <xiPSlpbvW3NAiGkR3ZsZX6ySTLjBUGTBQLYLHLXXTYg=.24be186d-5924-4d73-88bc-57664a46c672@github.com>

On Thu, 28 Aug 2025 23:20:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing space in Calendar update
>
> src/java.base/share/classes/java/text/DateFormat.java line 104:
> 
>> 102:  *
>> 103:  * <p>If the specified locale contains "ca" (calendar), "rg" (region override),
>> 104:  * and/or "tz" (timezone) {@link Locale##def_locale_extension Unicode
> 
> `{@link}` renders in code font. Is that intended? You can use `{@linkplain}` for plain font.

You are right, these would be better as `linkplain` tags. Updated as such.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26996#discussion_r2311189574

From jlu at openjdk.org  Fri Aug 29 23:04:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Aug 2025 23:04:42 GMT
Subject: <i18n dev> RFR: 8361593: Commented dead code in JDK-8342868 can
 be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <jvI1IldKMvGXzyCUyvDDynclH_fIqHbvYkqzLMqTtEY=.5697eb3f-c5c5-4bb7-b205-e61e93b61cd5@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

Removals are consistent with the ones commented out in https://github.com/openjdk/jdk/pull/21654.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170642702

From naoto at openjdk.org  Fri Aug 29 23:27:41 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 29 Aug 2025 23:27:41 GMT
Subject: <i18n dev> RFR: 8361593: Commented dead code in JDK-8342868 can
 be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <005TU_LUKpe4hFdKdMHebTg1Tn8GfWbngdLpg8tKvUE=.d068c2e4-4462-4ed5-834b-4285dd4bb910@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170703060

From duke at openjdk.org  Fri Aug 29 23:27:41 2025
From: duke at openjdk.org (duke)
Date: Fri, 29 Aug 2025 23:27:41 GMT
Subject: <i18n dev> RFR: 8361593: Commented dead code in JDK-8342868 can
 be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <59nQMxcp2BQVztc0_1WAn9_IlMUN5a01p4Efr90kz3E=.7909e05c-a7cc-4b24-ba4f-7b25a475654c@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

@fandreuz 
Your change (at version 09067914f31bdabe29d2c9d4187eec6246a3cae4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27012#issuecomment-3238691498

From jlu at openjdk.org  Sat Aug 30 00:06:18 2025
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 30 Aug 2025 00:06:18 GMT
Subject: <i18n dev> RFR: 8366400: JCK test
 api/java_text/DecimalFormat/Parse.html fails after JDK-8363972
Message-ID: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com>

This PR addresses a JCK test failure of an unexpected SIOOBE during DecimalFormat parsing. During the char by char comparison in `matchAffix`, the minimum of the length of the parsed String and the PP index + affix length are iterated on. The parse position index needs to be checked to not be negative to ensure that we do not index the String below 0. Taking the minimum of those two previously mentioned values already guarantees that we do not index the String above the length.

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

Commit messages:
 - Add reg test
 - init

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

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

From alanb at openjdk.org  Sat Aug 30 06:44:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Aug 2025 06:44:44 GMT
Subject: <i18n dev> RFR: 8366401: JCK test
 api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after
 JDK-8363972
In-Reply-To: <zAaz3nEwujeGkbjEvHEBVfHiU7cjDolZjgANFvWLXqM=.5618c4c2-791f-4faa-a55e-d1002292cad1@github.com>
References: <zAaz3nEwujeGkbjEvHEBVfHiU7cjDolZjgANFvWLXqM=.5618c4c2-791f-4faa-a55e-d1002292cad1@github.com>
Message-ID: <qLxV_otdOJ6J1Z57uPGp8ABjklD_DGwzZq9Ja__6lZg=.182e2acd-0888-457a-8603-9db96476b5b4@github.com>

On Fri, 29 Aug 2025 18:00:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`.
> 
> Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`.

Have you considered adding a unit or regression test to exercise DecimalFormatSymbols serialization? I assume this issue slipped through and was caught else because the jdk repo doesn't have any tests for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/27008#issuecomment-3239003577

From alanb at openjdk.org  Sat Aug 30 06:49:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Aug 2025 06:49:40 GMT
Subject: <i18n dev> RFR: 8366400: JCK test
 api/java_text/DecimalFormat/Parse.html fails after JDK-8363972
In-Reply-To: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com>
References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com>
Message-ID: <apfO1U-LhNrG2LALdTHS9hPF85U9PNmGK-N_RDVRlcE=.afe41024-6d91-4a36-83ef-013b29ddacb4@github.com>

On Fri, 29 Aug 2025 23:59:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses a JCK test failure of an unexpected SIOOBE during DecimalFormat parsing. During the char by char comparison in `matchAffix`, the minimum of the length of the parsed String and the PP index + affix length are iterated on. The parse position index needs to be checked to not be negative to ensure that we do not index the String below 0. Taking the minimum of those two previously mentioned values already guarantees that we do not index the String above the length.

Would it be possible to review the DecimalFormat tests in the jdk repo? I'm wondering if the changes for lenient parsing in JDK-8363972 should have had more tests (it's good that tests elsewhere found the issue but it does suggest that we don't have enough tests in the jdk repo).

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

PR Comment: https://git.openjdk.org/jdk/pull/27014#issuecomment-3239007000

From jwaters at openjdk.org  Sat Aug 30 06:53:41 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 30 Aug 2025 06:53:41 GMT
Subject: <i18n dev> RFR: 8361593: Commented dead code in JDK-8342868 can
 be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <Hf0bUlANe4m4vwq1TaQKBUk3pHysIHbkpb67Xpr6-Es=.e1af0982-049b-4f96-b217-8e2c900feae7@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

Test failure is because JDK source failed to check out rather than anything related to this change

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170915193

From jpai at openjdk.org  Sat Aug 30 09:57:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 30 Aug 2025 09:57:45 GMT
Subject: <i18n dev> RFR: 8361593: Commented dead code in JDK-8342868 can
 be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <g8cKUd20NXdcGW5oisM55cxZswHpWAOrPnAvzyS2f2w=.15457053-c4a8-42bb-933c-6c238bcf508f@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170992535

From liach at openjdk.org  Sat Aug 30 15:46:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 30 Aug 2025 15:46:43 GMT
Subject: <i18n dev> RFR: 8365175: Replace Unicode extension anchor
 elements with link tag [v3]
In-Reply-To: <0t5YDtu6ylWIPC8qsRpR49hwn6xGWRub8ebABKKD5DY=.42d97385-3974-4eb8-93da-da7ec64c274f@github.com>
References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com>
 <0t5YDtu6ylWIPC8qsRpR49hwn6xGWRub8ebABKKD5DY=.42d97385-3974-4eb8-93da-da7ec64c274f@github.com>
Message-ID: <squzv7ffV3Poksdz43xHfo0rldP1hUNqw0hwsF4Hxa8=.c4461dd2-fc4e-43f1-a56d-d8591967d042@github.com>

On Fri, 29 Aug 2025 20:44:00 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683.
>> 
>> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link -> linkplain

Marked as reviewed by liach (Reviewer).

src/java.base/share/classes/java/util/Calendar.java line 2670:

> 2668:      *         {@code Calendar} instance
> 2669:      * @since 1.8
> 2670:      * @see Locale##def_locale_extension Locale extensions

This will be handled as plain text because of space in "Locale extensions" ?

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

PR Review: https://git.openjdk.org/jdk/pull/26996#pullrequestreview-3171094927
PR Review Comment: https://git.openjdk.org/jdk/pull/26996#discussion_r2311994680

From duke at openjdk.org  Sun Aug 31 00:37:49 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Sun, 31 Aug 2025 00:37:49 GMT
Subject: <i18n dev> Integrated: 8361593: Commented dead code in JDK-8342868
 can be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <hitHEJaihgTNtVVo8bs47iMtcQriMZmd-ODRi5D6E-w=.381b4606-0b50-4dd7-9c1f-277e313a689b@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

This pull request has now been integrated.

Changeset: 9339a6a2
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9339a6a23236e783e93f967cf6aba16c2f749fdd
Stats:     16 lines in 3 files changed: 0 ins; 11 del; 5 mod

8361593: Commented dead code in JDK-8342868 can be removed

Reviewed-by: jlu, naoto, jwaters, jpai

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

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