Repository navigation
Conversation
Proposal kroxylicious#141 needs JEP 527 (post-quantum ML-KEM) to avoid depending on Bouncy Castle. JDK 25 also brings the JEP 491 virtual thread pinning fix and a more current LTS. Keep the Java 21 language level and test coverage in place so this isn't a breaking change for plugin developers or bare-metal JDK 21 users. Assisted-by: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Robert Young <robertyoungnz@gmail.com>
robobario
changed the title
Signed-off-by: Robert Young <robertyoungnz@gmail.com>
SamBarker
left a comment
SamBarker
left a comment
There was a problem hiding this comment.
Proposal looks good — happy with the runtime/language-level separation. A few minor comments inline.
Decouple the JDK 25 runtime move from waiting on OpenJDK 25.0.5, since PQC support arrives separately through the normal dependency upgrade cycle. Explain why integration/system tests pin to JDK 25 instead of 21, following the DNS resolver precedent. Add the admission controller to the affected-projects list. Assisted-by: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Robert Young <robertyoungnz@gmail.com>
|
had an offline chat about this and there's some doubt about whether we need an additional concept/name like "preferred runtime" when we've been through the same process for 17->21, where we had the language/compile level at 17 and everything else at 21 for some time, with unit tests additionally run against 17. |
|
I wouldn't want to scope creep this proposal but with Java 29 (next LTS) due less than a year away, is it worth making this a proposal to adopt new LTS versions. Having code built to the current LTS -1 (in this case Java 21) and moving the JDK to the next LTS (Java 25) means that we would plan to move the code to 25 and JDK to 29 next year. This would allow a predictable upgrade path but also provide a timeline for when the project will be able to use new language features. |
|
|
||
| Kroxylicious compiles to Java 21 bytecode (`maven.compiler.release=21`); the floor moved from 17 to 21 on 3 July 2026, completing stage 2 of proposal 013. | ||
|
|
||
| CI builds and runs the unit test suite against JDK 21. Container images for `kroxylicious` and `kroxylicious-operator` run on JDK 21. |
There was a problem hiding this comment.
nit: Don't we also run the unit tests on JDK 25?
|
|
||
| This proposal separates the *preferred runtime* (the JDK the project builds containers with and recommends to operators) from the *language level* (the bytecode target and minimum supported JDK). | ||
|
|
||
| 1. Update the container images for `kroxylicious`, `kroxylicious-operator`, and `kroxylicious-admission-control` to use a JDK 25 base image, and update CI workflows to build with JDK 25. This does not need to wait for OpenJDK 25.0.5; the runtime move and PQC enablement are separable, and JDK 25.0.5 reaches the project through the normal dependency upgrade cycle once it ships. |
There was a problem hiding this comment.
nit: we mostly use ubi-minimal as a base image, then install the JDK RPM
|
|
||
| 1. Update the container images for `kroxylicious`, `kroxylicious-operator`, and `kroxylicious-admission-control` to use a JDK 25 base image, and update CI workflows to build with JDK 25. This does not need to wait for OpenJDK 25.0.5; the runtime move and PQC enablement are separable, and JDK 25.0.5 reaches the project through the normal dependency upgrade cycle once it ships. | ||
| 2. Keep `maven.compiler.release` at 21. No bytecode or language-level change. Users running Kroxylicious on bare-metal JDK 21 see no breaking change. | ||
| 3. Continue running the unit test suite against JDK 21, as happens today, so the minimum supported JDK stays verified. Run integration/system tests against JDK 25 only, not JDK 21. We already pin integration tests to a specific JDK where behaviour depends on it (JDK 21 for DNS resolver behaviour); the same logic applies here. Once JDK 25.0.5 lands, verifying a PQC-enabled session (proposal #141) requires a JVM with JEP 527, so those tests can only run meaningfully on JDK 25. |
There was a problem hiding this comment.
(JDK 21 for DNS resolver behaviour)
nit: That was a special case we needed when the project was Java 17 focused. The special casing disappeared last year.
|
|
||
| 1. Update the container images for `kroxylicious`, `kroxylicious-operator`, and `kroxylicious-admission-control` to use a JDK 25 base image, and update CI workflows to build with JDK 25. This does not need to wait for OpenJDK 25.0.5; the runtime move and PQC enablement are separable, and JDK 25.0.5 reaches the project through the normal dependency upgrade cycle once it ships. | ||
| 2. Keep `maven.compiler.release` at 21. No bytecode or language-level change. Users running Kroxylicious on bare-metal JDK 21 see no breaking change. | ||
| 3. Continue running the unit test suite against JDK 21, as happens today, so the minimum supported JDK stays verified. Run integration/system tests against JDK 25 only, not JDK 21. We already pin integration tests to a specific JDK where behaviour depends on it (JDK 21 for DNS resolver behaviour); the same logic applies here. Once JDK 25.0.5 lands, verifying a PQC-enabled session (proposal #141) requires a JVM with JEP 527, so those tests can only run meaningfully on JDK 25. |
There was a problem hiding this comment.
Run integration/system tests against JDK 25 only, not JDK 21.
I'm not sure about that. We'd need to be very confident that our JDK specific code (PQC for instance) is covered by the unit tests. Running no integration tests against JDK 21 makes me feel uneasy. Could we identify a subset of integration tests and run those against JDK 21?
There was a problem hiding this comment.
the motivation here was conserving our actions budget which is pretty taxed already. In a perfect world we could run the full IT suite against both versions. Running a subset sounds like a good idea to me.
Would it also be worth something like a daily test run to exercise the full set of ITs on 21? I know it's shifting things further away from the breaking commit but I don't feel like we can double our IT load on GHA without further impacting the difficulty of getting things merged. It would give some confidence if we have any automation that runs all the tests.
Having the floor be the prior LTS with an upgrade every two years does feel like a reasonable amount of runway. One problem is since we've increased the floor to 21 recently, increasing it again when JDK 29 releases would be quite quick. Then there's unknown Vendor requirements, we may find come the release JDK LTS X that some vendor really needs more time to upgrade from LTS X-2 and it may be in the projects interest to weigh that up against keeping up with JDK improvements and new language features. So I feel like each floor bump should have a proposal to give community members a chance to speak up. It might also dovetail with the 1.0.0 discussion, like maybe we could consider tying JRE minimum versions to a major project version? I think you're right though, that we could write up a policy that would help users. If we can say what the project would prefer to do, and that we'll consult the community when we bump the floor, that would just make it a mechanical thing. I think it'd be good to do separately from this PR and I can have a go at writing a policy after this one is wrapped up. |
|
I think that PQC and its associated back porting is a special case, so raising a separate proposal to define the adoption of new LTS's would be good. If we pinned the Java byte code to JVM LTS X - 1, but tested and built the project images on JVM LTS that effectively gives 2 LTS releases to move up whilst still being able to take advantage of JVM enhancements and bug fixes. Let me know if I can help with the new proposal. |
Proposal #141 needs JEP 527 (post-quantum ML-KEM) to avoid depending on Bouncy Castle. JDK 25 also brings the JEP 491 virtual thread pinning fix and a more current LTS. Keep the Java 21 language level and test coverage in place so this isn't a breaking change for plugin developers or bare-metal JDK 21 users.
Assisted-by: Claude Sonnet 5 noreply@anthropic.com