From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@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 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 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 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 Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > 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: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References:

Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth 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: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References:

Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang 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/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? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References:

Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> 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). > >> 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. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth 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... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From duke at openjdk.org Tue Sep 2 09:27:52 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 09:27:52 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected Message-ID: Problem Statements: 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. 2. ZoneID was not displaying in the window as it is displaying in the lower releases. Test Results: jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java Passed: java/util/TimeZone/DefaultTimeZoneTest.java Test results: passed: 1 ------------- Commit messages: - 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected Changes: https://git.openjdk.org/jdk/pull/27043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366537 Stats: 30 lines in 1 file changed: 26 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From duke at openjdk.org Tue Sep 2 10:50:33 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 10:50:33 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v2] In-Reply-To: References: Message-ID: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: modified tzid variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/303709d8..7a2a87d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From myankelevich at openjdk.org Tue Sep 2 14:38:44 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 2 Sep 2025 14:38:44 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v2] In-Reply-To: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> References: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> Message-ID: On Tue, 2 Sep 2025 10:50:33 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > modified tzid variable test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 111: > 109: panel.setLayout(new BoxLayout(panel, BoxLayout.PAGE_AXIS)); > 110: // Time zone ID label > 111: var tzid = new JLabel("Time zone ID: " + SDF.getTimeZone().getID(), SwingConstants.CENTER); minor: do you think changing it to a more intuitive `timeZoneID` would make it easier to read? If you want to leave it as is - I don't mind ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27043#discussion_r2316292304 From duke at openjdk.org Tue Sep 2 15:50:59 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 15:50:59 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v2] In-Reply-To: References: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> Message-ID: On Tue, 2 Sep 2025 14:35:47 GMT, Mikhail Yankelevich wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> modified tzid variable > > test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 111: > >> 109: panel.setLayout(new BoxLayout(panel, BoxLayout.PAGE_AXIS)); >> 110: // Time zone ID label >> 111: var tzid = new JLabel("Time zone ID: " + SDF.getTimeZone().getID(), SwingConstants.CENTER); > > minor: do you think changing it to a more intuitive `timeZoneID` would make it easier to read? If you want to leave it as is - I don't mind Done, changed to timeZoneID. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27043#discussion_r2316501052 From duke at openjdk.org Tue Sep 2 15:50:58 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 15:50:58 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References: Message-ID: > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: changed tzid to more readable timeZoneID ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/7a2a87d3..1d553994 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From naoto at openjdk.org Tue Sep 2 16:10:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 16:10:44 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 18:00:25 GMT, Justin Lu 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`. There are some tests for serializing DecimalFormatSymbols, but I agree that it would be desirable to revisit and cover missing cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27008#issuecomment-3245960204 From naoto at openjdk.org Tue Sep 2 17:04:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 17:04:46 GMT Subject: 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: <7Dkg3RT7FqyGD32gIbhB5uu-SvTy02SXCPah2dVLbaA=.8dc7a5e2-5f8d-4937-89af-f287bc5e7ddd@github.com> On Fri, 29 Aug 2025 23:59:54 GMT, Justin Lu 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. test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 172: > 170: assertNull(assertDoesNotThrow(() -> new DecimalFormat().parse("1", new ParsePosition(-1)))); > 171: } > 172: Thanks for writing the invalid case test. As Alan suggested, maybe we could provide more edge case tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27014#discussion_r2316676697 From naoto at openjdk.org Tue Sep 2 18:50:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 18:50:45 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References:

Message-ID: <5I7FdKVr3PH_8Fkwh87wAizc_efngMwxbv0YBsEIKec=.9c0e0b28-54d9-426c-9b7e-a138d6e2c935@github.com> On Tue, 2 Sep 2025 15:50:58 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > changed tzid to more readable timeZoneID LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27043#pullrequestreview-3177729678 From jlu at openjdk.org Tue Sep 2 18:55:23 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 18:55:23 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References: Message-ID: > 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`. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Nested class rename - Add JDK regression test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27008/files - new: https://git.openjdk.org/jdk/pull/27008/files/0ace8f6a..751d00be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=00-01 Stats: 262 lines in 1 file changed: 262 ins; 0 del; 0 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 jlu at openjdk.org Tue Sep 2 18:55:24 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 18:55:24 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 In-Reply-To: References:

