JDK 25.0.2 base repository

Tue Dec 16 13:32:25 UTC 2025

Hi,

I just read the thread and agree that the current status of jdk25u is not nice. However, in the Oracle maintained releases, you can never be sure that the tip of the jdk<nn>u release is at the level of the yet to release update.

For instance, at the time JDK 25.0.1 was branched (and not yet delivered), e.g. in September time, there have already been a lot of changes of JDK 25.0.2 as well in the jdk25u master branch.

And, Aleksey, regarding the commits that you cited which would be in the jdk-25.0.2 to be released, it's also not completely correct. The last commit that was merged into Oracle's tree that is the basis for the upcoming January release is likely this one:
https://github.com/openjdk/jdk25u/commit/89c5659aa88acd1e9624aa14e5b9757255e55916
https://bugs.openjdk.org/browse/JDK-8366694
If you look at the JBS bug, you see that it is in build 5 and the backport item was resolved on 31st of October which is the date of the comment.

The next commit from 13th of November is this one:
https://github.com/openjdk/jdk25u/commit/44ca0caba38e30eae6de4e3a571192f48c567dad
https://bugs.openjdk.org/browse/JDK-8370465
This one was initially marked in a backport item for 25.0.3. Some time later, a backport to 25.0.2 appeared (resolved on 18th of November), so Oracle very likely cherry-picked this into their branch for the 25.0.2 release (it is marked as build 7).

This probably applies to all commits until the one that you cited (https://github.com/openjdk/jdk25u/commit/8fd9a739c895d7f0f860a8170d22cb50574abc79). However, if you want to be sure, you need to check each item in JBS whether it went into the release.

Generally, a downstream vendor who wants to test an Oracle maintained release from the jdk<nn>u repository always has to find the tag that he would need to base his work on. And to be able to know more about the bits that are actually in the release, they need to take part in the vulnerability group where the exact bundle is shared in advance.

So, I really oppose to changing anything on the jdk25u repository now although I suggest to start the next time when the community takes over an LTS release (e.g. 29.0.3) to wait for a jdk25u-dev repository (or branch) before allowing further backports.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.org> On Behalf Of
> Shipilev, Aleksey
> Sent: Dienstag, 16. Dezember 2025 11:19
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.org
> Subject: Re: JDK 25.0.2 base repository
> 
> 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