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/junit-framework#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

[chabala]

It seems I'm a little late to the discussion, as open-feature/java-sdk#1371 already happened, but perhaps I can add some more perspective here.

1. Java 8 isn't going away.

It holds that special position as the version before the JDK release cadence changed, when the next version was promised to be unsupported after six months. Even with other more 'generally agreed to be' LTS versions like 11, 17, 21, a huge amount of companies are holding on to Java 8, for good reason: it will continue to be supported.

It doesn't get much attention, because the hype is for the shiny new Java features. Even what usage survey results exist are not very trustworthy, because the kinds of companies that are still using Java 8 are not necessarily the kind to be sharing telemetry data with NewRelic, for example.

You can bet that Oracle will extend support beyond 2030, if there's support money to be gained. Even if not, there will still be users. There are still users of Java 6 & 7 too.

2. End user projects can use the newest Java, but libraries should be conservative with the bytecode level they require.

With the exception of Spring all those examples listed are either test dependencies or build tool plugins. Projects can run tests with Java 21, and still want to compile Java 8 bytecode. But one can't link against Java 11 bytecode when compiling a Java 8 project. Compile time libraries need to be more conservative.

Don't take Spring as a good example to emulate. There are plenty of teams that would rather remove Spring from their project than be forced to follow their JDK upgrade cadence. Libraries shouldn't pressure their users to choose between keeping up with maintenance updates or using their JDK of choice.

A better example to emulate is SLF4J: qos-ch/slf4j#379 Version 2.0.0 was the first to require JDK 8, in 2022. The 1.7.X series only requires JDK 7.

Everyone else is doing it or the lure of cool new language features isn't enough to justify alienating Java 8 users.

[aepfli]

Just speaking of my mind:

The good part:
Our pom.xml is way more structured, we extracted code quality into own profiles, etc. which might make this adventure easier.

The ugly part:
A lot of language features have already been used especially var, etc. this will need closer look and effort to get rid of

The bad part:
Currently we are evaluating using JMPS which might be the next big release. JMPS is java 9 - where we would split API and SDK into separate artifacts relying on the module path functionalities. This will force us to a tip & tail release process overtime anyways.

So this might be doable, but our community is not big, and the efforts are hard to really estimate.

[chabala]

SLF4J is also an example of supporting JPMS while still being Java 8 compatible: https://www.slf4j.org/faq.html#jmpsModuleNames

I'll also mention that once you commit to supporting JPMS, you really ought to test with both the classpath and modulepath, because they behave differently, and you can't tell which way your users will use: https://blog.joda.org/2018/03/jpms-negative-benefits.html

I see a small amount of var usage that will need to get cleaned up, but I don't notice any other Java 11 language features being used: https://github.com/open-feature/java-sdk/compare/4125ae83801a9f485059a9edaca090ee47b7632f..354632084a2978db17a0d7791253c9442e843c33