Message-ID: On Sat, 30 Aug 2025 06:41:53 GMT, Alan Bateman 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 where because the jdk repo doesn't have any tests for this. @AlanBateman @naotoj Initially I relied on the JCK test since this was a non-standard situation. But you are right that we should not have to rely on the JCK tests to discover an issue in the JDK, I've removed the `noreg-jck` label and added a serialization test. It checks all of the correct behavior based on the stream version, as well as other invariants. I also filed [JDK-8366733](https://bugs.openjdk.org/browse/JDK-8366733) because many of the existing serialization tests for DFS seem to be relics and can either be removed or are redundant with the newly added test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27008#issuecomment-3246431509 From naoto at openjdk.org Tue Sep 2 19:35:57 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 19:35:57 GMT Subject: RFR: 8366517: DateFormatSymbols(Locale) throws NPE if Locale argument is null Message-ID: Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27060/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366517 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27060/head:pull/27060 PR: https://git.openjdk.org/jdk/pull/27060 From naoto at openjdk.org Tue Sep 2 20:27:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 20:27:41 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Sep 2025 18:55:23 GMT, Justin Lu 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`. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Nested class rename > - Add JDK regression test Thanks for providing new tests. test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 140: > 138: } > 139: > 140: // Previous versions of DFS could contain a null locale "Previous" suggests it would not allow null with this change, which is not the case. test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 224: > 222: ObjectInputStream ois = new ObjectInputStream(byteArrayInputStream)) { > 223: return (DecimalFormatSymbols) ois.readObject(); > 224: } I guess if an error occured in this try block, the test should fail. Just wondering the reason it did not use `assertDoesNotThrow()` method. ------------- PR Review: https://git.openjdk.org/jdk/pull/27008#pullrequestreview-3177975352 PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317077376 PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317062931 From jlu at openjdk.org Tue Sep 2 20:38:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 20:38:42 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Sep 2025 20:22:50 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Nested class rename >> - Add JDK regression test > > test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 140: > >> 138: } >> 139: >> 140: // Previous versions of DFS could contain a null locale > > "Previous" suggests it would not allow null with this change, which is not the case. Instances created from the current standard _public_ API **do not allow** a null locale, hence the clarification that previous versions **can contain** a null locale. i.e. We do not expect to see null locales with up-to-date versions of DFS that are not tampered with, so I think the comment is accurate. > test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 224: > >> 222: ObjectInputStream ois = new ObjectInputStream(byteArrayInputStream)) { >> 223: return (DecimalFormatSymbols) ois.readObject(); >> 224: } > > I guess if an error occured in this try block, the test should fail. Just wondering the reason it did not use `assertDoesNotThrow()` method. I did not swallow the error with `assertDoesNotThrow()` here becasue `disagreeingTextTest` expects to see an `InvalidObjectException.class`. Future tests/changes can easily check for expected de-serialization failures with this setup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317106675 PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317106647 From jlu at openjdk.org Tue Sep 2 20:46:46 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 20:46:46 GMT Subject: 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: On Fri, 29 Aug 2025 20:44:00 GMT, Justin Lu 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 Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26996#issuecomment-3246731929 From jlu at openjdk.org Tue Sep 2 20:46:47 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 20:46:47 GMT Subject: Integrated: 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: On Thu, 28 Aug 2025 20:23:32 GMT, Justin Lu 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. This pull request has now been integrated. Changeset: 80fb7088 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/80fb7088a10136080d23ea93b4840f17d738500c Stats: 36 lines in 12 files changed: 0 ins; 0 del; 36 mod 8365175: Replace Unicode extension anchor elements with link tag Reviewed-by: liach, iris, naoto ------------- PR: https://git.openjdk.org/jdk/pull/26996 From naoto at openjdk.org Tue Sep 2 20:54:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 20:54:41 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References:

Message-ID: On Tue, 2 Sep 2025 20:35:50 GMT, Justin Lu wrote: >> test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 140: >> >>> 138: } >>> 139: >>> 140: // Previous versions of DFS could contain a null locale >> >> "Previous" suggests it would not allow null with this change, which is not the case. > > Instances created from the current standard _public_ API **do not allow** a null locale, hence the clarification that previous versions **can contain** a null locale. > > i.e. We do not expect to see null locales with up-to-date versions of DFS that are not tampered with, so I think the comment is accurate. I guess I mistook "previous" as previous implementation of DFS, but your comment refers to previous "stream" versions. Probably clarify it may help here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317147454 From jlu at openjdk.org Tue Sep 2 21:02:46 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 21:02:46 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v3] In-Reply-To: References: Message-ID: <06XwUOKKgaicVdJcVCaOpuWBNE56acEtKeEYNNj2Y64=.e7328343-b82e-402c-b20e-e5525da7ef78@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`. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Clarify the null locale comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27008/files - new: https://git.openjdk.org/jdk/pull/27008/files/751d00be..445bbe85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 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 jlu at openjdk.org Tue Sep 2 21:14:43 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 21:14:43 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References:

Message-ID: On Tue, 2 Sep 2025 15:50:58 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > changed tzid to more readable timeZoneID Thanks for the change. I ran the manual test and can confirm that the zone ID now updates in the window when the platform tz is changed. Nit: Copyright year can be updated. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/27043#pullrequestreview-3178145140 From jlu at openjdk.org Tue Sep 2 21:21:04 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 21:21:04 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v4] In-Reply-To: References: Message-ID: > 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`. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: public API is too broad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27008/files - new: https://git.openjdk.org/jdk/pull/27008/files/445bbe85..dfb818c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 jlu at openjdk.org Tue Sep 2 22:15:29 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 22:15:29 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2] In-Reply-To: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> Message-ID: > 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. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Missing the bug ID in the new test - Adding additional tests and moving tests to PositionTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27014/files - new: https://git.openjdk.org/jdk/pull/27014/files/79b57021..96f71a0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27014&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27014&range=00-01 Stats: 75 lines in 2 files changed: 56 ins; 14 del; 5 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 jlu at openjdk.org Tue Sep 2 22:15:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 22:15:30 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2] In-Reply-To: <7Dkg3RT7FqyGD32gIbhB5uu-SvTy02SXCPah2dVLbaA=.8dc7a5e2-5f8d-4937-89af-f287bc5e7ddd@github.com> References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> <7Dkg3RT7FqyGD32gIbhB5uu-SvTy02SXCPah2dVLbaA=.8dc7a5e2-5f8d-4937-89af-f287bc5e7ddd@github.com> Message-ID: On Tue, 2 Sep 2025 17:01:58 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Missing the bug ID in the new test >> - Adding additional tests and moving tests to PositionTest > > test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 172: > >> 170: assertNull(assertDoesNotThrow(() -> new DecimalFormat().parse("1", new ParsePosition(-1)))); >> 171: } >> 172: > > Thanks for writing the invalid case test. As Alan suggested, maybe we could provide more edge case tests. Added some additional tests with a focus on affix matching, specifically ensuring SIOOBE does not leak out in any of those cases. i.e. The bounds checks should ensure `false` is returned for those cases. But specifically for the failing JCK test, the main test we need on the JDK repo side is a negative ParsePosition index test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27014#discussion_r2317281582 From naoto at openjdk.org Tue Sep 2 22:29:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 22:29:41 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v4] In-Reply-To: References:

Message-ID: On Tue, 2 Sep 2025 21:21:04 GMT, Justin Lu 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`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > public API is too broad LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27008#pullrequestreview-3178334115 From naoto at openjdk.org Tue Sep 2 22:58:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 22:58:46 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2] In-Reply-To: References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> Message-ID: On Tue, 2 Sep 2025 22:15:29 GMT, Justin Lu 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. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Missing the bug ID in the new test > - Adding additional tests and moving tests to PositionTest LGTM. Moving position tests unrelated to lenient minus parsing to here is good. test/jdk/java/text/Format/NumberFormat/PositionTest.java line 60: > 58: // begins at the valid portion. Ensure PP is properly updated. > 59: @Test > 60: public void modifiedPositionTest() { JUnit5 tests default to package-private visibility, but I think aligning with other tests is more important. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27014#pullrequestreview-3178377182 PR Review Comment: https://git.openjdk.org/jdk/pull/27014#discussion_r2317343019 From jlu at openjdk.org Tue Sep 2 23:10:41 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 23:10:41 GMT Subject: RFR: 8366517: DateFormatSymbols(Locale) throws NPE if Locale argument is null In-Reply-To: References: Message-ID: <8O740YRFXmkIrb1Hgu_qQUnYRSHYv0SWqXACpWWSOEc=.31959706-e26a-41fd-8a60-a99742e32e24@github.com> On Tue, 2 Sep 2025 19:29:37 GMT, Naoto Sato wrote: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. Looks good to me and the static factory methods already specify the NPE. fyi: PR title is missing the ` around code portions. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/27060#pullrequestreview-3178410659 From rriggs at openjdk.org Wed Sep 3 01:00:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 01:00:59 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 19:29:37 GMT, Naoto Sato wrote: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. src/java.base/share/classes/java/text/DateFormatSymbols.java line 148: > 146: * if the resources for the specified locale cannot be > 147: * found or cannot be loaded. > 148: * @throws NullPointerException if {@code locale} is null Adding an explicit Objects.requireNull(locale, "locale") would clearly identify when the NPE is thrown. Though it might be earlier than without the check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2317509928 From duke at openjdk.org Wed Sep 3 05:24:02 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 05:24:02 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v4] In-Reply-To: References: Message-ID: <3ZZxxJN7so5fHtNVcmAktY-suviU-OrNfZejnuPBFRw=.7102d369-ab3d-46ec-a7d0-ef5ca4199d20@github.com> > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Copyright year changed to 2025 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/1d553994..676cd48a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From duke at openjdk.org Wed Sep 3 06:13:17 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 06:13:17 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v5] In-Reply-To: References: Message-ID: > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Vanitha B P ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/676cd48a..c096a930 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=03-04 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From duke at openjdk.org Wed Sep 3 09:33:43 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 09:33:43 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References:

Message-ID: <-9xZMei8RG9SNQZppoVG6F9_SYh0awM4Y5gbAtVdtKo=.8046cba6-2c2a-4194-8747-fe4a852c32b9@github.com> On Tue, 2 Sep 2025 21:12:01 GMT, Justin Lu wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> changed tzid to more readable timeZoneID > > Thanks for the change. I ran the manual test and can confirm that the zone ID now updates in the window when the platform tz is changed. > Nit: Copyright year can be updated. @justin-curtis-lu I have updated the Copyright year, please review and approve. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27043#issuecomment-3248460755 From alanb at openjdk.org Wed Sep 3 11:36:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Sep 2025 11:36:46 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v4] In-Reply-To: References:

Message-ID: <4mXSGoIkRXmbPtv38taBT4ZT89b46s3IxAq8aAQAJVQ=.b271401a-e04b-4720-9023-dabf2baa2a83@github.com> On Wed, 3 Sep 2025 06:13:17 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Vanitha B P Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27043#pullrequestreview-3181181899 From naoto at openjdk.org Wed Sep 3 15:24:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 15:24:46 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v2] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 00:57:39 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Objects.requireNonNull() > > src/java.base/share/classes/java/text/DateFormatSymbols.java line 148: > >> 146: * if the resources for the specified locale cannot be >> 147: * found or cannot be loaded. >> 148: * @throws NullPointerException if {@code locale} is null > > Adding an explicit Objects.requireNull(locale, "locale") would clearly identify when the NPE is thrown. > Though it might be earlier than without the check. Right. Added the explicit null check. (and a test case) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2319328408 From duke at openjdk.org Wed Sep 3 15:33:48 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 15:33:48 GMT Subject: Integrated: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 09:22:16 GMT, Vanitha B P wrote: > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 This pull request has now been integrated. Changeset: a40afdd0 Author: Vanitha B P Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/a40afdd08f366afcefb1ac9d5fb184c8e803707e Stats: 30 lines in 1 file changed: 25 ins; 1 del; 4 mod 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected Reviewed-by: naoto, jlu ------------- PR: https://git.openjdk.org/jdk/pull/27043 From jlu at openjdk.org Wed Sep 3 16:03:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 16:03:42 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v2] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 15:22:11 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/DateFormatSymbols.java line 148: >> >>> 146: * if the resources for the specified locale cannot be >>> 147: * found or cannot be loaded. >>> 148: * @throws NullPointerException if {@code locale} is null >> >> Adding an explicit Objects.requireNull(locale, "locale") would clearly identify when the NPE is thrown. >> Though it might be earlier than without the check. > > Right. Added the explicit null check. (and a test case) If we are adding an explicit check to the ctor, might we also take this opportunity to add the check to the related 1-arg factory method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2319435650 From naoto at openjdk.org Wed Sep 3 17:06:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 17:06:32 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References: Message-ID: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Further requireNonNull() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27060/files - new: https://git.openjdk.org/jdk/pull/27060/files/7b3d4e00..d7cb9566 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=01-02 Stats: 14 lines in 4 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27060/head:pull/27060 PR: https://git.openjdk.org/jdk/pull/27060 From naoto at openjdk.org Wed Sep 3 17:06:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 17:06:32 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 16:01:01 GMT, Justin Lu wrote: >> Right. Added the explicit null check. (and a test case) > > If we are adding an explicit check to the ctor, might we also take this opportunity to add the check to the related 1-arg factory method? Indeed. Also did the same for `DecimalFormatSymbols`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2319613332 From jlu at openjdk.org Wed Sep 3 18:02:49 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 18:02:49 GMT Subject: Integrated: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 18:00:25 GMT, Justin Lu 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`. This pull request has now been integrated. Changeset: e3b36e3b Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/e3b36e3babb860d9d24a610160f47d42cfaafaa3 Stats: 266 lines in 2 files changed: 265 ins; 0 del; 1 mod 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/27008 From jlu at openjdk.org Wed Sep 3 18:57:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 18:57:42 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References:

Message-ID: <7Bd0xA8GDgik-VMG1hitlHAm04HvNWq2muI1MZA6h0E=.8dc8f4c3-4f30-42a1-a38e-8a25618c28bc@github.com> On Wed, 3 Sep 2025 17:06:32 GMT, Naoto Sato wrote: >> Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further requireNonNull() Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27060#pullrequestreview-3182018697 From rriggs at openjdk.org Wed Sep 3 21:24:43 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 21:24:43 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 21:22:16 GMT, Roger Riggs wrote: > Considerable scope creep here, the issue title and PR title should be updated. And the CSR. Modified ------------- PR Comment: https://git.openjdk.org/jdk/pull/27060#issuecomment-3250891660 From jlu at openjdk.org Wed Sep 3 22:00:48 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 22:00:48 GMT Subject: Integrated: 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: On Fri, 29 Aug 2025 23:59:54 GMT, Justin Lu 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. This pull request has now been integrated. Changeset: becc35f2 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/becc35f28792a48fac488841d0bc43226d7c96a7 Stats: 72 lines in 2 files changed: 60 ins; 9 del; 3 mod 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/27014 From rriggs at openjdk.org Thu Sep 4 22:15:07 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 22:15:07 GMT Subject: RFR: 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` [v3] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 17:06:32 GMT, Naoto Sato wrote: >> Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further requireNonNull() LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27060#pullrequestreview-3187358527 From jlu at openjdk.org Fri Sep 5 00:59:34 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 00:59:34 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests Message-ID: This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). **DFSDeserialization142.java & DFSSerialization142.java** (D) - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. **NumberFormat/DFSSerialization.java** (D) - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. **SerializationLoad.java & SerializationSave.java** (D) - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. **NumberRegression.java** (M) - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/27108/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366733 Stats: 1051 lines in 13 files changed: 214 ins; 787 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/27108.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27108/head:pull/27108 PR: https://git.openjdk.org/jdk/pull/27108 From rriggs at openjdk.org Fri Sep 5 14:17:10 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 5 Sep 2025 14:17:10 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Have you verified that the serialized streams in these new tests are identical to the hexformat versions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258516580 From ihse at openjdk.org Fri Sep 5 15:43:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 15:43:32 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp Message-ID: Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. ------------- Commit messages: - Fix syntax error - Don't use $(if ...) for KEYS. - Move weird characters in template expansion from command line to the template itself - Merge branch 'master' into cleanup-spp-gensrc - 8366837: Clean up gensrc by spp.Spp Changes: https://git.openjdk.org/jdk/pull/27078/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27078&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366837 Stats: 1321 lines in 9 files changed: 523 ins; 562 del; 236 mod Patch: https://git.openjdk.org/jdk/pull/27078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27078/head:pull/27078 PR: https://git.openjdk.org/jdk/pull/27078 From ihse at openjdk.org Fri Sep 5 15:43:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 15:43:32 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: <3R3SyNx6jYRhyK-xJwmoscTX2oSAV0zzQWHW2AYDf-A=.6bff4b0c-2e79-4648-a7d9-a42a559c4b48@github.com> On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. I have verified that the generated java source code in gensrc is byte-by-byte identical with and without this patch. That is really all that is needed in terms of correctness, but to make sure I do not run into some unexpected problem I am also running a confirmation round on our internal CI. Hm, something is messing up the command lines on the GHA hosts. Funny, I did not see it when testing elsewhere. I'll look into it. For the record: the changes in the X-Coder template means that additional empty lines will be inserted in the generated source. This has no real effect on anything substantial, but it means that line numbers change, which make a complete byte-by-byte comparison fail for anything that is dependent on these classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3250651080 PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3250722749 PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3258508787 From naoto at openjdk.org Fri Sep 5 16:16:12 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 16:16:12 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Although the existing tests are old and not run, I think the existing data can be reused. You can create overload for `deSer()` for these and test them. I believe they are the real serialized objects from the older releases, so I believe testing them still have value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258921072 From jlu at openjdk.org Fri Sep 5 16:37:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 16:37:08 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References:

