How to handle Spring + Java 8?

[brendandburns]

Spring has moved to require Java 17 with Spring 6 (https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6)

We probably want to continue to support Java 8 + Spring 5, and this library will keep moving forward with new Kubernetes releases.

So we need to figure out how to move forward here.

I think the best thing to do is probably to extract the code from the extended package into a separate spring-6 package which can take a dependency on the new spring code.

Note that this is less than ideal because we will have a bunch of code duplication and probably start having feature skew between the two packages.

cc @yue9944882 @joshlong

Does anyone know how other libraries are approaching this?

[joshlong]

Hi

It is possible to share the base Spring Boot 2 autoconfiguration (assuming you add a text file called AutoConfiguration.imports) for both Spring Boot 2 and Spring Boot 3. The only part unique to Spring Boot 3 is the new AOT engine (which makes it easy to use a spring boot library in a graalvm native-image context). so, perhaps you could create a starter-aot (or something) which in turn imports the core starter. that way people using Spring Boot 3's AOT engine could use that, and everybody else could just use the regular starter, which works in both boot 2 and 3, and on java 8 or later.

I prototyped this to see if it'd work out in practice by building a regular starter (for both boot 2 and 3), a starter-aot (for just boot 3), an app-2 to use the regular starter, and an app-3 to use the starter-aot.

https://github.com/joshlong/hybrid-2-and-3-spring-boot-starters

it seems to work. maybe there's a better way, but at least this works.

NB:

• I had to add a new (text-)file from boot 3 to the otherwise boot 2 starter so that it'd function in both boot 2 and 3
• I setup .sdkmanrc files so that the two boot 2 projects - the starter and app-2 assume a java 8 compiler, while the boot 3 projects - starter-aot and app-3 - assume java 17

[dsyer]

+1 - it should be trivial to support Spring Boot 2 and 3 without a separate jar artifact. At least we should start that way. We could maybe drop Spring Boot 2 when the Kubernetes client reaches a new major, but it's probably not going to be mandatory.

UPDATE: ignore the "without a separate artifact" comment - the AOT hints need Spring 6 to compile, so you can only do it in a single artifact if you can use Java 17, and I guess that's not an option for legacy scenarios.

I mean, it might be possible to ship both things in one jar. Spring Boot 2 will not go anywhere near the new features, so they could be a different class format I guess. Kind of a hack probably. There is such a thing as a "multiplatform jar" in the JDK though right? I never saw one in the wild.

[brendandburns]

The problem has to do with compiling the spring code in this library. (and it's not just about spring boot, it's about spring generally)

We're going to target Spring 5.x for now because we need to maintain Java 8 compatability. That means that we can't take a dependency on Spring 6 from this library. Hence the need to split the code so that one library can depend on spring 5 and the other can depend on spring 6.

[joshlong]

right. that's basically what my prototype demonstrates. i wouldn't bifurcate them in terms of spring framework 5 and 6, but instead in terms of the auto configuration (available in all versions of Spring Boot) and the ahead-of-time (AOT) compilation for graalvm (unique to SF 6 / spring boot 3) support.

so you'd leave the auto configuration as-is, but add one text file, META-INF/spring/...AutoConfiguration.imports. that jar links to SB 2 and compiles with java 8. it'll work in SF 6 and SB 3, too.

then you introduce a new jar, which in my prototype I've called starter-aot, which pulls in starter but then also contributes AOT 'hints' to make the starter work when compiled in a graalvm app.

SB 3 users could pull in starter OR starter-aot (i'd encourage them to use starter-aot, since graalvm's dope and there's no high quite like the high of a well-written kubernetes controller written on the JVM and spring boot that takes 50mb of RAM!)

SB 2 users pull in starter (eg, nothing changes for them at all)

starter in my prototype corresponds to what you're calling spring. you could introduce a new module, spring-aot that does what starter-aot does in my prototype.

the contents of spring-aot would be, basically, the contents of my PR adding AOT support a month or two ago.

I'm happy to craft a new PR to reflect that arrangement if it sounds workable to you.

[brendandburns]

@joshlong thanks for the details, it feels like this would be a good approach. Basically if you can craft a PR that passes our integration testing we're good with it :)

[joshlong]

hi - i have just sent this PR. it changes almost nothing from the existing client-java-spring-integration module, adding only one text file. It also adds a new module to specifically support Spring Boot 3 AOT.

#2457

[yue9944882]

https://github.com/joshlong/hybrid-2-and-3-spring-boot-starters

@joshlong thank you for the demo project, i've ran it locally and it works like a charm. running the spring3 app which lists starter-aot in the dependencies on java8 will throw out the following errors as expected, so any user feel like trying out spring3 and java17 can simply opt-in by adding the new module.

Module starter-aot SDK 1.8 is not compatible with the source version 17.
Upgrade Module SDK in project settings to 17 or higher.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[dsyer]

/remove-lifecycle stale

(But #2457 is merged, so why is this one still open?)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale