From swen at openjdk.org  Sat Feb  1 00:41:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 1 Feb 2025 00:41:52 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <HkP-NaJux3FUlRBC5SBu6rSwtFwkxMv0dXInEzRAKc4=.9b397c8e-ad0d-450a-b77d-ad77ada4cc85@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
 <ZyLsa7o--VDmIlJS2vlhaTR2AQNg2Mo9Kyxh8DevTOg=.40c84a94-e863-4ba3-89b4-54617769e79f@github.com>
 <HkP-NaJux3FUlRBC5SBu6rSwtFwkxMv0dXInEzRAKc4=.9b397c8e-ad0d-450a-b77d-ad77ada4cc85@github.com>
Message-ID: <DXoUSX22Omyn2Z9S6c9frY8eucCUJWpOR7aCypm8x2g=.359222f3-38fd-4382-9bea-35ef5cb7663d@github.com>

On Mon, 23 Sep 2024 05:33:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> I don't think using SharedSecret just for performance improvement and code size reduction is the right way, as the class is the last resort as the header says:
> 
> ```
>  * <p><strong>
>  * Usage of these APIs often means bad encapsulation designs,
>  * increased complexity and lack of sustainability.
>  * Use this only as a last resort!
>  * </strong>
> ```

@naotoj 
 I have removed SharedSecrets, can you review it again?

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2628624789

From swen at openjdk.org  Sun Feb  2 17:37:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 2 Feb 2025 17:37:43 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via Class
 File API
Message-ID: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>

By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.

Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:

1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.

2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.

These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

Commit messages:
 - code style
 - simplify & code style
 - fix comment
 - fix comment
 - support OffsetTime
 - fix comments
 - optimize parseOffsetDateTime
 - optimize nano3
 - Generate PrinterParser using bytecode
 - add benchmark

Changes: https://git.openjdk.org/jdk/pull/23384/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23384&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349189
  Stats: 1687 lines in 9 files changed: 1543 ins; 88 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From swen at openjdk.org  Sun Feb  2 17:37:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 2 Feb 2025 17:37:43 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <TiRhj8Dq3ABd736LbX0VR5_QxgpLeng3x-4g059wEik=.652ee830-d57c-4159-90d0-a77150e8d8ac@github.com>

On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Below are the performance numbers on the MacBook M1, which show very significant performance improvements in both parse and format scenarios. Many scenarios have an improvement of more than 100%, and in parse, some scenarios have a performance improvement of more than 10 times.

# 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

#baseline
git checkout 75caf4f7c6acf04d4acbe6434ecdc9ce9a6b35d7
make test TEST="micro:java.time.format.DateTimeFormatterParse"
make test TEST="micro:java.time.format.DateTimeFormatterBench"

# current
git checkout 55ac19d6dfc401d66bb141ada501945b8145c62e
make test TEST="micro:java.time.format.DateTimeFormatterParse"
make test TEST="micro:java.time.format.DateTimeFormatterBench"



# 2. the performance benchmarks on MacBook M1 Pro



-# baseline
-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units (c49dd5b8efd)
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  16.326 ? 0.440  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  10.870 ? 0.080  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   9.187 ? 0.374  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.086 ? 0.235  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  23.344 ? 0.297  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  16.015 ? 0.198  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  13.561 ? 0.527  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  10.241 ? 0.055  ops/ms

+# current
+Benchmark                                                   (pattern)   Mode  Cnt    Score   Error   Units (55ac19d6dfc)
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15   44.066 ? 0.526  ops/ms
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15   31.789 ? 0.124  ops/ms
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   29.527 ? 0.090  ops/ms
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   23.733 ? 0.083  ops/ms
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  116.871 ? 1.173  ops/ms
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15   75.032 ? 0.321  ops/ms
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15   64.843 ? 0.633  ops/ms
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   49.958 ? 0.511  ops/ms


|   | pattern | baseline  | current | delta |
| --- | --- | --- | --- | --- |
| DateTimeFormatterBench.formatInstants | HH:mm:ss | 16.326 | 44.066 | 169.91% |
| DateTimeFormatterBench.formatInstants | HH:mm:ss.SSS | 10.870 | 31.789 | 192.45% |
| DateTimeFormatterBench.formatInstants | yyyy-MM-dd'T'HH:mm:ss | 9.187 | 29.527 | 221.40% |
| DateTimeFormatterBench.formatInstants | yyyy-MM-dd'T'HH:mm:ss.SSS | 7.086 | 23.733 | 234.93% |
| DateTimeFormatterBench.formatZonedDateTime | HH:mm:ss | 23.344 | 116.871 | 400.65% |
| DateTimeFormatterBench.formatZonedDateTime | HH:mm:ss.SSS | 16.015 | 75.032 | 368.51% |
| DateTimeFormatterBench.formatZonedDateTime | yyyy-MM-dd'T'HH:mm:ss | 13.561 | 64.843 | 378.16% |
| DateTimeFormatterBench.formatZonedDateTime | yyyy-MM-dd'T'HH:mm:ss.SSS | 10.241 | 49.958 | 387.82% |



-# baseline
-Benchmark                                           Mode  Cnt     Score      Error   Units (c49dd5b8efd)
-DateTimeFormatterParse.parseInstant                thrpt   15  2271.484 ?  114.069  ops/ms
-DateTimeFormatterParse.parseLocalDate              thrpt   15  6729.739 ? 1800.372  ops/ms
-DateTimeFormatterParse.parseLocalDateTime          thrpt   15  4224.068 ?  153.198  ops/ms
-DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15  4180.456 ?   82.478  ops/ms
-DateTimeFormatterParse.parseLocalTime              thrpt   15  4908.282 ?  208.797  ops/ms
-DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15  5412.657 ?  133.999  ops/ms
-DateTimeFormatterParse.parseOffsetDateTime         thrpt   15  2788.254 ?   85.754  ops/ms
-DateTimeFormatterParse.parseZonedDateTime          thrpt   15  2032.773 ?   78.660  ops/ms

+# current
+Benchmark                                           Mode  Cnt       Score       Error   Units (55ac19d6dfc)
+DateTimeFormatterParse.parseInstant                thrpt   15    3645.826 ?    53.758  ops/ms
+DateTimeFormatterParse.parseLocalDate              thrpt   15   57592.249 ?  3711.524  ops/ms
+DateTimeFormatterParse.parseLocalDateTime          thrpt   15   24713.840 ?  1462.137  ops/ms
+DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15   15246.892 ?   960.591  ops/ms
+DateTimeFormatterParse.parseLocalTime              thrpt   15  115757.021 ? 15040.874  ops/ms
+DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15   64888.840 ?   297.881  ops/ms
+DateTimeFormatterParse.parseOffsetDateTime         thrpt   15   15789.014 ?   188.675  ops/ms
+DateTimeFormatterParse.parseZonedDateTime          thrpt   15    2313.851 ?    61.707  ops/ms


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| DateTimeFormatterParse.parseInstant | 2271.484 | 3645.826 | 60.50% |
| DateTimeFormatterParse.parseLocalDate | 6729.739 | 57592.249 | 755.79% |
| DateTimeFormatterParse.parseLocalDateTime | 4224.068 | 24713.840 | 485.07% |
| DateTimeFormatterParse.parseLocalDateTimeWithNano | 4180.456 | 15246.892 | 264.72% |
| DateTimeFormatterParse.parseLocalTime | 4908.282 | 115757.021 | 2258.40% |
| DateTimeFormatterParse.parseLocalTimeWithNano | 5412.657 | 64888.840 | 1098.84% |
| DateTimeFormatterParse.parseOffsetDateTime | 2788.254 | 15789.014 | 466.27% |
| DateTimeFormatterParse.parseZonedDateTime | 2032.773 | 2313.851 | 13.83% |

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2629267435

From syan at openjdk.org  Mon Feb  3 08:42:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Feb 2025 08:42:34 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails
Message-ID: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>

Hi all,
The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:


        TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
        System.out.println(tz.getDisplayName());
        System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
        System.out.println(tz.getDisplayName(false, TimeZone.SHORT));


- Java 22 output:


~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
Ecuador Time
ECST
ECT


- Java 23 output:


~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
Ecuador Time
GMT-04:00
GMT-05:00


This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark fails

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

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

From scolebourne at openjdk.org  Mon Feb  3 09:05:48 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 3 Feb 2025 09:05:48 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>

On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

My comments refer to the outer parts of the PR. I haven't reviewed the class file generation part.

With these changes, please ensure that the same field can be output twice. Not sure if any tests cover that.

Thanks for the performance boost.

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

> 2592:         }
> 2593: 
> 2594:         public <T> T parse(CharSequence text, DateTimeFormatter formatter, TemporalQuery<T> query) {

Would package or protected scope be sufficient?

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

> 2633:         }
> 2634: 
> 2635:         static int litteral(CharSequence text, int pos, char literlal) {

`literal`

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

> 3060: 
> 3061:         protected final void printValueFixWidth3NotNegative(StringBuilder buf, int value) {
> 3062:             if (value > 1000) {

Should this be `>=` ?

src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line 327:

> 325:      * @return the year, from MIN_YEAR to MAX_YEAR
> 326:      */
> 327:     default int getYear() {

The whole point of `TemporalAccessor` is that it does not have methods like these - it does not assume anything about the temporal.

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

PR Review: https://git.openjdk.org/jdk/pull/23384#pullrequestreview-2589155307
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1938938121
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1938998806
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1939005206
PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1938934674

From aturbanov at openjdk.org  Mon Feb  3 12:49:51 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 3 Feb 2025 12:49:51 GMT
Subject: <i18n dev> RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v2]
In-Reply-To: <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
Message-ID: <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>

On Fri, 31 Jan 2025 19:46:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   generalize format comment

src/java.base/share/classes/java/util/Currency.java line 1182:

> 1180:         private static boolean isPastCutoverDate(String cutOver) {
> 1181:             return System.currentTimeMillis() >
> 1182:                     LocalDateTime.parse(cutOver.trim(), DateTimeFormatter.ISO_LOCAL_DATE_TIME)

Btw, do we really need this `trim()` call?
It looks redundant. prop.date is result part of `m.group(4)` of this regexp:
https://github.com/openjdk/jdk/blob/3f1d9b573546685215af06031656efe6f1429caf/src/java.base/share/classes/java/util/Currency.java#L255-L257
`(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2})`

I don't see how it could contain whitespace characters on start or end.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1939322191

From swen at openjdk.org  Mon Feb  3 13:07:27 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 13:07:27 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v2]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <h38bDMF4XGArBXFrLI7YA5imWXY_CIX-tGnbH7t8xiI=.04e1af22-3ce8-4e41-a33f-c0c9aa9002e4@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - typo
 - bug fix, from @jodastephen
 - bug fix, from @jodastephen
 - typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/aec84b03..b0ac02d4

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

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

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

From swen at openjdk.org  Mon Feb  3 13:10:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 13:10:47 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v2]
In-Reply-To: <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
Message-ID: <uzybaBXeJAB-oLmwnYsWEQeUvCFA5vii6jIG_YkzqSY=.ccaa6d2d-a4f5-4eb0-884d-9d31b9b985f3@github.com>

On Mon, 3 Feb 2025 07:59:02 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - typo
>>  - bug fix, from @jodastephen
>>  - bug fix, from @jodastephen
>>  - typo
>
> src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line 327:
> 
>> 325:      * @return the year, from MIN_YEAR to MAX_YEAR
>> 326:      */
>> 327:     default int getYear() {
> 
> The whole point of `TemporalAccessor` is that it does not have methods like these - it does not assume anything about the temporal.

If these methods are not added here, query will be called during formatting, which will incur some overhead. By providing these methods, if these Fields are not supported by the implementation of the TemporalAccessor, the error reporting behavior will remain the same as before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1939350252

From swen at openjdk.org  Mon Feb  3 13:19:45 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 13:19:45 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v2]
In-Reply-To: <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
Message-ID: <fhxOg8uMZiZHU2MRntKVxe1xTRuFTC8wZpkv7nknMiw=.e290bf1b-d236-4f5d-8b5a-ee7f57200cc9@github.com>

On Mon, 3 Feb 2025 09:02:59 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

> My comments refer to the outer parts of the PR. I haven't reviewed the class file generation part.
> 
> With these changes, please ensure that the same field can be output twice. Not sure if any tests cover that.
> 
> Thanks for the performance boost.

Thanks @jodastephen, the optimization of this PR is to take a shorter path through ClassFile generation, without changing the original behavior. The behavior of outputting the same field multiple times should be the same as before. I will also add tests to cover the current changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2630982846

From scolebourne at openjdk.org  Mon Feb  3 13:30:47 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 3 Feb 2025 13:30:47 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v2]
In-Reply-To: <uzybaBXeJAB-oLmwnYsWEQeUvCFA5vii6jIG_YkzqSY=.ccaa6d2d-a4f5-4eb0-884d-9d31b9b985f3@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <9CyvGLWWh4ELygv9gkUMlemHuIxsge2CC1BdcOHT3WQ=.999ff8e5-8fb2-45b2-b826-ce7a4f84809d@github.com>
 <uzybaBXeJAB-oLmwnYsWEQeUvCFA5vii6jIG_YkzqSY=.ccaa6d2d-a4f5-4eb0-884d-9d31b9b985f3@github.com>
Message-ID: <1W_tF6ZOntsiJh9n7QVeH3hZko7VQ22S6w64A9RCYk8=.0b7e24ec-a99d-4048-9a9c-64eaaa7ba207@github.com>

On Mon, 3 Feb 2025 13:07:54 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line 327:
>> 
>>> 325:      * @return the year, from MIN_YEAR to MAX_YEAR
>>> 326:      */
>>> 327:     default int getYear() {
>> 
>> The whole point of `TemporalAccessor` is that it does not have methods like these - it does not assume anything about the temporal.
>
> If these methods are not added here, query will be called during formatting, which will incur some overhead. By providing these methods, if these Fields are not supported by the implementation of the TemporalAccessor, the error reporting behavior will remain the same as before.

To retain the design of java.time, you cannot add these methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23384#discussion_r1939378358

From swen at openjdk.org  Mon Feb  3 14:16:31 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 14:16:31 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v3]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <3Z8AuD9fsDc7OcJs0HIJKB7xhg24fdX4XjQ1PnpRi8U=.805655b2-278d-4ee4-b5b7-c28dd02a687b@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - revert TemporalAccessor change, from @jodastephen
 - revert TemporalAccessor change, from @jodastephen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/b0ac02d4..5388a40e

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

  Stats: 113 lines in 3 files changed: 5 ins; 89 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From swen at openjdk.org  Mon Feb  3 14:37:30 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 14:37:30 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v4]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <-Dzxwsi4EhGQOWXnqpbO6K7yVMbB_gmguHsfMjrIKrg=.f9002b1c-fccd-4fc0-994f-7877cf10a563@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  use get & formatInt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/5388a40e..c44d03b5

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

  Stats: 21 lines in 1 file changed: 1 ins; 11 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From naoto at openjdk.org  Mon Feb  3 18:08:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 18:08:46 GMT
Subject: <i18n dev> RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v2]
In-Reply-To: <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
 <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>
Message-ID: <4wL9fyeYjujr4JKGG94IX60aqzgktbWiiORwiQxnIiQ=.6e16edb5-5566-425f-b0ca-4ffb2b232ac1@github.com>

On Mon, 3 Feb 2025 12:47:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   generalize format comment
>
> src/java.base/share/classes/java/util/Currency.java line 1182:
> 
>> 1180:         private static boolean isPastCutoverDate(String cutOver) {
>> 1181:             return System.currentTimeMillis() >
>> 1182:                     LocalDateTime.parse(cutOver.trim(), DateTimeFormatter.ISO_LOCAL_DATE_TIME)
> 
> Btw, do we really need this `trim()` call?
> It looks redundant. prop.date is result part of `m.group(4)` of this regexp:
> https://github.com/openjdk/jdk/blob/3f1d9b573546685215af06031656efe6f1429caf/src/java.base/share/classes/java/util/Currency.java#L255-L257
> `(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2})`
> 
> I don't see how it could contain whitespace characters on start or end.

That seems to be correct to me

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1939814234

From jlu at openjdk.org  Mon Feb  3 19:01:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Feb 2025 19:01:50 GMT
Subject: <i18n dev> RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
Message-ID: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>

> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
> 
> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.

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

  reflect review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23374/files
  - new: https://git.openjdk.org/jdk/pull/23374/files/a71a31bc..f8073ae5

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

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

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

From aturbanov at openjdk.org  Mon Feb  3 19:01:50 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 3 Feb 2025 19:01:50 GMT
Subject: <i18n dev> RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
Message-ID: <La73ytGY_0uvDrgJVfTNme8udzGEZvNDCPKK3hrfWXE=.4d928189-4d21-4469-a726-ed0aa1d1b5e1@github.com>

On Mon, 3 Feb 2025 18:58:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23374#pullrequestreview-2590758515

From jlu at openjdk.org  Mon Feb  3 19:01:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Feb 2025 19:01:51 GMT
Subject: <i18n dev> RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v2]
In-Reply-To: <4wL9fyeYjujr4JKGG94IX60aqzgktbWiiORwiQxnIiQ=.6e16edb5-5566-425f-b0ca-4ffb2b232ac1@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com>
 <WsZgDc0x-v--FYgQyThleuAUZRha5hookrYV_Rra2oE=.33748369-aa18-4b1c-84cb-5297d120d19f@github.com>
 <4wL9fyeYjujr4JKGG94IX60aqzgktbWiiORwiQxnIiQ=.6e16edb5-5566-425f-b0ca-4ffb2b232ac1@github.com>
Message-ID: <LWQFDuEWRbB5mXQc0p1pRlwLil93Oy1hrQqHpjBQcs4=.a9d90fb8-6270-48e6-bc43-e5305b3e8a94@github.com>

On Mon, 3 Feb 2025 18:05:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Currency.java line 1182:
>> 
>>> 1180:         private static boolean isPastCutoverDate(String cutOver) {
>>> 1181:             return System.currentTimeMillis() >
>>> 1182:                     LocalDateTime.parse(cutOver.trim(), DateTimeFormatter.ISO_LOCAL_DATE_TIME)
>> 
>> Btw, do we really need this `trim()` call?
>> It looks redundant. prop.date is result part of `m.group(4)` of this regexp:
>> https://github.com/openjdk/jdk/blob/3f1d9b573546685215af06031656efe6f1429caf/src/java.base/share/classes/java/util/Currency.java#L255-L257
>> `(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2})`
>> 
>> I don't see how it could contain whitespace characters on start or end.
>
> That seems to be correct to me

Right, that previous `trim()` is unnecessary. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1939875572

From naoto at openjdk.org  Mon Feb  3 19:10:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 19:10:48 GMT
Subject: <i18n dev> RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
Message-ID: <lE4zFHrxm1hr70SO7iTR4qhAm2x2ZmYGwWF5RdyDO60=.d5c1e672-f0c1-4c37-8b47-2fc3ceb5f042@github.com>

On Mon, 3 Feb 2025 19:01:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23374#pullrequestreview-2590777638

From jlu at openjdk.org  Mon Feb  3 22:07:09 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 3 Feb 2025 22:07:09 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <hAWVsuqr6EluyiSDcKUfW8YvyruBd78XloUVbrrVFT8=.1d9b2ee0-1140-44d2-a721-5680a09cfb1d@github.com>

On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

Switch to universal time for the time-zone to generalize the benchmark looks good to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23414#pullrequestreview-2591146673

From naoto at openjdk.org  Mon Feb  3 22:14:15 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 22:14:15 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v14]
In-Reply-To: <F6H5U0MvgE9lpclMnE4B3QLUUHUlBQdZv2b8lwQlolw=.c74e89e9-e78e-47bf-b9e6-45d9d97fe32c@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <F6H5U0MvgE9lpclMnE4B3QLUUHUlBQdZv2b8lwQlolw=.c74e89e9-e78e-47bf-b9e6-45d9d97fe32c@github.com>
Message-ID: <rMFZ8MTB_bazVEoxNnOLgquz_mNbnPVCJ8J1YJEBQvU=.6865b569-968e-4daa-a901-5ac2bd741f87@github.com>

On Thu, 30 Jan 2025 15:11:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not import static, from @RogerRiggs

Looks good with some minor nits

test/micro/org/openjdk/bench/java/time/ToStringBench.java line 131:

> 129:         }
> 130:     }
> 131: }

Please add a new line at the end

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

PR Review: https://git.openjdk.org/jdk/pull/20353#pullrequestreview-2591171271
PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1940137524

From naoto at openjdk.org  Mon Feb  3 22:14:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 22:14:16 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v13]
In-Reply-To: <z0dIl7k4w_LeGq8-yhcn4-kUuScntNjfibrAP7hZ7rQ=.0f50e511-b800-46c6-982f-0cc6bcd0644b@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <qzW61a-0HEm3P6ZrqiFwDOCcbPbQa_0pw6hWEKQSqxU=.49eff62c-76ed-4c5d-b780-c62bfdbfc5e6@github.com>
 <VahYLNpYxH4wjZ-A9fF_h7H7Qqhit3kkAuvRVwIU6HI=.de864376-80c1-45ce-a968-43383ba80eab@github.com>
 <z0dIl7k4w_LeGq8-yhcn4-kUuScntNjfibrAP7hZ7rQ=.0f50e511-b800-46c6-982f-0cc6bcd0644b@github.com>
Message-ID: <X3UwNKk5JfxetCEwXDKBbEKhSXaRaoddNm93XMRhDa4=.4de7ded0-a46d-49b5-885d-bf979de5fc35@github.com>

On Thu, 30 Jan 2025 14:36:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/DateTimeHelper.java line 26:
>> 
>>> 24:  * questions.
>>> 25:  */
>>> 26: package jdk.internal.util;
>> 
>> Maybe `jdk.internal.time` would be appropriate.
>
> Currently, since we only have the DateTimeHelper class, we can wait until there are two or more classes before creating the jdk.internal.time package.

This utility class can be final, and have a private default constructor so that no instance can be created.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1940135372

From naoto at openjdk.org  Mon Feb  3 22:21:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Feb 2025 22:21:10 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>

On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

The benchmark was provided with the fix to https://bugs.openjdk.org/browse/JDK-8304976, and most likely the failure was due to the removal of COMPAT locale provider. Would you double check the benchmark is relevant with your fix? Since UTC is a special time zone, so I just wanted to double check. If we need more practical short name, "PST" might not be a bad choice

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2632271474

From swen at openjdk.org  Mon Feb  3 22:31:10 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 22:31:10 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v15]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

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

  from @natoj

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/5924935e..5ca4d6e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=13-14

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

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

From swen at openjdk.org  Mon Feb  3 22:33:18 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 3 Feb 2025 22:33:18 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <ZyLsa7o--VDmIlJS2vlhaTR2AQNg2Mo9Kyxh8DevTOg=.40c84a94-e863-4ba3-89b4-54617769e79f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
 <ZyLsa7o--VDmIlJS2vlhaTR2AQNg2Mo9Kyxh8DevTOg=.40c84a94-e863-4ba3-89b4-54617769e79f@github.com>
Message-ID: <FW1S0UyFQCas48nYZG3pvFSMTLsEk136B9u5mDOqrn4=.b6389084-53b1-42c9-9e3b-31e13be7a65d@github.com>

On Tue, 3 Sep 2024 17:32:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - Speed up Instant.toString using JavaTimeAccess
>>  - add JavaTimeAccess SharedSecrets
>>  - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
>>  - breaking out the printNano methods
>>  - copyright
>>  - Update src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>>    
>>    Co-authored-by: Stephen Colebourne <scolebourne at joda.org>
>>  - 1. fix handle fraction == -1
>>    2. Split two methods to make codeSize less than 325
>>  - add comment
>>  - optimize format instant
>
> I don't think using SharedSecret just for performance improvement and code size reduction is the right way, as the class is the last resort as the header says:
> 
>  * <p><strong>
>  * Usage of these APIs often means bad encapsulation designs,
>  * increased complexity and lack of sustainability.
>  * Use this only as a last resort!
>  * </strong>

Thank you @naotoj, these have been fixed, please help review again

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2632311871

From swen at openjdk.org  Tue Feb  4 00:34:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 00:34:58 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v5]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <kYX9e_pv3p_MaJNJms0hy6cbwGwRRR3SKhcqbUvmuno=.1be358b0-99fb-43f6-9995-39538a45ba50@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  speed up format via wrapper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/c44d03b5..3b228eeb

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

  Stats: 128 lines in 2 files changed: 80 ins; 1 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From syan at openjdk.org  Tue Feb  4 02:32:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Feb 2025 02:32:15 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails
In-Reply-To: <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
Message-ID: <bMB3unbhpgcV7kGeJeA8ZPQpL8me4BSRpDaQYUDepKY=.c6635bf2-53c1-42bf-b77b-30811158d83f@github.com>

On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> most likely the failure was due to the removal of COMPAT locale provide

Yes. git bisect result shows that the failure was due to PR "8174269: Remove COMPAT locale data provider from JDK"
 
And, use jdk22, the difference between '-Djava.locale.providers=COMPAT' and '-Djava.locale.providers=CLDR' also convinced that.


~/software/jdk/temurin/jdk-22.0.2+9/bin/java -Djava.locale.providers=COMPAT ~/compiler-test/zzkk/TimeZoneTest.java 
Feb 04, 2025 10:19:51 AM sun.util.locale.provider.LocaleProviderAdapter <clinit>
WARNING: COMPAT locale provider will be removed in a future release
Ecuador Time
ECST
ECT



~/software/jdk/temurin/jdk-22.0.2+9/bin/java -Djava.locale.providers=CLDR ~/compiler-test/zzkk/TimeZoneTest.java 
Ecuador Time
GMT-05:00
GMT-05:00

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2632614374

From syan at openjdk.org  Tue Feb  4 02:40:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Feb 2025 02:40:59 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails [v2]
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

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

  Use PST instead of Z

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23414/files
  - new: https://git.openjdk.org/jdk/pull/23414/files/56fde9bc..7c84581e

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

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

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

From syan at openjdk.org  Tue Feb  4 02:40:59 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Feb 2025 02:40:59 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails
In-Reply-To: <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <p1fT39ka23odYt3tgPLFxrHdihnSqAuHIwg7s75vA8M=.933a46e7-deb0-44a4-a7d9-1a92c970eaf2@github.com>
Message-ID: <Mqp5WS-5IBysmTr_intSFBnadAXlovwZXF8JoZEx1Ps=.51becfb7-34aa-402e-b566-f850f9c21248@github.com>

On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> If we need more practical short name, "PST" might not be a bad choice.

I think use "Pacific Standard Time - PST" is a more practical chioce. The PR has been updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2632673527

From swen at openjdk.org  Tue Feb  4 07:57:06 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 07:57:06 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v6]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <9Ce6hvXSD06El0rkSCClTScKa4gpRz4MUODs8Ne5rXc=.580266b1-bd43-4774-add4-895a2c1707a2@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  add test and bug fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/3b228eeb..e5d3f83b

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

  Stats: 143 lines in 2 files changed: 128 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From swen at openjdk.org  Tue Feb  4 08:05:20 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 08:05:20 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v7]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <NDmUTFj8thNY5YCjr61kMHJGFHkzx7coN0K3w66o-eg=.44edbab6-ae5e-43e6-bcef-fb57683233a6@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  add instance test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/e5d3f83b..b9e54912

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

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

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

From swen at openjdk.org  Tue Feb  4 08:08:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 08:08:54 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v8]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <ciIVpHuV02-ZU29tQDfsVGyfbAsoqSX9ml_QMHfpUL8=.17b41c2b-5f51-466b-9a7d-3577d8a606f0@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - code style
 - code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/b9e54912..c5f35999

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

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

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

From swen at openjdk.org  Tue Feb  4 08:45:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 08:45:15 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v9]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <hYdMk5G3fLvHICPOVTkQdcL8fwoNDRMiBbdfyBzTBHk=.ecb3d285-5faa-412e-99ec-7a2d30958f49@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/c5f35999..101a2abc

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

  Stats: 172 lines in 1 file changed: 107 ins; 42 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From swen at openjdk.org  Tue Feb  4 09:02:26 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 09:02:26 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v10]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <wE2UfxFRDQ5Qi8tPor2CliltTTBWHys6SfqvK0TjbjI=.e63089a8-9435-4ce7-9422-b0b0725a358c@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  refactor test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/101a2abc..5fb9dc52

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

  Stats: 117 lines in 1 file changed: 56 ins; 57 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From swen at openjdk.org  Tue Feb  4 13:39:28 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 4 Feb 2025 13:39:28 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v11]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

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

  more use getInt & add more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23384/files
  - new: https://git.openjdk.org/jdk/pull/23384/files/5fb9dc52..e785189b

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

  Stats: 269 lines in 2 files changed: 242 ins; 8 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From jlu at openjdk.org  Tue Feb  4 17:10:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Feb 2025 17:10:26 GMT
Subject: <i18n dev> RFR: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String) [v3]
In-Reply-To: <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
 <jzPoG6Mv4efEDmR2Yr6AaFPNqTMQf2mapPj9mgYbe1M=.26dc02ab-ffc0-4080-a17d-97a7092be36b@github.com>
Message-ID: <gyivtJhehehJkd6wUwrM-jQe4n91RA8vY_OLIuwHXH8=.76018146-3c51-468e-80bc-cf6e8cbc243f@github.com>

On Mon, 3 Feb 2025 19:01:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
>> 
>> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23374#issuecomment-2634568025

From jlu at openjdk.org  Tue Feb  4 17:10:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Feb 2025 17:10:26 GMT
Subject: <i18n dev> Integrated: 8349000: Performance improvement for
 Currency.isPastCutoverDate(String)
In-Reply-To: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
References: <nlm-ZZE48thX6sTsr3MX7BGLp2F0C4j-mFvzE0ddhtY=.8936b256-54cc-4951-9661-c214fe3cf202@github.com>
Message-ID: <1SUczs6H4opt4d_-G8-xA6rrtWPx6EjXRG_V681PseI=.87f65cc9-4754-4b31-9465-801aa2a580fe@github.com>

On Thu, 30 Jan 2025 19:27:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`.
> 
> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise.

This pull request has now been integrated.

Changeset: 250ff86d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/250ff86dc86f73dbf7c944d9b5a792c4bdfeef0d
Stats:     14 lines in 1 file changed: 2 ins; 3 del; 9 mod

8349000: Performance improvement for Currency.isPastCutoverDate(String)

Reviewed-by: naoto, aturbanov

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

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

From naoto at openjdk.org  Tue Feb  4 18:00:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Feb 2025 18:00:32 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails [v2]
In-Reply-To: <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
Message-ID: <-w3oDImLp6wG2SQgcxbktW3_nwPCJQx_C96SSu02bNY=.87a7bd37-54d8-4edd-b827-794ba9ea4b43@github.com>

On Tue, 4 Feb 2025 02:40:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
>> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
>> 
>> 
>>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>>         System.out.println(tz.getDisplayName());
>>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
>> 
>> 
>> - Java 22 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> ECST
>> ECT
>> 
>> 
>> - Java 23 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> GMT-04:00
>> GMT-05:00
>> 
>> 
>> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use PST instead of Z

LGTM. Thanks for the update

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23414#pullrequestreview-2593642191

From naoto at openjdk.org  Tue Feb  4 18:16:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Feb 2025 18:16:27 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v15]
In-Reply-To: <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
Message-ID: <-HS2Rx0PAEZEOHmLhuAK20_Joeg6cC4tk9xJ5stImXE=.e0291528-dd80-4201-876c-9a0fe23d007f@github.com>

On Mon, 3 Feb 2025 22:31:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @natoj

Looks good. I confirmed the changes passed tier1-3 tests.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20353#pullrequestreview-2593676894

From syan at openjdk.org  Wed Feb  5 02:20:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Feb 2025 02:20:18 GMT
Subject: <i18n dev> RFR: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails [v2]
In-Reply-To: <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
 <GZedlVAX83lkQmbZj5hXc0-FAH0vXyMTfSaU5rg_tt4=.12301d1b-f5ee-4e78-ab96-c833a5ee1a24@github.com>
Message-ID: <yfntlS_Nqac6j1U1wjCpXYW9j83bSg8Us9xtKQweQkY=.463fb4bd-79be-4425-99cf-6e96f4ef00e0@github.com>

On Tue, 4 Feb 2025 02:40:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
>> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
>> 
>> 
>>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>>         System.out.println(tz.getDisplayName());
>>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
>> 
>> 
>> - Java 22 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> ECST
>> ECT
>> 
>> 
>> - Java 23 output:
>> 
>> 
>> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
>> Ecuador Time
>> GMT-04:00
>> GMT-05:00
>> 
>> 
>> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use PST instead of Z

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomment-2635551383

From syan at openjdk.org  Wed Feb  5 02:20:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Feb 2025 02:20:19 GMT
Subject: <i18n dev> Integrated: 8349200: [JMH]
 time.format.ZonedDateTimeFormatterBenchmark fails
In-Reply-To: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
References: <PfsrPgy9G4LmDdrUMs7PwZ9U2YZ03wdKcF4NvHi4YgM=.9ff8912c-79d9-4e6b-84c7-0161ba2d791d@github.com>
Message-ID: <MRXYgdTqM042GMwEHeR5HphOsysrNzu-n_ZDX3_FO5k=.0ca88be1-f61d-49bc-859b-dff896ba719a@github.com>

On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The JMH test "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse" fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT' could not be parsed at index 17".
> The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23 the `ECT` TimeZone.SHORT doesn't support anymore. Below code snippet shows the difference between jdk22 and jdk23:
> 
> 
>         TimeZone tz = TimeZone.getTimeZone("America/Guayaquil");
>         System.out.println(tz.getDisplayName());
>         System.out.println(tz.getDisplayName(true, TimeZone.SHORT));
>         System.out.println(tz.getDisplayName(false, TimeZone.SHORT));
> 
> 
> - Java 22 output:
> 
> 
> ~/software/jdk/temurin/jdk-22.0.2+9/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> ECST
> ECT
> 
> 
> - Java 23 output:
> 
> 
> ~/software/jdk/temurin/jdk-23+37/bin/java ~/compiler-test/zzkk/TimeZoneTest.java 
> Ecuador Time
> GMT-04:00
> GMT-05:00
> 
> 
> This PR use `Z` TimeZone.SHORT instead of `ECT` will make this test more generic. Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: a51e6699
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a51e6699b497564de65620a36dc38437ca87cb32
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8349200: [JMH] time.format.ZonedDateTimeFormatterBenchmark fails

Reviewed-by: naoto, jlu

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

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

From jlu at openjdk.org  Wed Feb  5 21:30:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Feb 2025 21:30:40 GMT
Subject: <i18n dev> RFR: 8349493: Replace sun.util.locale.ParseStatus usage
 with java.text.ParsePosition
Message-ID: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>

Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.

Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Wed Feb  5 22:55:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Feb 2025 22:55:11 GMT
Subject: <i18n dev> RFR: 8349493: Replace sun.util.locale.ParseStatus
 usage with java.text.ParsePosition
In-Reply-To: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
Message-ID: <s4BOef0QBtEIxDMuhglPadEJkFSm0CvQTc0J5BFnV4M=.06662615-0959-4bf7-9606-280a276f04b5@github.com>

On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
> 
> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

Looks good. Nice cleanup. I don't think changing the exception message requires a CSR though.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 423:

> 421:             throw new IllformedLocaleException(String.format("Ill formed tag:" +
> 422:                     " %s", sts.errorMsg));
> 423:         }

If we want to keep the existing behavior, catch the ILE and throw a new one with the prepending text, but I think that won't be necessary.

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

PR Review: https://git.openjdk.org/jdk/pull/23474#pullrequestreview-2597166661
PR Review Comment: https://git.openjdk.org/jdk/pull/23474#discussion_r1943783817

From jlu at openjdk.org  Wed Feb  5 23:02:19 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Feb 2025 23:02:19 GMT
Subject: <i18n dev> RFR: 8349493: Replace sun.util.locale.ParseStatus
 usage with java.text.ParsePosition
In-Reply-To: <s4BOef0QBtEIxDMuhglPadEJkFSm0CvQTc0J5BFnV4M=.06662615-0959-4bf7-9606-280a276f04b5@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
 <s4BOef0QBtEIxDMuhglPadEJkFSm0CvQTc0J5BFnV4M=.06662615-0959-4bf7-9606-280a276f04b5@github.com>
Message-ID: <hmmKu6nsY9KQTM15s1W-pwq00yu0gElk1nJiEOJCmSM=.c35cf120-afb5-4077-8743-16b5c38a9ac6@github.com>

On Wed, 5 Feb 2025 22:51:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
>> 
>> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.
>
> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 423:
> 
>> 421:             throw new IllformedLocaleException(String.format("Ill formed tag:" +
>> 422:                     " %s", sts.errorMsg));
>> 423:         }
> 
> If we want to keep the existing behavior, catch the ILE and throw a new one with the prepending text, but I think that won't be necessary.

Yes, I didn't think it was needed to do that, the existing message should already have enough details. I filed the CSR just in case, I'll withdraw it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23474#discussion_r1943790683

From dholmes at openjdk.org  Thu Feb  6 01:52:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 01:52:57 GMT
Subject: <i18n dev> RFR: 8349511: [BACKOUT] Framework for tracing makefile
 inclusion and parsing
Message-ID: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>

This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.

JDK-8348190: Framework for tracing makefile inclusion and parsing

The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.

Thanks.

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

Commit messages:
 - Revert "8348190: Framework for tracing makefile inclusion and parsing"

Changes: https://git.openjdk.org/jdk/pull/23481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349511
  Stats: 2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod
  Patch: https://git.openjdk.org/jdk/pull/23481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23481/head:pull/23481

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

From darcy at openjdk.org  Thu Feb  6 02:04:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Feb 2025 02:04:15 GMT
Subject: <i18n dev> RFR: 8349511: [BACKOUT] Framework for tracing
 makefile inclusion and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Approving clean backout.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597463613

From naoto at openjdk.org  Thu Feb  6 02:14:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Feb 2025 02:14:10 GMT
Subject: <i18n dev> RFR: 8349493: Replace sun.util.locale.ParseStatus
 usage with java.text.ParsePosition
In-Reply-To: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
Message-ID: <gjhWPLhaHGu3ubT4wL4m3O6S3qZ5jsOT3RYbxpL0CME=.8327a3f2-51ed-4e6b-9d62-e6fa78ca11a7@github.com>

On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
> 
> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23474#pullrequestreview-2597486343

From dholmes at openjdk.org  Thu Feb  6 02:44:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:44:08 GMT
Subject: <i18n dev> RFR: 8349511: [BACKOUT] Framework for tracing
 makefile inclusion and parsing
In-Reply-To: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
Message-ID: <AWJoVSTeygOR6BO1A3fQOGLPGVzlF6zuRNMw4TMiVZc=.cf4c9f9e-75b8-45ef-b295-8fb57846fa24@github.com>

On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Approving clean backout.

Thanks @jddarcy !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638687813

From mikael at openjdk.org  Thu Feb  6 02:54:17 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 6 Feb 2025 02:54:17 GMT
Subject: <i18n dev> RFR: 8349511: [BACKOUT] Framework for tracing
 makefile inclusion and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597531112

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: <i18n dev> RFR: 8349511: [BACKOUT] Framework for tracing
 makefile inclusion and parsing
In-Reply-To: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
Message-ID: <o_LWA-N7-KZ6e3MLu8U2GOcgFRK6rgW58IWj5sGK_6s=.12f73a3c-70ce-49c3-b486-1585990fefac@github.com>

On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Marked as reviewed by mikael (Reviewer).

Thanks @vidmik !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638701374

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: <i18n dev> Integrated: 8349511: [BACKOUT] Framework for tracing
 makefile inclusion and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <aWuh7nyeGLH2h82Pk0IN4KD8wwSrAXkioaZ_EWlOWN4=.5e1f6202-37f7-4b5a-a36a-2adf4ca85b10@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 64bd8d25
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2
Stats:     2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod

8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

Reviewed-by: darcy, mikael

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

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

From alanb at openjdk.org  Thu Feb  6 15:01:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Feb 2025 15:01:28 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v11]
In-Reply-To: <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>
Message-ID: <pWYS-bIas8bbNzBEG4gf9B7pF4rDEXeddUitdqeoi1o=.8a083501-9001-4a7f-947c-2376e1296a32@github.com>

On Tue, 4 Feb 2025 13:39:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
>> 
>> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
>> 
>> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
>> 
>> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
>> 
>> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more use getInt & add more test

I've set the number of reviewers to at least 2 as there is a lot of complexity proposed here and one Reviewer will not be sufficient. Before spending any time on this, maintainers in this area will need to consider whether the complexity is worth it and whether resources should be taken from larger projects to review the proposed changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2636511769

From duke at openjdk.org  Fri Feb  7 00:12:15 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Feb 2025 00:12:15 GMT
Subject: <i18n dev> Withdrawn: 8346117: Add test annotation
In-Reply-To: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
References: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
Message-ID: <y6r_BU1BQj2RZSKTCX3hHrBUOsX1C1KHJ46Ul7fsU_U=.4db75380-2005-4604-b7a5-72d03b362757@github.com>

On Thu, 12 Dec 2024 16:59:58 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @mahendrachhipa @bwhuang-us @serhiysachkov

This pull request has been closed without being integrated.

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

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

From jlu at openjdk.org  Fri Feb  7 17:11:24 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Feb 2025 17:11:24 GMT
Subject: <i18n dev> Integrated: 8349493: Replace sun.util.locale.ParseStatus
 usage with java.text.ParsePosition
In-Reply-To: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
References: <ei1wec-7_GCLiq6sKPWJpDKC7-WB-_FI3PMU2i3XZuc=.855f6166-016d-452f-8a44-bab23479b095@github.com>
Message-ID: <vukQXZryDb8I1yahT2wd47a5S4pP_LhobnCyu59p4Pw=.47cd88a3-9732-4e94-9ae7-d29eccfe6370@github.com>

On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes  _sun.util.locale.ParseStatus_ which is a Locale helper class used for parsing language tags.
> 
> Such usages should be replaced by _java.text.ParsePosition_ which has almost 1 to 1 behavior. Note that this cleanup changes the exception message in `Locale.caseFoldLanguageTag(String)` to no longer be prepended by `"Ill formed tag: "`. As such, a CSR is filed to address the compatibility aspect.

This pull request has now been integrated.

Changeset: fb847bb2
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb847bb2afc9e9e164430078c5c403ec6583d50e
Stats:     137 lines in 3 files changed: 12 ins; 78 del; 47 mod

8349493: Replace sun.util.locale.ParseStatus usage with java.text.ParsePosition

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Wed Feb 12 19:39:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 19:39:33 GMT
Subject: <i18n dev> RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException
Message-ID: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>

Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.

In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Wed Feb 12 20:35:19 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 20:35:19 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550 if
 -Duser.timezone= is set to a deprecated zone id
Message-ID: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>

Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

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

Commit messages:
 - initial commit

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

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

From iris at openjdk.org  Wed Feb 12 21:40:23 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 12 Feb 2025 21:40:23 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550
 if -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <qU-GXQ3ClAoY7UZd1c0WMDDmEfkRYF-UJ7jNUWiFDaI=.ed4d7135-7645-4cc1-90b5-3cd272708c16@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613267853

From naoto at openjdk.org  Wed Feb 12 21:43:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 21:43:16 GMT
Subject: <i18n dev> RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
Message-ID: <ViWemy9TBU3wIes2K72-boplIynghN2wnPGAzmPodLQ=.7e311da6-f77c-4b2b-8c31-78e939bb6cfb@github.com>

On Wed, 12 Feb 2025 19:34:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
> 
> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

Looks good

test/jdk/java/util/Locale/IllformedRangeTest.java line 40:

> 38: import static org.junit.jupiter.api.Assertions.assertThrows;
> 39: 
> 40: public class IllformedRangeTest {

Instead of creating a new test file, you might want to add this test into `LanguageRangeTest.java`

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

PR Review: https://git.openjdk.org/jdk/pull/23596#pullrequestreview-2613272653
PR Review Comment: https://git.openjdk.org/jdk/pull/23596#discussion_r1953439911

From jlu at openjdk.org  Wed Feb 12 22:06:35 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 22:06:35 GMT
Subject: <i18n dev> RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <ViWemy9TBU3wIes2K72-boplIynghN2wnPGAzmPodLQ=.7e311da6-f77c-4b2b-8c31-78e939bb6cfb@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
 <ViWemy9TBU3wIes2K72-boplIynghN2wnPGAzmPodLQ=.7e311da6-f77c-4b2b-8c31-78e939bb6cfb@github.com>
Message-ID: <RA92so1UWHAPBBL1r7iPTP4jc4D0av6tHQqopzvSKtE=.5a40d2d5-c5a3-4de9-b22c-c5a295145975@github.com>

On Wed, 12 Feb 2025 21:40:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto's review - Include test in LanguageRangeTest instead. Additionally, bundle existing LRToString test into LanguageRangeTest as well
>
> test/jdk/java/util/Locale/IllformedRangeTest.java line 40:
> 
>> 38: import static org.junit.jupiter.api.Assertions.assertThrows;
>> 39: 
>> 40: public class IllformedRangeTest {
> 
> Instead of creating a new test file, you might want to add this test into `LanguageRangeTest.java`

Moved `IllformedRangeTest.java` as well as the existing `LRToString.java` test into `LanguageRangeTest.java`, which can now serve as a general class test. Also converted the test to JUnit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23596#discussion_r1953464752

From jlu at openjdk.org  Wed Feb 12 22:06:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 22:06:34 GMT
Subject: <i18n dev> RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
Message-ID: <qPvb4UPZXdLgaEDQ8LQwZR_DjN2A1eNunC5TBHcHOgY=.a7a847b7-5587-45f7-9f51-ef318347aa98@github.com>

> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
> 
> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

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

  Naoto's review - Include test in LanguageRangeTest instead. Additionally, bundle existing LRToString test into LanguageRangeTest as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23596/files
  - new: https://git.openjdk.org/jdk/pull/23596/files/f1a90f2a..797f69a7

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

  Stats: 204 lines in 3 files changed: 61 ins; 136 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23596.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23596/head:pull/23596

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

From joehw at openjdk.org  Wed Feb 12 22:18:18 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 12 Feb 2025 22:18:18 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550
 if -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <OZfzzUhemcIefF7DOq17RUhiEs54lylc_0sL62Xe7u4=.3e041519-cead-4e29-928f-2940f3ac2d21@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613339069

From jlu at openjdk.org  Wed Feb 12 22:24:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 22:24:10 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550
 if -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <LpTXlvpIQbictHsy6gKQCmeFUrMfTN-LP3-znzt8zVM=.3270a59d-8aac-4563-9093-dc8f8783022b@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

lgtm

test/jdk/java/util/TimeZone/ThreeLetterZoneID.java line 52:

> 50:     @Test
> 51:     public void testExplicitGetTimeZone() throws Exception {
> 52:         ProcessTools.executeTestJava("ThreeLetterZoneID", "dummy").shouldMatch(WARNING);

Could use `stderrShouldMatch` here and below instead of `shouldMatch`

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613347789
PR Review Comment: https://git.openjdk.org/jdk/pull/23597#discussion_r1953484074

From naoto at openjdk.org  Wed Feb 12 22:55:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 22:55:25 GMT
Subject: <i18n dev> RFR: 8349883: Locale.LanguageRange.parse("-") throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <qPvb4UPZXdLgaEDQ8LQwZR_DjN2A1eNunC5TBHcHOgY=.a7a847b7-5587-45f7-9f51-ef318347aa98@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
 <qPvb4UPZXdLgaEDQ8LQwZR_DjN2A1eNunC5TBHcHOgY=.a7a847b7-5587-45f7-9f51-ef318347aa98@github.com>
Message-ID: <wHJ0SjCsj6eaU5FFd0Itl62znKv5srJauGrXqEmjWeo=.8273deb4-beae-4b52-ab73-1d7ea2c4ddaa@github.com>

On Wed, 12 Feb 2025 22:06:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
>> 
>> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review - Include test in LanguageRangeTest instead. Additionally, bundle existing LRToString test into LanguageRangeTest as well

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23596#pullrequestreview-2613404677

From naoto at openjdk.org  Wed Feb 12 23:07:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 12 Feb 2025 23:07:26 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550
 if -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23597/files
  - new: https://git.openjdk.org/jdk/pull/23597/files/197d50fb..d1b990f7

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

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

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

From jlu at openjdk.org  Wed Feb 12 23:12:09 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Feb 2025 23:12:09 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550
 if -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
 <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
Message-ID: <HtgteRuqMEsakhUV5ledPYtxEDhgrOLN3L96HdLYMmI=.c72306b5-a277-4ef3-847b-dcf1b2aa12ac@github.com>

On Wed, 12 Feb 2025 23:07:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2613429565

From joehw at openjdk.org  Thu Feb 13 20:19:10 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 13 Feb 2025 20:19:10 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550
 if -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
 <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
Message-ID: <ttPgLPeHj7XDRJjUtbhQgGMMFaN1iGfxDrcLOqJ62k0=.90cd59dc-cbe4-43c8-8d18-f1059228eaa9@github.com>

On Wed, 12 Feb 2025 23:07:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23597#pullrequestreview-2616127694

From naoto at openjdk.org  Thu Feb 13 21:00:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Feb 2025 21:00:16 GMT
Subject: <i18n dev> RFR: 8349873: StackOverflowError after JDK-8342550
 if -Duser.timezone= is set to a deprecated zone id [v2]
In-Reply-To: <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
 <uGgWJgX4LUeeG504dXBNm7ZbF5WdAx6t_3vkvhoa6JQ=.b9db9b85-f3e3-4ac3-aae3-1a02ea99a2b6@github.com>
Message-ID: <QKEvw3muTRFs9pC5UVB0XhGAnNdD_WJMjoWHA1nUNig=.3d6df28b-e0db-4feb-bce3-6a3efeb0030a@github.com>

On Wed, 12 Feb 2025 23:07:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23597#issuecomment-2657694002

From naoto at openjdk.org  Thu Feb 13 21:00:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Feb 2025 21:00:17 GMT
Subject: <i18n dev> Integrated: 8349873: StackOverflowError after
 JDK-8342550 if -Duser.timezone= is set to a deprecated zone id
In-Reply-To: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
References: <nRITIIzu1Gptt6S5H_a7e6gu4Xa9UVXdEoJLmtZRKqE=.565fe601-aa7f-42f4-8ca0-5c47d505809e@github.com>
Message-ID: <JTj6KZTqUXCu2xMJzcfwSEpbX3hP29uGj-v128kymsU=.0b8b6afc-7d12-4eb7-a7b1-bf7e917cdf9e@github.com>

On Wed, 12 Feb 2025 19:35:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the regression caused by the JDK-8342550 fix. Since the logging facility depends on TimeZone class, it should not use the logging facility. Replacing the logging with simple System.err.printf() will fix the issue.

This pull request has now been integrated.

Changeset: 3e7acfac
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e7acfac48229441b243a6ac564e719963e4f43d
Stats:     21 lines in 2 files changed: 10 ins; 1 del; 10 mod

8349873: StackOverflowError after JDK-8342550 if -Duser.timezone= is set to a deprecated zone id

Reviewed-by: joehw, jlu, iris

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

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

From jlu at openjdk.org  Thu Feb 13 22:28:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Feb 2025 22:28:13 GMT
Subject: <i18n dev> Integrated: 8349883: Locale.LanguageRange.parse("-")
 throws ArrayIndexOutOfBoundsException
In-Reply-To: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
References: <wHGVj83af-xyB1NmZgOYmktTR-UUyowNLFlGq3kVkTI=.8b2809d0-1c77-4f45-8948-8c8f6155f495@github.com>
Message-ID: <y8s5Kjl6cEtQJflyxkR2Y4uSFqKqtubgCngpCC7kwPc=.c7def4ca-0776-4aeb-a1b4-5859cb3a640f@github.com>

On Wed, 12 Feb 2025 19:34:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents a (non-specified) `AIOOBE` from leaking out of the range accepting endpoints in `Locale.LanguageRange`.
> 
> In the reported error case, the invalid range is a lone "-" which is `split` into an empty array. Checking if the range ends with "-" first, avoids indexing the empty array.

This pull request has now been integrated.

Changeset: 3741c980
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3741c980b865b7122d07655353657d683923c40d
Stats:     138 lines in 3 files changed: 61 ins; 67 del; 10 mod

8349883: Locale.LanguageRange.parse("-") throws ArrayIndexOutOfBoundsException

Reviewed-by: naoto

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

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

From coffeys at openjdk.org  Fri Feb 14 09:29:16 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 14 Feb 2025 09:29:16 GMT
Subject: <i18n dev> RFR: 8346117: Add test annotation
In-Reply-To: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
References: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
Message-ID: <94sv6fIT-HBQU1Mr2-mToHKzerFH1yRQatdCag5mbUc=.81cf535a-2a70-4771-ae51-aec4e85839df@github.com>

On Thu, 12 Dec 2024 16:59:58 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @mahendrachhipa @bwhuang-us @serhiysachkov

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22717#pullrequestreview-2617200662

From duke at openjdk.org  Fri Feb 14 16:10:12 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Feb 2025 16:10:12 GMT
Subject: <i18n dev> RFR: 8346117: Add test annotation
In-Reply-To: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
References: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
Message-ID: <z0-8-K8fr7D4h61d7jBKUMi6I5VGyeo0kdX2g1Hf58I=.403d8a3d-8d64-4456-8a08-433be18b6549@github.com>

On Thu, 12 Dec 2024 16:59:58 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @mahendrachhipa @bwhuang-us @serhiysachkov

@frkator 
Your change (at version d3e86c769ff4d86051bee35a8f467051fca4913c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22717#issuecomment-2659725815

From isipka at openjdk.org  Fri Feb 14 16:22:17 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Fri, 14 Feb 2025 16:22:17 GMT
Subject: <i18n dev> Integrated: 8346117: Add test annotation
In-Reply-To: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
References: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
Message-ID: <yBp19dlZqkUzpnmXglQXcGI3bJt1OgUyaGJXU2JmsAU=.f565fd5f-db2e-4b4f-a091-33bce44ecb33@github.com>

On Thu, 12 Dec 2024 16:59:58 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @mahendrachhipa @bwhuang-us @serhiysachkov

This pull request has now been integrated.

Changeset: 2a90b90a
Author:    Ivan ?ipka <isipka at openjdk.org>
Committer: Mahendra Chhipa <mchhipa at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a90b90a95da91b71cd90caeafae5adaee621ebf
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8346117: Add test annotation

Reviewed-by: coffeys

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

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

From naoto at openjdk.org  Fri Feb 14 17:22:23 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Feb 2025 17:22:23 GMT
Subject: <i18n dev> RFR: 8346117: Add test annotation
In-Reply-To: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
References: <I1-jiSNasv_EBanj7IZkHIS-QMShkRhwJhhU_xnIaHE=.cd344907-21eb-45b5-9008-157b66e4262f@github.com>
Message-ID: <8kuRq2ah8ogVeIX1M3eQdbrqDAi_K1bhXLnQyvoNZoo=.e3f1e4c4-dbb2-4f60-8196-438dde6fc16d@github.com>

On Thu, 12 Dec 2024 16:59:58 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @mahendrachhipa @bwhuang-us @serhiysachkov

Thanks for making them run. Please change the copyright year up-to-date

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

PR Comment: https://git.openjdk.org/jdk/pull/22717#issuecomment-2659875909

From acobbs at openjdk.org  Sat Feb 15 21:27:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 15 Feb 2025 21:27:56 GMT
Subject: <i18n dev> RFR: 8343478: Remove unnecessary @SuppressWarnings
 annotations (core-libs) [v12]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
 - Remove a few more unnecessary suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update @LastModified tags.
 - Revert changes under src/java.desktop (to be moved into a separate PR).
 - Bump copyright year to 2025.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary @SuppressWarnings annotations.
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

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

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=11
  Stats: 211 lines in 93 files changed: 0 ins; 90 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From imyers at openjdk.org  Tue Feb 18 23:08:57 2025
From: imyers at openjdk.org (Ian Myers)
Date: Tue, 18 Feb 2025 23:08:57 GMT
Subject: <i18n dev> RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
Message-ID: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>

On Wed, 29 Jan 2025 23:15:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
>> 
>> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
>> 
>> - Contacted ietf, these are the new links to use.
>> 
>> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
>> 
>> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.
>
> make/common/Modules.gmk line 95:
> 
>> 93: SPEC_SUBDIRS += share/specs
>> 94: 
>> 95: MAN_SUBDIRS += share/man windows/man
> 
> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.

Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1960715214

From nbenalla at openjdk.org  Wed Feb 19 11:05:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 19 Feb 2025 11:05:59 GMT
Subject: <i18n dev> RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
 <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
Message-ID: <HX3zhtWYlzDwcThjfRfh2UiSgtjvxOyz3lHTM4rr3cw=.98597d31-7abe-40a2-b7bf-36b592597b34@github.com>

On Tue, 18 Feb 2025 23:06:42 GMT, Ian Myers <imyers at openjdk.org> wrote:

>> make/common/Modules.gmk line 95:
>> 
>>> 93: SPEC_SUBDIRS += share/specs
>>> 94: 
>>> 95: MAN_SUBDIRS += share/man windows/man
>> 
>> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.
>
> Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

I think it will prevent windows-only tools man pages from being generated in linux builds, but it would prevent the man pages from appearing in the generated documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1961472101

From isipka at openjdk.org  Thu Feb 20 17:06:21 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 20 Feb 2025 17:06:21 GMT
Subject: <i18n dev> RFR: 8350442: Update copyright
Message-ID: <cneifM5QORloB6I2qGdeCy7YyOuvWh0nHz89vy1vQLs=.6105f832-76f9-4643-8e8b-4e3e3bfc988c@github.com>

@naotoj  @coffeys @mahendrachhipa 

update of copyright years. Details on ticket.

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

Commit messages:
 - copyright updated

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

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

From naoto at openjdk.org  Thu Feb 20 18:04:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Feb 2025 18:04:52 GMT
Subject: <i18n dev> RFR: 8350442: Update copyright
In-Reply-To: <cneifM5QORloB6I2qGdeCy7YyOuvWh0nHz89vy1vQLs=.6105f832-76f9-4643-8e8b-4e3e3bfc988c@github.com>
References: <cneifM5QORloB6I2qGdeCy7YyOuvWh0nHz89vy1vQLs=.6105f832-76f9-4643-8e8b-4e3e3bfc988c@github.com>
Message-ID: <_tizwAlRZdgJN5JPBF7m7Ga9sQcpYQDOVtESvi0ihKw=.5b0d9d21-e7a2-490d-8bb4-f989e3f93a8a@github.com>

On Thu, 20 Feb 2025 17:01:36 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @naotoj  @coffeys @mahendrachhipa 
> 
> update of copyright years. Details on ticket.

Thanks!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23714#pullrequestreview-2630751204

From jlu at openjdk.org  Mon Feb 24 17:55:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Feb 2025 17:55:53 GMT
Subject: <i18n dev> RFR: 8350442: Update copyright
In-Reply-To: <cneifM5QORloB6I2qGdeCy7YyOuvWh0nHz89vy1vQLs=.6105f832-76f9-4643-8e8b-4e3e3bfc988c@github.com>
References: <cneifM5QORloB6I2qGdeCy7YyOuvWh0nHz89vy1vQLs=.6105f832-76f9-4643-8e8b-4e3e3bfc988c@github.com>
Message-ID: <77yk95slb2EPGznJD3VQuLDSWx7COtUSxRXkdPxYTTM=.d40aea2b-080b-4ae0-a346-57d39c8d3544@github.com>

On Thu, 20 Feb 2025 17:01:36 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @naotoj  @coffeys @mahendrachhipa 
> 
> update of copyright years. Details on ticket.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23714#pullrequestreview-2637970531

From jwaters at openjdk.org  Tue Feb 25 08:43:00 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Feb 2025 08:43:00 GMT
Subject: <i18n dev> RFR: 8342868: Errors related to unused code on
 Windows after 8339120 in core libs [v2]
In-Reply-To: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <t7TC5dtafc-_tjEK9fvprB2ZLW38bg6L7jrcrfaw0A4=.a75619b2-9840-48be-ae17-e03d56f05eab@github.com>

On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

Keep open please

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-2681144858

From jlu at openjdk.org  Wed Feb 26 00:02:43 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 00:02:43 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
Message-ID: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>

Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.

Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 

We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override. (Which ensures `SupplementalJapaneseEraTestRun.java` passes, which also tests against building (and succeeding) with an era value of 6.

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Wed Feb 26 00:16:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Feb 2025 00:16:01 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <n8LnahndpBjJSa966XOmel-filCFfrYRi77QYysYPXw=.464a4ef8-2e9c-4dcb-b818-e95a08aed0cb@github.com>

On Tue, 25 Feb 2025 23:58:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override. (Which ensures `SupplementalJapaneseEraTestRun.java` passes, which also tests against building (and succeeding) with an era value of 6.

This appears to be a behavioral change and warrants a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23789#issuecomment-2683573479

From naoto at openjdk.org  Wed Feb 26 17:23:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Feb 2025 17:23:56 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <lbc_6-0e2mtkowoAcRSqniIfc2kbd386ZNxIXagPnHw=.e914e8d7-9b8b-4fe9-968e-74655436ef0a@github.com>

On Tue, 25 Feb 2025 23:58:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override. (Which ensures `SupplementalJapaneseEraTestRun.java` passes, which also tests against building (and succeeding) with an era value of 6.

Looks good to me. I would expect a test case with `jdk.calendar.japanese.supplemental.era` defined with something, and 7 would throw an IAE.

src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1862:

> 1860:             // BEFORE_MEIJI to be ignored during normalization
> 1861:             // We check against eras.length over Reiwa ERA due to possibility
> 1862:             // of additional eras via "jdk.calendar.japanese.supplemental.era"

The possibility is not only that emergency property, but by design Japanese calendar eras increase when the current emperor abdicates.

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

PR Review: https://git.openjdk.org/jdk/pull/23789#pullrequestreview-2645256501
PR Review Comment: https://git.openjdk.org/jdk/pull/23789#discussion_r1972020190

From jlu at openjdk.org  Wed Feb 26 18:26:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 18:26:15 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.

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

  Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23789/files
  - new: https://git.openjdk.org/jdk/pull/23789/files/f14d7c64..e55053aa

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

  Stats: 23 lines in 4 files changed: 17 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23789/head:pull/23789

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

From jlu at openjdk.org  Wed Feb 26 18:28:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 18:28:57 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <lbc_6-0e2mtkowoAcRSqniIfc2kbd386ZNxIXagPnHw=.e914e8d7-9b8b-4fe9-968e-74655436ef0a@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <lbc_6-0e2mtkowoAcRSqniIfc2kbd386ZNxIXagPnHw=.e914e8d7-9b8b-4fe9-968e-74655436ef0a@github.com>
Message-ID: <BvoA1xOqUn2kAO0HXKWlwl-V1RVh8625O4MZMJVlXQk=.72f24f12-4975-49bd-8713-30ca271ad76d@github.com>

On Wed, 26 Feb 2025 17:20:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop
>
> Looks good to me. I would expect a test case with `jdk.calendar.japanese.supplemental.era` defined with something, and 7 would throw an IAE.

@naotoj Addressed your comments in https://github.com/openjdk/jdk/pull/23789/commits/e55053aa92d735ec44844b426ebd8996eb24317f. 

@liach Filed a CSR: https://bugs.openjdk.org/browse/JDK-8350806.

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

PR Comment: https://git.openjdk.org/jdk/pull/23789#issuecomment-2685858142

From naoto at openjdk.org  Wed Feb 26 19:25:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Feb 2025 19:25:53 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>
Message-ID: <u4nBgH0AolI9bDbXo4Ez97P02eFOrZ_wUfmvmeqAlJ4=.421df13c-aebd-4413-86d5-56b6b5aa66e5@github.com>

On Wed, 26 Feb 2025 18:26:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
>> 
>> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
>> 
>> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop

test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.java line 75:

> 73:             new Calendar.Builder()
> 74:                     .setCalendarType("japanese")
> 75:                     .setFields(ERA, 7)

Sorry I suggested this immediate value "7", but this can be `JapaneseEra.values().length + 2` which might be more meaningful

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23789#discussion_r1972249833

From jlu at openjdk.org  Wed Feb 26 19:48:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 19:48:10 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v3]
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <B6UdiMgJqb1x4CiyiCV06wub7dz4kwreMy8DLZVvNA4=.23b07720-d7a9-44c2-9352-d83b45aab573@github.com>

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.

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

  Replace 7 w/ more meaningful value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23789/files
  - new: https://git.openjdk.org/jdk/pull/23789/files/e55053aa..53a2e3ff

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

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

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

From jlu at openjdk.org  Wed Feb 26 19:48:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 19:48:11 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v2]
In-Reply-To: <u4nBgH0AolI9bDbXo4Ez97P02eFOrZ_wUfmvmeqAlJ4=.421df13c-aebd-4413-86d5-56b6b5aa66e5@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <q3h949fNwUclnY6e2gCz075we3PXCqDYK8fdYOTnBWg=.168cebcf-760f-40a9-94b5-b1562c1c73b3@github.com>
 <u4nBgH0AolI9bDbXo4Ez97P02eFOrZ_wUfmvmeqAlJ4=.421df13c-aebd-4413-86d5-56b6b5aa66e5@github.com>
Message-ID: <MZoGvBGkb3bcYiRmmsFwqyfRsdUNWBMGg909WfNDtW4=.a9117982-0044-40f7-a96b-2f45a5fe9127@github.com>

On Wed, 26 Feb 2025 19:23:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto - correct comment regarding REIWA, add test case for IAE check w/ additional era via sys prop
>
> test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.java line 75:
> 
>> 73:             new Calendar.Builder()
>> 74:                     .setCalendarType("japanese")
>> 75:                     .setFields(ERA, 7)
> 
> Sorry I suggested this immediate value "7", but this can be `JapaneseEra.values().length + 2` which might be more meaningful

Agree that is better; it's pushed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23789#discussion_r1972280397

From naoto at openjdk.org  Wed Feb 26 20:03:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Feb 2025 20:03:02 GMT
Subject: <i18n dev> RFR: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException [v3]
In-Reply-To: <B6UdiMgJqb1x4CiyiCV06wub7dz4kwreMy8DLZVvNA4=.23b07720-d7a9-44c2-9352-d83b45aab573@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
 <B6UdiMgJqb1x4CiyiCV06wub7dz4kwreMy8DLZVvNA4=.23b07720-d7a9-44c2-9352-d83b45aab573@github.com>
Message-ID: <JmkTUduAFUwvAWddFui1xAjYzQqtqhMhPaHgqLuuRpE=.3a2e60ef-fd02-411f-958b-4b3b33e2bbc6@github.com>

On Wed, 26 Feb 2025 19:48:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
>> 
>> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
>> 
>> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace 7 w/ more meaningful value

Thanks. I reviewed the CSR as well.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23789#pullrequestreview-2645746475

From jlu at openjdk.org  Wed Feb 26 22:22:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Feb 2025 22:22:11 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods
Message-ID: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>

Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.

Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Thu Feb 27 16:40:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Feb 2025 16:40:53 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods
In-Reply-To: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
Message-ID: <byn0BzdA2CC9kefFDrk3CdXpcCjkQIYxX9999LJ6pOk=.0524f24a-f764-438d-a6d9-1d27b5443516@github.com>

On Wed, 26 Feb 2025 22:18:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

src/java.base/share/classes/java/text/NumberFormat.java line 889:

> 887:      * formatting and parsing. For example, in the English locale, with grouping on,
> 888:      * the number 1234567 might be formatted as "1,234,567". For the same format
> 889:      * with grouping off, the String "1,234,567" might be parsed as 1.

Although you used `might`, it may be helpful to mention the leniency here. I think it will throw exception in the strict mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1973958774

From jlu at openjdk.org  Thu Feb 27 18:08:35 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 18:08:35 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods [v2]
In-Reply-To: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
Message-ID: <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

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

  Naoto review - include strict parsing example. Also remove 'might' wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23813/files
  - new: https://git.openjdk.org/jdk/pull/23813/files/4f067f79..8c4ff2eb

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

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

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

From jlu at openjdk.org  Thu Feb 27 18:08:36 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 18:08:36 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods [v2]
In-Reply-To: <byn0BzdA2CC9kefFDrk3CdXpcCjkQIYxX9999LJ6pOk=.0524f24a-f764-438d-a6d9-1d27b5443516@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <byn0BzdA2CC9kefFDrk3CdXpcCjkQIYxX9999LJ6pOk=.0524f24a-f764-438d-a6d9-1d27b5443516@github.com>
Message-ID: <TcB4CRRTh0uRUqgUTxO_5hdlec2Zn8UP-BrqBuOGCX4=.9111bd50-06a4-44d9-bf0c-cbca5ee53ca2@github.com>

On Thu, 27 Feb 2025 16:37:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto review - include strict parsing example. Also remove 'might' wording
>
> src/java.base/share/classes/java/text/NumberFormat.java line 889:
> 
>> 887:      * formatting and parsing. For example, in the English locale, with grouping on,
>> 888:      * the number 1234567 might be formatted as "1,234,567". For the same format
>> 889:      * with grouping off, the String "1,234,567" might be parsed as 1.
> 
> Although you used `might`, it may be helpful to mention the leniency here. I think it will throw exception in the strict mode.

I originally included a strict behavior example as well but reverted it because the default behavior for NumberFormat does not support strict/non-strict. But I think we can include it as long as the wording is careful.

For the formatting example, I inferred that the "might" wording was regarding that there is no guarantee (however unlikely) that `,` remains the grouping separator and a size of 3 for the English locale. That's why I included that wording in the (previous) parsing example.

I changed the wording so that we can remove the ambiguous "might" wording. https://github.com/openjdk/jdk/pull/23813/commits/8c4ff2eb8c1746b524b661f37296cea6586161d9 contains these updates.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1974098707

From naoto at openjdk.org  Thu Feb 27 19:42:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Feb 2025 19:42:56 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods [v2]
In-Reply-To: <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>
Message-ID: <eGssGU8zVetL6RF1bX-H50AusIo-UCnML-l8CS-tux0=.01a73266-841e-4ade-bedc-0d6b377f09fc@github.com>

On Thu, 27 Feb 2025 18:08:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
>> 
>> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto review - include strict parsing example. Also remove 'might' wording

src/java.base/share/classes/java/text/NumberFormat.java line 896:

> 894:      *   <li> Parsing {@code "1,234,567"} with grouping off and an implementation that
> 895:      *        implements strict parsing with {@link #isStrict()} returning {@code true}
> 896:      *        throws {@code ParseException}

Sorry for the nit, but I think "an implementation that implements strict parsing" can safely be removed without changing the context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1974233971

From jlu at openjdk.org  Thu Feb 27 19:52:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 19:52:13 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods [v3]
In-Reply-To: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
Message-ID: <kDNySBaxIMOtEucLyIuL38UamV8WxYqHvJ6h5O7bZKw=.e419a0f8-1991-4891-a952-2e2527a7e6d2@github.com>

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

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

  make strict example less wordy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23813/files
  - new: https://git.openjdk.org/jdk/pull/23813/files/8c4ff2eb..f36ec09d

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

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

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

From jlu at openjdk.org  Thu Feb 27 19:52:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Feb 2025 19:52:13 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods [v2]
In-Reply-To: <eGssGU8zVetL6RF1bX-H50AusIo-UCnML-l8CS-tux0=.01a73266-841e-4ade-bedc-0d6b377f09fc@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <ZiYza2xy8-y2i4woI1b5MjYVwUggTuquy-Ub6zK1oVU=.f7b02b65-266d-4cf4-97c5-b4d0a910d965@github.com>
 <eGssGU8zVetL6RF1bX-H50AusIo-UCnML-l8CS-tux0=.01a73266-841e-4ade-bedc-0d6b377f09fc@github.com>
Message-ID: <f7CB8wT97YIDl0VGLCOjiyUk9iDmEt_2Vmp6puN7oqc=.eee59c52-c4d6-4d06-8427-5914d169f967@github.com>

On Thu, 27 Feb 2025 19:39:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Naoto review - include strict parsing example. Also remove 'might' wording
>
> src/java.base/share/classes/java/text/NumberFormat.java line 896:
> 
>> 894:      *   <li> Parsing {@code "1,234,567"} with grouping off and an implementation that
>> 895:      *        implements strict parsing with {@link #isStrict()} returning {@code true}
>> 896:      *        throws {@code ParseException}
> 
> Sorry for the nit, but I think "an implementation that implements strict parsing" can safely be removed without changing the context.

Yeah, it was a little wordy. Was worried users may not be aware that those `set/isStrict` methods need to be implemented, but the link is right there to `isStrict`, which makes it apparent they throw `UOE` by default. Shortened in https://github.com/openjdk/jdk/pull/23813/commits/f36ec09dd73ef2e88a87fa52658eb751072ed758.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23813#discussion_r1974246647

From naoto at openjdk.org  Fri Feb 28 17:50:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Feb 2025 17:50:54 GMT
Subject: <i18n dev> RFR: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods [v3]
In-Reply-To: <kDNySBaxIMOtEucLyIuL38UamV8WxYqHvJ6h5O7bZKw=.e419a0f8-1991-4891-a952-2e2527a7e6d2@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
 <kDNySBaxIMOtEucLyIuL38UamV8WxYqHvJ6h5O7bZKw=.e419a0f8-1991-4891-a952-2e2527a7e6d2@github.com>
Message-ID: <XdHtt8At46bgZswWJNoheaMngB93mM9eeQ5yjPEfyKw=.311ab2fa-75f5-4efa-9f4b-556764bcb229@github.com>

On Thu, 27 Feb 2025 19:52:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
>> 
>> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make strict example less wordy

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23813#pullrequestreview-2651436794

From jlu at openjdk.org  Fri Feb 28 19:39:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Feb 2025 19:39:59 GMT
Subject: <i18n dev> Integrated: 8350646: Calendar.Builder.build() Throws
 ArrayIndexOutOfBoundsException
In-Reply-To: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
References: <ZTMczL7n-2PBA3OnCiInXgaHSIbN54lpe1wcpgrXPiA=.1306537d-2297-4497-b09b-46990f464766@github.com>
Message-ID: <QxIiTi1qVanUkCzIYx0Jcv3e1x7DkaviVM3lYvfzXlY=.793ac4ca-1fb1-44b7-8b8b-d9481dc511af@github.com>

On Tue, 25 Feb 2025 23:58:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which prevents an `AIOOBE` from leaking out when `java.util.Calendar.Builder` is used to build a Japanese calendar with an era value too large.
> 
> Note that we don't check under `BEFORE_MEIJI`/0 as historically Japanese calendar ignores negative values during normalization. See `JapaneseImperialCalendar` L2018: `date.setEra(era > 0 ? eras[era] : null);`. 
> 
> We also check against `eras.length` over `REIWA`/5 due to the possibility of additional eras via the property override or future eras in general.

This pull request has now been integrated.

Changeset: 3a7d9868
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a7d98687849ba0625fed2b516f4103ee8d27e41
Stats:     36 lines in 4 files changed: 30 ins; 0 del; 6 mod

8350646: Calendar.Builder.build() Throws ArrayIndexOutOfBoundsException

Reviewed-by: naoto

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

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