Message-ID: <6RyH1eZqhrpM8vWDsIQ0ZcW7Qn35RECuAOyNPhbES2I=.0450ecca-59d3-4859-b658-34bdb74a9dde@github.com> On Fri, 5 Sep 2025 14:14:48 GMT, Roger Riggs wrote: > Have you verified that the serialized streams in these new tests are identical to the hexformat versions? I looked at the respective Serialization save files and what was being tested in the load files to determine the configuration of the replacement tests. I stepped through the tests with a debugger to make sure the data read from the stream that was being tested was accurate with what was indicated in the save file. I do not expect the streams themselves to be identical (since the new ones are mocked), but rather the invariants being tested should be the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258975202 From jlu at openjdk.org Fri Sep 5 16:41:10 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 16:41:10 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 16:13:50 GMT, Naoto Sato wrote: > Although the existing tests are old and not run, I think the existing data can be reused. You can create overload for `deSer()` for these and test them. I believe they are the real serialized objects from the older releases, so I believe testing them still have value. The new tests mock these streams so that we could do away with relying on the hex dump files (which required a user to navigate to the unused save file to determine how the stream was created). What is being tested should be the same for the mocked stream and the original stream itself. However, if it is desirable to test the exact streams from older releases, I can bring the data files back and test their streams directly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258986668 From ihse at openjdk.org Fri Sep 5 17:18:15 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 17:18:15 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: <3GbZE6bnaw9k543kmYqbPXW-sTX_6-ToUsorSTpEJ-0=.b6fb443e-9a13-4478-830f-633ec21dfb47@github.com> On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. This has passed Oracle internal CI testing for "builds-infra" tier 1-5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3259183136 From naoto at openjdk.org Fri Sep 5 17:42:09 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 17:42:09 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 16:38:06 GMT, Justin Lu wrote: > However, if it is desirable to test the exact streams from older releases, I can bring the data files back and test their streams directly. Yes, I think so. Unless there is any specific reason to remove tests, it is the main purpose for these *regression* tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3259242350 From rriggs at openjdk.org Fri Sep 5 19:18:09 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 5 Sep 2025 19:18:09 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Yes, the purpose of the hex dumps is to test exactly the stream produced by earlier versions. They should be retained. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3259470579 From naoto at openjdk.org Fri Sep 5 20:20:15 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 20:20:15 GMT Subject: RFR: 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` [v3] In-Reply-To: References:

Message-ID: On Wed, 3 Sep 2025 17:06:32 GMT, Naoto Sato wrote: >> Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further requireNonNull() Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27060#issuecomment-3259643744 From naoto at openjdk.org Fri Sep 5 20:23:14 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 20:23:14 GMT Subject: Integrated: 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 19:29:37 GMT, Naoto Sato wrote: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. This pull request has now been integrated. Changeset: 3824c7cd Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/3824c7cd06645b1dab5322015e8e6cf604afa754 Stats: 25 lines in 4 files changed: 20 ins; 0 del; 5 mod 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` Reviewed-by: jlu, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/27060 From jlu at openjdk.org Fri Sep 5 20:32:20 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 20:32:20 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v2] In-Reply-To: References: Message-ID: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Retain hex dump and test against older versions directly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27108/files - new: https://git.openjdk.org/jdk/pull/27108/files/95c3c0c7..59f07e9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=00-01 Stats: 383 lines in 7 files changed: 379 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27108.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27108/head:pull/27108 PR: https://git.openjdk.org/jdk/pull/27108 From jlu at openjdk.org Fri Sep 5 20:32:20 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 20:32:20 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Brought the hex dump files back (more appropriately under the DecimalFormat folder) and retained the original tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3259669710 From naoto at openjdk.org Fri Sep 5 21:14:17 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 21:14:17 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v2] In-Reply-To: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> References: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> Message-ID: <0CiO6X7STDojhN-y2aZSknIV66GexeGV_rMIradJ-mU=.8a6b2f51-987d-47ad-be33-1077cb56cab6@github.com> On Fri, 5 Sep 2025 20:32:20 GMT, Justin Lu wrote: >> This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. >> >> As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. >> >> These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. >> >> Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). >> >> **DFSDeserialization142.java & DFSSerialization142.java** (D) >> >> - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. >> >> **NumberFormat/DFSSerialization.java** (D) >> >> - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. >> - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. >> - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. >> >> **SerializationLoad.java & SerializationSave.java** (D) >> >> - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. >> >> **NumberRegression.java** (M) >> >> - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Retain hex dump and test against older versions directly LGTM. Thanks for revisiting the serialization tests. test/jdk/java/text/Format/DecimalFormat/DecimalFormat.114.txt line 2: > 1: # > 2: # Copyright (c) 1998, 2025, Oracle and/or its affiliates. All rights reserved. Nit: since the content of the file has not changed, I don't think we need to update the year ------------- PR Review: https://git.openjdk.org/jdk/pull/27108#pullrequestreview-3190796488 PR Review Comment: https://git.openjdk.org/jdk/pull/27108#discussion_r2326054684 From jlu at openjdk.org Fri Sep 5 21:39:36 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 21:39:36 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v3] In-Reply-To: References: Message-ID: <8sxIpUiYPlvs8yEyQFQcDARKjP_4C02j44N8mGNiMPY=.81c3c717-88d2-48ff-a59a-ee4b5f900220@github.com> > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Restore copyright years for hex dump files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27108/files - new: https://git.openjdk.org/jdk/pull/27108/files/59f07e9d..c57082c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=01-02 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27108.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27108/head:pull/27108 PR: https://git.openjdk.org/jdk/pull/27108 From jlu at openjdk.org Fri Sep 5 21:39:37 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 21:39:37 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v2] In-Reply-To: <0CiO6X7STDojhN-y2aZSknIV66GexeGV_rMIradJ-mU=.8a6b2f51-987d-47ad-be33-1077cb56cab6@github.com> References: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> <0CiO6X7STDojhN-y2aZSknIV66GexeGV_rMIradJ-mU=.8a6b2f51-987d-47ad-be33-1077cb56cab6@github.com> Message-ID: <-0NRA6CTbdNKNFKsmNAi64ySS_PtFBXyO0CPRyHbEtM=.cdeb1a6a-c268-46c7-ad50-a0afe99d64cd@github.com> On Fri, 5 Sep 2025 21:09:43 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Retain hex dump and test against older versions directly > > test/jdk/java/text/Format/DecimalFormat/DecimalFormat.114.txt line 2: > >> 1: # >> 2: # Copyright (c) 1998, 2025, Oracle and/or its affiliates. All rights reserved. > > Nit: since the content of the file has not changed, I don't think we need to update the year Restored in https://github.com/openjdk/jdk/pull/27108/commits/c57082c684961993b64b9627f4e64c5d7cea70b6 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27108#discussion_r2326093681 From erikj at openjdk.org Fri Sep 5 22:44:11 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 Sep 2025 22:44:11 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. make/modules/java.base/gensrc/GensrcBuffer.gmk line 162: > 160: $$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp > 161: $$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp > 162: $$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT) Indentation looks off here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326173444 From ihse at openjdk.org Fri Sep 5 22:50:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 22:50:11 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 22:34:32 GMT, Erik Joelsson wrote: >> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. > > make/modules/java.base/gensrc/GensrcBuffer.gmk line 162: > >> 160: $$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp >> 161: $$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp >> 162: $$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT) > > Indentation looks off here. I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326185455 From naoto at openjdk.org Fri Sep 5 23:08:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 23:08:41 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring Message-ID: A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27130/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27130&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367021 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27130/head:pull/27130 PR: https://git.openjdk.org/jdk/pull/27130 From jlu at openjdk.org Fri Sep 5 23:19:10 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 23:19:10 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: <9LSeqq53cdjE4uQBhl6Zw7rBvpa1xqMu_zJCv9hiAsM=.ba769751-d2a9-45e3-9991-ea22e6dbae4c@github.com> On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27130#pullrequestreview-3191031657 From naoto at openjdk.org Fri Sep 5 23:30:10 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 23:30:10 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v3] In-Reply-To: <8sxIpUiYPlvs8yEyQFQcDARKjP_4C02j44N8mGNiMPY=.81c3c717-88d2-48ff-a59a-ee4b5f900220@github.com> References: <8sxIpUiYPlvs8yEyQFQcDARKjP_4C02j44N8mGNiMPY=.81c3c717-88d2-48ff-a59a-ee4b5f900220@github.com> Message-ID: On Fri, 5 Sep 2025 21:39:36 GMT, Justin Lu wrote: >> This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. >> >> As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. >> >> These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. >> >> Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). >> >> **DFSDeserialization142.java & DFSSerialization142.java** (D) >> >> - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. >> >> **NumberFormat/DFSSerialization.java** (D) >> >> - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. >> - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. >> - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. >> >> **SerializationLoad.java & SerializationSave.java** (D) >> >> - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. >> >> **NumberRegression.java** (M) >> >> - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Restore copyright years for hex dump files Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27108#pullrequestreview-3191048971 From joehw at openjdk.org Fri Sep 5 23:58:10 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 5 Sep 2025 23:58:10 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: <1-561kkcAj3rPXJC8GxxcL8CXD6UoPNLORVjN5Tu4jI=.b0c94f0b-df8a-4741-b0f3-bd6889df25aa@github.com> On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27130#pullrequestreview-3191136843 From ihse at openjdk.org Sat Sep 6 09:05:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sat, 6 Sep 2025 09:05:10 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References:

Message-ID: On Fri, 5 Sep 2025 22:47:58 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/gensrc/GensrcBuffer.gmk line 162: >> >>> 160: $$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp >>> 161: $$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp >>> 162: $$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT) >> >> Indentation looks off here. > > I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect. Turns out you can actually change the tab size setting on GitHub. They set 4 as default but you can change it to 8 at https://github.com/settings/appearance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326684556 From erikj at openjdk.org Mon Sep 8 13:20:19 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Sep 2025 13:20:19 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27078#pullrequestreview-3196501441 From erikj at openjdk.org Mon Sep 8 13:20:21 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Sep 2025 13:20:21 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References:

Message-ID: On Sat, 6 Sep 2025 09:02:59 GMT, Magnus Ihse Bursie wrote: >> I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect. > > Turns out you can actually change the tab size setting on GitHub. They set 4 as default but you can change it to 8 at https://github.com/settings/appearance. You are right, thanks for that link! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2330222469 From naoto at openjdk.org Mon Sep 8 16:26:16 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:26:16 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27130#issuecomment-3267052349 From naoto at openjdk.org Mon Sep 8 16:26:17 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:26:17 GMT Subject: Integrated: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. This pull request has now been integrated. Changeset: 48831c65 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/48831c65b5535fef706b64a4eb23ba28b1567ead Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8367021: Regression in LocaleDataTest refactoring Reviewed-by: jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/27130 From ihse at openjdk.org Mon Sep 8 16:51:23 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 8 Sep 2025 16:51:23 GMT Subject: Integrated: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. This pull request has now been integrated. Changeset: 55af9d83 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/55af9d83800930966776224bc4c7ff4ab1af9817 Stats: 1321 lines in 9 files changed: 523 ins; 562 del; 236 mod 8366837: Clean up gensrc by spp.Spp Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/27078 From duke at openjdk.org Mon Sep 8 18:00:20 2025 From: duke at openjdk.org (xxDark) Date: Mon, 8 Sep 2025 18:00:20 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. Hello, this seemingly broke the build on Windows x64. VarHandleGuards class does not get generated. ^ f:\openjdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:558: error: cannot find symbol VarHandleGuards.class, getVarHandleGuardMethodName(guardType), ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\openjdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:562: error: cannot find symbol VarHandleGuards.class, LM_TRUSTED); ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\openjdk\src\java.base\share\classes\java\lang\invoke\VarHandle.java:2249: error: cannot find symbol UNSAFE.ensureClassInitialized(VarHandleGuards.class) Reverting this commit fixed the issue. The setup to configure the build was as follows: set JAVA_HOME=D:\jdks\temurin-24.0.32 d:\MSV2019\VC\Auxiliary\Build\vcvars64.bat d:\cygwin64\Cygwin.bat cd /cygdrive/f/openjdk bash configure make java.base $ make clean java.base Building targets 'clean java.base' in configuration 'windows-x86_64-server-release' Cleaning hotspot build artifacts ... done Cleaning jdk build artifacts ... done Cleaning bootcycle-build build artifacts ... done Cleaning test-results build artifacts ... done Cleaning test-support build artifacts ... done Cleaning test build artifacts ... done Cleaning buildtools build artifacts ... done Cleaning support build artifacts ... done Cleaning support/images build artifacts ... done Cleaning images build artifacts ... done Cleaning make-support build artifacts ... done Cleaning test-make build artifacts ... done Cleaning bundles build artifacts ... done Cleaning buildjdk build artifacts ... done Cleaned all build artifacts. Compiling up to 1 files for BUILD_TOOLS_HOTSPOT Compiling up to 9 files for BUILD_TOOLS_LANGTOOLS Generating classes for compiler.properties launcher.properties Compiling 17 properties into resource bundles for jdk.javadoc Generating FlagsEnum Compiling 19 properties into resource bundles for jdk.compiler Compiling up to 136 files for BUILD_java.compiler.interim Compiling up to 360 files for BUILD_jdk.compiler.interim Compiling up to 145 files for BUILD_jdk.internal.md.interim Compiling up to 213 files for BUILD_jdk.javadoc.interim Compiling up to 17 files for BUILD_JAVAC_SERVER Compiling up to 190 files for BUILD_TOOLS_JDK Compiling up to 2 files for COMPILE_DEPEND Compiling up to 2 files for BUILD_BREAKITERATOR_BASE Compiling up to 2 files for BUILD_BREAKITERATOR_LD SocketOptionRegistry.java.template d:\msvwin10kit\include\10.0.19041.0\um\winbase.h(9531): warning C5105: macro expansion producing 'defined' has undefined behavior Compiling 11 properties into resource bundles for java.base Compiling 3 properties into resource bundles for java.base Compiling 22 properties into resource bundles for java.base Compiling 11 properties into resource bundles for java.base Compiling up to 3366 files for java.base Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) Compiling up to 2 files for BUILD_JVMTI_TOOLS Creating support/modules_libs/java.base/server/jvm.dll from 1223 file(s) f:\jdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:558: error: cannot find symbol VarHandleGuards.class, getVarHandleGuardMethodName(guardType), ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\jdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:562: error: cannot find symbol VarHandleGuards.class, LM_TRUSTED); ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\jdk\src\java.base\share\classes\java\lang\invoke\VarHandle.java:2249: error: cannot find symbol UNSAFE.ensureClassInitialized(VarHandleGuards.class); ^ symbol: class VarHandleGuards location: class VarHandle 3 errors make[3]: *** [CompileJavaModules.gmk:102: /cygdrive/f/jdk/build/windows-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1 make[2]: *** [make/Main.gmk:182: java.base-java] Error 2 make[2]: *** Waiting for unfinished jobs.... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267328044 From liach at openjdk.org Mon Sep 8 18:09:18 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Sep 2025 18:09:18 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267361378 From alanb at openjdk.org Mon Sep 8 18:27:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Sep 2025 18:27:19 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References:

Message-ID: On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang wrote: > This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix. I think the change needs to backed out and the differences with line numbers checked to see what impact it will have on stack traces and mapping it back to the sources in the template files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267427085 From philip.race at oracle.com Mon Sep 8 18:52:43 2025 From: philip.race at oracle.com (Philip Race) Date: Mon, 8 Sep 2025 11:52:43 -0700 Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References:

Message-ID: Looks like it broke all the builds. So a P1 backout is needed. -phil. On 9/8/25 11:27 AM, Alan Bateman wrote: > On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang