JDK 25.0.2 base repository

[Shipilev, Aleksey]

On 16.12.25, 14:33, "Langer, Christoph" <christoph.langer at sap.com <mailto:christoph.langer at sap.com>> wrote:
> 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 [...] This probably applies to all commits until the one that you cited [...] However, if you want to be sure, you need to check each item in JBS whether it went into the release.

I only mentioned the commits that would appear in downstream build *in addition* to what would actually ship in normal 25.0.2 release, in case a vendor decides to build/test from jdk25u, (mistakenly) thinking it is only 25.0.2. Only to discover near the GA date that there is a difference beyond security patches. I cross-checked all issues from my "product fixes" list, and all of them are 25.0.3 only in JBS. That list calms me down a bit, actually, because there seem to be nothing on product side that would cause myself to say "Oh wait, oh no, this should wait for 25.0.3; also it does not readily invalidate 25.0.2 testing". 

But I think you as maintainers might also need to look at it carefully and decide that the risk -- if anything like that actually happens -- is low.

> 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.

I understand the bit about the security patches: they would have to stay in private repository until embargo date expires. At the same time, I do believe that the bulk of the release contents (regular backports) should be done in clearly demarcated public repositories. And we already have that in community-maintained releases: current split between jdk25u and jdk25u-dev does that nicely for us. We should just stick to the rule that no release "N" backports happen in jdkXXXu until we start stabilizing for that release "N". That looks completely doable, we just need to decide to keep doing it :) Maybe write it down somewhere in jdkXXXu handoff checklist, if there is any?

Sure, that does still not solve the problem with additional (critical) backports after the private stabilization branch is cut, but at least it prevents the accidental leakage of backports in downstream build/test pipelines. In the ideal world, I would have liked to see the bulk of 25.0.1/2 stabilization branch being not private, but that ship had already sailed. It would be extra nice if JDK 29u started with jdk29u (29.0.1 initially) and jdk29u-dev (29.0.1 initially, then switched to 29.0.2) from the get-go, so we don't get into any non-nice situations like these again.

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