JDK 25.0.2 base repository

[Shipilev, Aleksey]

On 15.12.25, 17:16, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com>> wrote:
> Maybe we could do that rollback, but it would not be really nice.
> But is this really necessary? We don't need that for our process.

It is not necessary, but it saves friction in downstream releases and/or critical 25.0.2 fixes. We can certainly deal with it in downstreams.

Consider the case you need a critical backport to 25.0.2 now. It goes to Rob's private stash, correct? Because if you open the PR against jdk25u, it would go to 25.0.3. It is inconvenient that you cannot be automatically sure that the patch applies cleanly and tests well in 25.0.2, because you need to actually care to fork it off the last pre-25.0.3 commit, *and* hope there are no interfering changes somewhere in outside-the-repo stash. So that's not great.

Consider the case of downstream wanting to put a downstream-specific fix into 25.0.2 in its downstream fork of jdk25u. Oops, its HEAD is already at 25.0.3, dang. (This is how I found it in Corretto...) The jdk25u / jdk25u-dev split is great in the sense that downstreams can cleanly track what is the base for the upcoming release. Its HEAD tracks it more or less cleanly, and we just anticipate that at the release date some HEAD commit there would be tagged as jdk-XXX-ga. Nice and clean.

> How do you deal with *.0.1? Is that different from now in any way? Less hassle?

Yes, *.0.1 is a hassle in the sense there is no convenient reference point what is *.0.1. We grumble, but deal with it, eagerly awaiting the clean repo split. The jdkXXXu and jdkXXXu-dev split is much less hassle, because their respective HEADs are always the latest state of N-th and (N+1)-th quarterly release. It is just surprising that jdk25u got into inconvenient spot that the repo split was preventing to happen in all previous years.

Sure, you can (and should) release off the real tags. Then again, I suspect some pipeline somewhere relies on assumption that HEAD in jdk25u is the current quarterly release. OTOH, the current jdk25u 25.0.3 "leakage" is not terrible, as most of the fixes are test/infra issues. And arguably you want some of those product fixes earlier. See below. So a pragmatic choice might be tagging some current commits in jdk25u with jdk-25.0.2+$buildnumber to clearly show where the tip of 25.0.2 is. Plus, avoid accepting (N+1)-th changes in jdkXXXu after the split for the next LTS :)

$ shipilev-jdk25u % git log --oneline jdk-25.0.3+0..HEAD

== Product changes:
 d306ab95729 8372753: jpackage ignores --file-associations option with predefined app image
 2ed77bee88c 8361381: GlyphLayout behavior differs on JDK 11+ compared to JDK 8
 ddc7a00d880 8359472: JVM crashes when attaching a dynamic agent before JVMTI_PHASE_LIVE 
 fc2f115d2d8 8367901: Calendar.roll(hour, 24) returns wrong result
 96dc209747e 8368328: CompactNumberFormat.clone does not produce independent instances
 96906db79bc 8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 5e639f4fe36 8368882: NPE during text drawing on machine with JP locale
 5c9150ff62e 8370242: JFR: Clear event reference eagerly when using EventStream

== Testbugs:
 cdbdbdce40b 8370649: Add intermittent tag for gc/shenandoah/generational/TestOldGrowthTriggers.java
 5de7202c15a 8359418: Test "javax/swing/text/GlyphView/bug4188841.java" failed because the phrase of text pane does not match the instructions
 278e244d2c8 8366128: jdk/jdk/nio/zipfs/TestPosix.java::testJarFile uses wrong file
 22cc0d69898 8366908: Use a different class for testing JDK-8351654
 e221f1c2d08 8346962: Test CRLReadTimeout.java fails with -Xcomp on a fastdebug build
 a17bc10493a 8349192: jvmti/scenarios/contention/TC05/tc05t001 fails: ERROR: tc05t001.cpp, 281: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)
 2fbf15a40cc 8341039: compiler/cha/TypeProfileFinalMethod.java fails with assertEquals expected: 0 but was: 2
 c56ad415318 8313770: jdk/internal/platform/docker/TestSystemMetrics.java fails on Ubuntu
 f464f7714ba 8366951: Test runtime/logging/StressAsyncUL.java is timing out
 76c3e1d26c1 7191877: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently
 14493a40b8a 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues
 bbd99cbfc12 8343340: Swapping checking do not work for MetricsMemoryTester failcount
 22af1754901 8369032: Add test to ensure serialized ICC_Profile stores only necessary optional data
 da10b6d84be 8371697: test/jdk/java/nio/file/FileStore/Basic.java fails after 8360887 on linux
 95f4bc9b6e9 8368982: Test sun/security/tools/jarsigner/EC.java completed and timed out

== Infra:
 796f2b42b07 8371425: Include folder names in vscode workspace virtual folders
 6a410a8a1a5 8372320: Bump update version for OpenJDK: jdk-25.0.3

Thanks,
-Aleksey




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597