Should we change our baseline java version?

[aepfli]

Java 8 has been out there for quite a while, and development on Java 8 has been dropped (still providing security and bug fixes) by a lot of tools or is in the process of being dropped - often, they aim for Java 17:

• checkstyle - https://checkstyle.sourceforge.io/releasenotes.html#Release_10.0 (java 11)
• spotless - https://github.com/diffplug/spotless/blob/main/plugin-maven/README.md#requirements (java 11)
• mockito - https://github.com/mockito/mockito/blob/main/README.md#current-version-is-5x (java 11)
• assertJ - https://bsky.app/profile/assertj.github.io/post/3ldzywdoh7c23 (even to java 17)
• junit - Change Java baseline to 17 for 6.0 junit-team/junit5#4246 aiming for 17 in their next big release
• cucumber - Consider changing Java baseline to 17 cucumber/cucumber-jvm#2962 also aiming for newer versions
• spring - https://spring.io/blog/2022/03/28/an-update-on-java-17-adoption (java 17)
• junit pioneer - https://github.com/junit-pioneer/junit-pioneer/releases/tag/v2.0.0 (java 11)

I do think that our SDK and tools provide already a good set of functionality, so we could move into that direction too.

furthermore, there is this nice read https://openjdk.org/jeps/14 (where we could still support an old version and provide security fixes - tip and tail)

I think it is time to at least start the discussion and document our reasons behind one or the other, to have a basis for future discussions. What do you think?

cc @open-feature/sdk-java-maintainers @open-feature/sdk-java-approvers

[aepfli]

we could still aim and target Java 8 on the language level - but change our main builds to eg java 17

[thomaspoignant]

I've been blocked for some dependencies update on the contrib repo for this reason.
For example this PR open-feature/java-sdk-contrib#1066 is blocked because caffeine 3.x.x requires java 11 or above.

In the other end, I saw that OpenJDK support for Java 8 is until November 30, 2026 and Oracle has an extended support for it until December 2030.

So I am a bit unsure what's best here.
I was not able to find any stats on the usage of java 8 in 2025 😞.

[aepfli]

with my draft pr, open-feature/java-sdk-contrib#1205 we could also allow that contrib sdk have their own baseline of java. maybe this freedom makes the adoption for different provider easier.

[toddbaert]

Great timing @aepfli !

Last week I specially reached out to some organizations which are large OpenFeature adopters who have historically been stuck on Java 8. I wanted to have input from these parties before formally proposing moving to a Java 11 minimum, but it's great to start the conversation in the open now.

I'll engage the TC and continue to seek input from the specific orgs this might concern.

cc @thomaspoignant @lukas-reining @kinyoklion

[justinabrahms]

I think that it would be good to know from those orgs.. do they view the adk as "done" for their needs? I think eBay is largely in this position. To the point that if we stopped shipping them updates.. it'd probably be fine. Would be good to ask as you have those conversations.

[thomaspoignant]

I agree with @justinabrahms here, do we think that the current version of the SDK is enough for most of the java 8 usecases? If the answer is yes we can probably upgrade it.

On the other end, it will also force providers builder to have a java compatibility with java 8 if they want to start integrating with OpenFeature.

[toddbaert]

From a technical perspective, we can target Java 11 in a Java 17 build environment, certainly, but my understanding is that the risk of that is that it's still possible to accidentally use Java 12+ APIs in this situation and they won't be caught until some consumer then tries to use the resultant class files in a Java 11 VM which then breaks because these APIs are missing.

So I think we just need to have some small part of our CI run some subset of relatively broad tests in Java 11 to ensure things are good, even if the majority of the CI runs in 17...

TBH we could possibly even do this now for Java 8.

[aepfli]

open-feature/java-sdk-contrib#1205 here is a little PoC for java builds with 3 different java versions - see https://github.com/open-feature-forking/java-sdk-contrib/pull/3/checks (build is not triggered on the main repo pr)

[toddbaert]

I think this is the way forward 🙏

[ARobertsCollibra]

If the build environment has Java 8 available, you can set -source 8 -target 8 -Xbootclasspath ${jdk8}/jre/lib/rt.jar to ensure that no java standard library classes or methods are used that aren't compatible with Java 8.

[toddbaert]

@aepfli made use of this which seems to address the issue from my perspective. This maven.compiler plugin option causes errors if you use APIs above the version specified.

[aepfli]

and here is some information from the spring framework https://spring.io/blog/2022/03/28/an-update-on-java-17-adoption