8272194: java.sql.Date::toLocalDate() broken for dates before 1 A.D. by Sholto · Pull Request #31808 · openjdk/jdk

Sholto · 2026-07-07T12:07:37Z

Also covers: 8249280

I will first give a quick summary of the problem.
Put simply, the LocalDate form of the java.sql.Date is derived using the getYear method of java.util.Date. This in turn returns the year of the normalised internal calendar.
However, the internal calendar getYear has an extra layer of complexity.
The calendar has an additional era field, which captures BC/AD.
getYear therefore just returns the year of that era.
For example, the year 6BC and the year 6AD both return getYear as 6.

This means that for BC dates, our LocalDate conversion loses the sign of the year.

This leads to additional problems down the line, as the year 1BC is for calculations sake is considered to be year 0 (and 2BC us considered year -1 and so on). As a result, the various leap year calculations are WRONG for these years, causing year format validation failures in situations like marshalling/unmarshalling the dates with a DB.

There are two seemingly obvious fixes here, however I will attempt to explain why I did not proceed with them.

Firstly, it seems sensible is to derive the LocalDate from an Instant created from the millisecond representation of the Date. After all, why we are having to use the deprecated getYear, getMonth and getDay methods anyway?
The answer lies in 8061577.
The underlying millisecond representation between java.time.Instant and java.util.Date is fundamentally different. Read that ticket for a greater explanation.
Ultimately though, it means that the for older dates, the only real way to bridge between the two calendar systems is to use these year/month/day methods.

This is where the second possible solution appears.
The underlying calendar representation that java.util.Date uses actually does have a year method which gives you the correctly signed year, that being getNormalizedYear.
In fact, java.util.Date uses the setter counterpart setNormalizedYear is its setYear method.
Given this, it seems natural that getYear should similarly call getNormalizedYear.
I think this would be my ideal solution, however I recognise that getYear only returning a positive year is very long standing behaviour. Given how widely spread java.util.Date is, I felt it was perhaps better not to rock the boat too much.

I have therefore taken the decision to add an equivalent getNormalizedYear method to java.util.Date.
This is the simplest way to expose the real inner year of the date to java.sql.Date and java.sql.Timestamp.
This fixes the negative year issue in the LocalDate conversion in an incredibly low impact way, and without altering long standing java.util.Date behaviour.
I chose to make the method protected to prevent unwanted consumption of the method. However, I did not make it Deprecated like the other accessor methods which perhaps I should have done.

Let me know what you think.

I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Warning

⚠️ Found trailing period in issue title for 8272194: java.sql.Date::toLocalDate() broken for dates before 1 A.D.

Issue

JDK-8272194: java.sql.Date::toLocalDate() broken for dates before 1 A.D. (Bug - P4)

Reviewers

Naoto Sato (@naotoj - Reviewer) 🔄 Re-review required (review applies to f65fe929)
Justin Lu (@justin-curtis-lu - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/31808/head:pull/31808
$ git checkout pull/31808

Update a local copy of the PR:
$ git checkout pull/31808
$ git pull https://git.openjdk.org/jdk.git pull/31808/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31808

View PR using the GUI difftool:
$ git pr show -t 31808

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/31808.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2026-07-07T12:09:43Z

👋 Welcome back Sholto! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2026-07-07T12:10:21Z

@Sholto This change is no longer ready for integration - check the PR body for details.

openjdk · 2026-07-07T12:11:20Z

@Sholto The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2026-07-07T12:18:43Z

Webrevs

naotoj · 2026-07-08T22:08:26Z

Hi,

I am not sure that adding a protected method to java.util.Date is the right approach. Since Date is extensible, an existing subclass may already declare a getNormalizedYear() method. With this change, that method would unintentionally override the new method and could change the behavior of toLocalDate() or toLocalDateTime().
Instead, I would suggest creating a GregorianCalendar initialized from the Date and deriving the proleptic year from its ERA and YEAR fields (BC = 1 - YEAR). This would avoid adding a new overrideable API to Date.

…e/LocalDateTime from calendar It was decided that adding a new protected method to java.util.Date isn’t the safest thing to do as it is a widely extended class. The new method could unintentionally break the java.time conversion for these classes. The conversion still cannot by using Instant due to the difference between the milli representations as stated in 8061577. Therefore, constructing a new GregorianCalendar is the next best way to get the correct year/month/day values.

Sholto · 2026-07-09T12:12:15Z

Hi,

I am not sure that adding a protected method to java.util.Date is the right approach. Since Date is extensible, an existing subclass may already declare a getNormalizedYear() method. With this change, that method would unintentionally override the new method and could change the behavior of toLocalDate() or toLocalDateTime(). Instead, I would suggest creating a GregorianCalendar initialized from the Date and deriving the proleptic year from its ERA and YEAR fields (BC = 1 - YEAR). This would avoid adding a new overrideable API to Date.

@naotoj Understood. I have gone with the GregorianCalendar approach as recommended. I just want to double check that there aren't any possible timezone issues when constructing the calendar?

naotoj · 2026-07-09T20:54:11Z

@naotoj Understood. I have gone with the GregorianCalendar approach as recommended. I just want to double check that there aren't any possible timezone issues when constructing the calendar?

I now think this approach would be significantly slower, although it would still handle the situation correctly, as it creates GregorianCalendar each time the method is called (time zone is not an issue here). Accessing the internal calendar via shared secrets might be possible, but I am not sure that is the right approach either.

justin-curtis-lu · 2026-07-09T23:41:25Z

Regardless of the workaround, we could use the result of getTime() as a fast-path for dates after the Unix epoch. This would retain mostly the same performance as the original code for those modern dates. Of course we are still looking at a slow down for all other dates before, but that may be unavoidable to figure out the era.

…rsion

Sholto · 2026-07-10T12:52:29Z

I did some benchmarking and the GregorianCalendar implementation is noticeably slower. On my machine it was 29x slower.
I have implemented the faster codepath as suggested by @justin-curtis-lu as I agree that it will speed up the conversion for an overwhelming majority of use cases.

We could potentially expand the number of dates covered by this faster codepath by using a negative unix time representing a much earlier year.
However, I feel slightly uneasy by this as it is almost pushing towards trying to check getTime directly to see if it is in BC time.

naotoj

We could potentially expand the number of dates covered by this faster codepath by using a negative unix time representing a much earlier year.

I think we can push the check close to the BC/AD switch, as we should account for local-time offset.

naotoj · 2026-07-10T17:54:23Z

+            // Ajdust the BC date into a negative astronomical date.
+            // As there is no year 0 in the proleptic Gregorian calendar
+            // we also have to adjust the BC year by 1.
+            // 1 BC becomes year 0, 2 BC becomes year -1 and so on.


I think you meant GregorianCalendar rather than "proleptic Gregorian calendar" here? GregorianCalendar has no year zero, whereas the ISO proleptic-year numbering used by LocalDate does. Also, there is a typo: "Ajdust" should be "Adjust".

Thank you for spotting those. I have fixed the comments as recommended.

naotoj · 2026-07-10T18:02:18Z

+            year = 1 - calendar.get(Calendar.YEAR);
+        } else {
+            year = calendar.get(Calendar.YEAR);
+        }
+        return LocalDate.of(year, calendar.get(Calendar.MONTH) + 1, calendar.get(Calendar.DAY_OF_MONTH));


The values of these fields should continue to be obtained by calling getYear(), getMonth(), and getDate(), rather than from the calendar instance. Otherwise, if a subclass overrides any of these methods, the override would be ignored.

Updated as suggested. I have done this on Timestamp as well.

justin-curtis-lu · 2026-07-10T20:31:07Z

+        // that we would ideally avoid if possible.
+        // Given that we can comfortably state that any dates after the unix epoch
+        // are AD, we can use a much faster local date time derivation for these dates.
+        if (getTime() >= 0) {


We could potentially expand the number of dates covered by this faster codepath by using a negative unix time representing a much earlier year.

That's a good idea. I agree that representing some negative time with a magic number is not as straightforward as 0, but considering we can retain almost the same performance for an extra ~1970 years, I think it is a worthwhile tradeoff. Granted we provide a big enough buffer to account for an arbitrary time zone offset, and the value is documented properly.

That would pretty much make only the BC years suffer the slowdown, which seems extremely justifiable since those are exactly the cases where the behavior was incorrect.

I have pushed this date back to 0002-01-01. While overkill, I think that doing an entire year offset is cleaner than doing something like 0001-01-03 which would yield the same result but wouldn't give us as comfortable a distance from possible timezone problems.
I have also just gone with directly using the millis in a constant rather than deriving them from a calendar and converting it into millis in a static initialiser.
However, I am happy to change to that approach if you think it is clearer.

I think the wide cushion is right. SimpleTimeZone can be created with offset up to Integer.MAX_VALUE offset in miliseconds, which gets up to ~25 days, so even a few day buffer would not be enough.

justin-curtis-lu · 2026-07-10T20:35:35Z

Since there is good traction on this PR, I think you can go ahead and update the copyright years for any files that need it. Also, since these tests don't have individual Jtreg headers, I think it is worth including the JBS bug ID 8272194 in the test comments to better associate the change with the test.

Done as suggested.

justin-curtis-lu · 2026-07-10T20:37:38Z

+        LocalDate ld1 = LocalDate.of(-4, 1, 1);
+        Date d1 = Date.valueOf(ld1);
+        LocalDate ld2 = d1.toLocalDate();
+        assertTrue(ld1.equals(ld2), "Error ld1 != ld2");


You might use assertEquals here and in the other occurrences as a more accurate assertion. Perhaps also update the error message to make it clear that the failed assertion is about negative years.

Done. I have also improved the test adding more coverage and improving the error messages.
I have also moved away from the negative year nomenclature as that obfuscates year 0 (1BC).
I have added tests to ensure we are checking this year 0 case as well, as it is an obvious possible boundary condition.

…ocalDateTime conversion

…mp to 2026

…e conversion

…ateTime conversion

naotoj · 2026-07-13T17:48:50Z

            year = 1 - calendar.get(Calendar.YEAR);
        } else {
            year = calendar.get(Calendar.YEAR);


getYear() is still bypassed on this path. The calendar should only be used to determine the era. The year value should continue to be obtained through getYear().

Changed as suggested.

Can I just double check, do you think that we should be using getYear() for the BC path as well?

Yes, I believe year should always be derived from getYear().

Cool I have made that changed. I have also moved away from the if-else block to only a BC if block. This brings the logic inline with how it is done in the GregorianCalendar class.

I realise that with always using getYear() we could also create a faster code path for BC dates by also adding a year 2 BC epoch millisecond and checking if getTime() is less than that. That way we only do the calendar check for the narrow band of dates we cannot be certain are BC or AD. However, I recognise this is an extra optimisation which few consumers would benefit from.

Yes, getYear() should always be called, regardless of the era. Otherwise, this would introduce a behavioral change. BC dates could also use the fast path, but the added benefit is limited and likely not worth doubling the complexity.

naotoj · 2026-07-13T23:01:32Z

+        List<LocalDateTime> bcLocalDateTimes = List.of(
+            LocalDateTime.of(0, 1, 1, 0, 0, 0, 0),
+            LocalDateTime.of(-4, 9, 8, 23, 11, 59, 999_999_999),
+            LocalDateTime.of(-1000, 3, 22, 8, 30, 20, 0)
+        );


Could you make this a JUnit parameterized test, using @ParameterizedTest, rather than iterating over a List? Please also add dates/date-times immediately around the cutoff to verify the conversion there, particularly that values at or after the cutoff are AD, even with the possible negative offset?

I have made the tests @ParameterizedTest

I have also added tests to check the dates around our BC check threshold.

naotoj · 2026-07-13T23:06:41Z

+            assertEquals(bcTimestamp.toLocalDateTime(), bcLocalDateTime, "The LocalDateTime created from the Timestamp does not match the original BC LocalDateTime.");
+            assertEquals(Timestamp.valueOf(bcTimestamp.toLocalDateTime()), bcTimestamp, "The BC Timestamp did not yield the expected result on a round trip Timestamp / LocalDateTime conversion.");


The expected and actual arguments to assertEquals appear to be reversed.

I have fixed this while making the @ParameterizedTest change.

…e/LocalDateTime conversion

…onversion parameterized

openjdk · 2026-07-14T09:28:39Z

@Sholto Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

…conversion parameterized

…eTime conversion

justin-curtis-lu

Thanks for your changes so far. These are the only remaining issues I spotted.

justin-curtis-lu · 2026-07-14T20:30:44Z

                                getMinutes(),
                                getSeconds(),
-                                getNanos());
+                                getNanos()); // We have to use nanos here as the calendar does not support nano precision


This comment is stale and can be removed.

Good spotting. I've removed that now.

justin-curtis-lu · 2026-07-14T20:36:30Z

+     * Validate that Date.valueOf and Date.toLocalDate yield the expected results for dates with BC years.
+     * Ensures that the fix for 8272194 has not regressed.
+     */
+    @ParameterizedTest(autoCloseArguments = false)


I understand you are following the existing test convention, but I would remove the autoCloseArguments = false here and in the other occurrences since the parameter does not implement AutoCloseable, so it's just noise. (It is added to those other tests even though not needed as part of an earlier migration to conservatively match TestNG semantics.)

That is good to know. I have removed them from the tests I have added, but I have left the existing uses alone.

…lDateTime conversion tests

justin-curtis-lu

The latest changes look good to me. But please also let @naotoj finish taking a look as well.

justin-curtis-lu · 2026-07-15T16:24:16Z

/reviewers 2

openjdk · 2026-07-15T16:26:29Z

@justin-curtis-lu
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

naotoj

Looks good to me too. Thank you @Sholto for fixing it!

Sholto · 2026-07-16T11:27:14Z

Looks good to me too. Thank you @Sholto for fixing it!

Excellent. I am just wondering, what is the next step of the process?

justin-curtis-lu

After the PR is approved, we generally wait around 24-hours and if there are no further comments, the author can comment /integrate to proceed with integrating the pull request. After which, one of us can sponsor the change.

But before you do that, a few final suggestions =). Following some offline discussion, we think that the core logic is in good shape, but there is opportunity to reduce some duplication. Please see the other comments I left.

justin-curtis-lu · 2026-07-16T18:45:11Z

+     * timezone offset, it gives us a comfortable distance while still
+     * providing a faster code path for almost 1970 years.
+     */
+    private static final long TWO_AD_AT_UTC_EPOCH_MILLIS = -62104233600000L;


We can make this package-private and have Timestamp use it as well to reduce some duplication.

I've left this private as Timestamp no longer needs this constant as it is directly using the new Date.toProlepticYear.

justin-curtis-lu · 2026-07-16T18:55:21Z

+        // Given that we can comfortably state that any dates on or after
+        // 0002-01-01 are AD, we can use a much faster local date derivation
+        // for these dates.
+        if (getTime() >= TWO_AD_AT_UTC_EPOCH_MILLIS) {


We can pull out the shared logic here and in Timestamp and create a static package-private helper in java.sql.Date.

Something like

static int toProlepticYear(long millis, int year) { if slow path set calendar using setTimeInMillis if calendar is in BC adjust year return year; }

The helper can call GregorianCalendar.setTimeInMillis(...) instead of GregorianCalendar.setTime(...). That lets us pass its millisecond value via getTime() rather than having to pass this as a java.util.Date to the helper method. I also think within the helper, you can inverse the getTime() >= TWO_AD_AT_UTC_EPOCH_MILLIS conditional to simplify the logic some more.

After that, toLocalDate need only look something like,

return LocalDate.of( toProlepticYear(getTime(), getYear() + 1900), getMonth() + 1, getDate());

Yup great idea. I have updated this as suggested.

Did we want unit tests specifically for the new toProlepticYear method? Or are we happy with the coverage provided by the existing dateTimesAroundBcCheckThreshold checks?

I also just wanted to confirm if toProlepticYear is the correct nomenclature.

Thanks for your update, it looks good to me. I'll run your change on our CI.

Did we want unit tests specifically for the new toProlepticYear method?

I don't think we need white-box tests for the helper method, the existing public API tests are sufficient.

I also just wanted to confirm if toProlepticYear is the correct nomenclature.

I think this name is correct. We are taking the Gregorian era and year and convert it to the ISO proleptic year. That is how the converted java.time classes refer to the year.

https://docs.oracle.com/en/java/javase/26/docs//api/java.base/java/time/LocalDate.html#getYear()
https://docs.oracle.com/en/java/javase/26/docs//api/java.base/java/time/LocalDateTime.html#getYear()

I think this name is correct. We are taking the Gregorian era and year and convert it to the ISO proleptic year. That is how the converted java.time classes refer to the year.

Okay, scratch that.

We are just deriving the java.time value from the date's values for year, month, etc. Technically, the conversion to the ISO calendar system is not exact, since GregorianCalendar is a hybrid Julian-Gregorian calendar.

We might better name it as toGregorianProlepticYear, which only indicates that the year and era are used to derive a Gregorian proleptic year (and not an exact ISO date conversion).

Ok I've renamed that as suggested.

…lDate/LocalDateTime conversions

…ql.Date

Sholto added 2 commits July 7, 2026 12:02

8272194: fix negative year handling for Date.toLocalDate

68cd2bd

8272194: fix negative year handling for Timestamp.toLocalDateTime

ac5f59d

openjdk Bot added the core-libs core-libs-dev@openjdk.org label Jul 7, 2026

openjdk Bot added the rfr Pull request is ready for review label Jul 7, 2026

Sholto changed the title ~~8272194: java.sql.Date::toLocalDate() broken for dates before 1 A.D.~~ 8272194: java.sql.Date::toLocalDate() broken for dates before 1 A.D Jul 8, 2026

openjdk Bot changed the title ~~8272194: java.sql.Date::toLocalDate() broken for dates before 1 A.D~~ 8272194: java.sql.Date::toLocalDate() broken for dates before 1 A.D. Jul 8, 2026

8272194: introduce faster code path for LocalDate/LocalDateTime conve…

745c717

…rsion

naotoj reviewed Jul 10, 2026

View reviewed changes

justin-curtis-lu reviewed Jul 10, 2026

View reviewed changes

Sholto added 5 commits July 13, 2026 11:05

8272194: fix bad comments in LocalDate/LocalDateTime conversion

e770a68

8272194: only use created calendar for year derivation in LocalDate/L…

5f14d14

…ocalDateTime conversion

8272194: update copyright year for java.sql.Date and java.sql.Timesta…

12d0e55

…mp to 2026

8272194: improve unit tests for Date/Timestamp LocalDate/LocalDateTim…

5023667

…e conversion

8272194: expand dates covered by faster code path in LocalDate/LocalD…

2dca69c

…ateTime conversion

Sholto requested review from justin-curtis-lu and naotoj July 13, 2026 12:06

naotoj reviewed Jul 13, 2026

View reviewed changes

Sholto added 2 commits July 14, 2026 10:22

8272194: only use created calendar for BC year derivation in LocalDat…

db987c5

…e/LocalDateTime conversion

8272194: make unit tests for Date/Timestamp LocalDate/LocalDateTime c…

8cddb2c

…onversion parameterized

Sholto force-pushed the jdk-8272194 branch from 2050353 to 8cddb2c Compare July 14, 2026 09:27

8272194: test cutoff dates in Date/Timestamp LocalDate/LocalDateTime …

6cbc037

…conversion parameterized

Sholto requested a review from naotoj July 14, 2026 09:44

8272194: only use created calendar for BC check in LocalDate/LocalDat…

99b9139

…eTime conversion

justin-curtis-lu reviewed Jul 14, 2026

View reviewed changes

Sholto added 2 commits July 14, 2026 23:17

8272194: remove outdated comment in Timestamp LocalDateTime conversion

c2c328a

8272194: remove autoCloseArguments from Date/Timestamp LocalDate/Loca…

f65fe92

…lDateTime conversion tests

Sholto requested a review from justin-curtis-lu July 14, 2026 22:21

justin-curtis-lu approved these changes Jul 15, 2026

View reviewed changes

openjdk Bot added the ready Pull request is ready to be integrated label Jul 15, 2026

openjdk Bot removed the ready Pull request is ready to be integrated label Jul 15, 2026

naotoj approved these changes Jul 15, 2026

View reviewed changes

openjdk Bot added the ready Pull request is ready to be integrated label Jul 15, 2026

justin-curtis-lu suggested changes Jul 16, 2026

View reviewed changes

openjdk Bot removed the ready Pull request is ready to be integrated label Jul 16, 2026

8272194: consolidate date proleptic year conversion and simplify Loca…

da229d0

…lDate/LocalDateTime conversions

Sholto requested a review from justin-curtis-lu July 17, 2026 11:46

justin-curtis-lu approved these changes Jul 17, 2026

View reviewed changes

8272194: rename toProlepticYear -> toGregorianProlepticYear in java.s…

60cc9a2

…ql.Date

justin-curtis-lu approved these changes Jul 17, 2026

View reviewed changes

		assertEquals(bcTimestamp.toLocalDateTime(), bcLocalDateTime, "The LocalDateTime created from the Timestamp does not match the original BC LocalDateTime.");
		assertEquals(Timestamp.valueOf(bcTimestamp.toLocalDateTime()), bcTimestamp, "The BC Timestamp did not yield the expected result on a round trip Timestamp / LocalDateTime conversion.");

Uh oh!

Conversation

Sholto commented Jul 7, 2026 • edited by openjdk Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Warning

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper Bot commented Jul 7, 2026

Uh oh!

openjdk Bot commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk Bot commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge Bot commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

naotoj commented Jul 8, 2026

Uh oh!

Sholto commented Jul 9, 2026

Uh oh!

naotoj commented Jul 9, 2026

Uh oh!

justin-curtis-lu commented Jul 9, 2026

Uh oh!

Sholto commented Jul 10, 2026

Uh oh!

naotoj left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sholto Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

naotoj Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sholto Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Sholto commented Jul 7, 2026 •

edited by openjdk Bot

Loading

openjdk Bot commented Jul 7, 2026 •

edited

Loading

openjdk Bot commented Jul 7, 2026 •

edited

Loading

mlbridge Bot commented Jul 7, 2026 •

edited

Loading

Sholto Jul 14, 2026 •

edited

Loading

naotoj Jul 13, 2026 •

edited

Loading

Sholto Jul 14, 2026 •

edited

Loading