KAFKA-19751: Java 23 is not officially supported

[FrankYang0529]

https://issues.apache.org/jira/browse/KAFKA-19751

[FrankYang0529]

Preview:

[chia7712]

Maybe we could copy the description from trunk?

We build and test Apache Kafka with 17 and 25. The release parameter in javac is set to 11 for the clients and streams modules, and 17 for the rest, ensuring compatibility with their respective minimum Java versions. Similarly, the release parameter in scalac is set to 11 for the streams modules and 17 for the rest.
Scala 2.13 is the only supported version in Apache Kafka.

[FrankYang0529]

@chia7712 Thanks for the review. I update a version like following:

Build and test Apache Kafka with Java 8, 11, 17, 21, and 23. Set the release parameter in javac and scalac
to 8 to ensure the generated binaries are compatible with Java 8 or higher (independently of the Java version
used for compilation).

[chia7712]

I apologize, but I feel that is too detailed for the users. Perhaps we should simply remind them that JDK 23 is not officially supported

Java 8, Java 11, Java 17, and Java 21 are fully supported. Java 23 is used by CI but is not officially supported since it is not an LTS version.

[srdo]

Talking about non-LTS seems odd to me, since non-LTS versions can be supported up until they hit end of life?

Surely the reason Java 23 is not supported is not that it's non-LTS, it's that Java 23 has hit end of life at this point, and it's an extremely bad idea to still be using it?

Wouldn't it be good enough to just say that Java 8, 11, 17 and 21 are supported and leave it at that?

[chia7712]

Talking about non-LTS seems odd to me

You are right. We should focus on the EOL status, not the non-LTS status

[chia7712]

Wouldn't it be good enough to just say that Java 8, 11, 17 and 21 are supported and leave it at that?

I'm fine with it :)

[gharris1727]

Java 23 and 24 are significant due to the removal of the SecurityManager, despite being non-LTS versions.

If we wish to remove 23 from the documentation, we should replace it with 24 or 25. Otherwise we will invite further questions about whether we support Java versions without the SecurityManager.

Also if the 3.9 documentation says 23 but the trunk documentation says 21, it appears that our version support has regressed, when I don't think it really has.

[gharris1727]

That being said, I think the current documentation is accurate and helpful as-is, so I don't think this PR should be merged, -1.

Adding support for Java 23+ was hard-fought for by users of Kafka, and this documentation should reflect the reality. Even if 23 and 3.9 go out of support, the documentation can still reflect the reality of the situation.

[srdo]

If we wish to remove 23 from the documentation, we should replace it with 24 or 25

The problem is that 3.9 CI runs Java 23. If 3.9 wants to list support for 25, we'd need to backport the Java upgrade (and various changes) to 3.9.

IIRC there were no production code changes needed to support 25 on trunk, just upgrades for Gradle and plugins like Spotbugs, so I guess whether backporting those changes is worth it depends on whether there is demand for Java 25 support in 3.9, or whether people have started moving to 4.0+?

It feels iffy to me to claim support for a Java version for 3.9 that 3.9's CI doesn't run against, so I think 3.9 can at most claim to be compatible with 23, and 22-24 are EOL and no one should be using them anymore, so it seems odd to claim support for them.

I guess it doesn't hurt anything for the docs to say that 3.9 is compatible with Java 23, that should be a safe claim.

Also if the 3.9 documentation says 23 but the trunk documentation says 21, it appears that our version support has regressed, when I don't think it really has.

Completely agree, but I think the fix should be for the trunk documentation to claim support for Java 25, since that's what CI runs now, as far as I know. I think maybe listing that version was just missed?

[srdo]

Guess someone else thought the same thing, 25 is being added to the docs over here apache/kafka#20917

[chia7712]

Guess someone else thought the same thing, 25 is being added to the docs over here

Yes, our team is updating trunk to ensure that users don't assume there is a regression.

Adding support for Java 23+ was hard-fought for by users of Kafka, and this documentation should reflect the reality. Even if 23 and 3.9 go out of support, the documentation can still reflect the reality of the situation.

Yes, I was one of the voters in that thread.

I think the current documentation is accurate and helpful as-is

How about just adding a description to remind users that Java 23 is EOL? That would be more accurate and helpful.

 Java 8, Java 11, Java 17, Java 21 and Java 23 are fully supported, but users should be aware that Java 23 has reached End-of-Life (EOL).

[gharris1727]

How about just adding a description to remind users that Java 23 is EOL? That would be more accurate and helpful.

I don't think that information is necessary to convey here. That's something between the user and the provider of the JRE, it doesn't involve Apache Kafka at all. Some providers may offer longer support contracts out of sight.

[chia7712]

I don't think that information is necessary to convey here. That's something between the user and the provider of the JRE, it doesn't involve Apache Kafka at all. Some providers may offer longer support contracts out of sight.

Sounds good. Another way to offer helpful guidance to users would be to backport the following description from trunk to 3.9. Users should be aware that java 23 is supported by Kafka 3.9. However, they must also understand the importance of using an LTS or extended support version for production environments. WDYT?

  We generally recommend running Apache Kafka with the most recent LTS release (Java 21 at the time of writing) for performance, efficiency and support reasons. From a security perspective, we recommend the latest released patch version as older versions typically have disclosed security vulnerabilities.

[ijuma]

The readme description has Apache Kafka developers as the audience (and hence why it's detailed and covers the compilation aspects, etc.). On the other hand, the page being updated is for users of Apache Kafka and hence it should be simpler.

Running unit and integration tests is the minimum required to claim support, but it doesn't actually exercise the system fully. You'd want to run complex workloads for long periods of time, performance tests, stress tests, system tests, etc. Many vendors do this, but they typically do this with one or more of the LTS Java versions.

From that perspective, to avoid known CVEs and also because non LTS version testing shifts regularly, it's actually a very good idea to encourage users to use one of the LTS versions.

I think it would be reasonable to backport the Java 25 patches and add that instead of Java 23. That is the cleanest option and gives users who have not migrated to KRaft an opportunity to use the latest Java version.

[ijuma]

Guess someone else thought the same thing, 25 is being added to the docs over here apache/kafka#20917

Ah, yes. That text is actually much more helpful. I am also ok leaving 3.9 as it is since the text for newer versions is fine.

[chia7712]

I think it would be reasonable to backport the Java 25 patches and add that instead of Java 23. That is the cleanest option and gives users who have not migrated to KRaft an opportunity to use the latest Java

I love this suggestion. The primary reason I want to have the next patch release is to make non-Kraft users happy. Support for Java 25 is definitely a welcome Christmas gift

@gharris1727 @FrankYang0529 What do you think? We may need some time to address this, as supporting Java 25 will require us to update Gradle and its related plugins.

[FrankYang0529]

What do you think? We may need some time to address this, as supporting Java 25 will require us to update Gradle and its related plugins.

Agree, some users still use ZK mode and may need more time to migrate to KRaft. It's good to include latest LTS (Java 25 at this moment) in 3.9 branch.

[chia7712]

I have opened KAFKA-19897 for java 25, and it's marked as a blocker for 3.9.2. We should hold this PR until KAFKA-19897 is resolved

[FrankYang0529]

Based on current discussion, I changed the content to Build and test Apache Kafka with Java 8, 11, 17, 21, and 25.. We can merge this PR after https://issues.apache.org/jira/browse/KAFKA-19897 is finished.

[mingyen066]

Bad news: According to the Gradle compatibility matrix,
Since Kafka 3.9 supports Java 8, we're stuck with Gradle 8.14 max. But Java 25 requires Gradle 9.10+. So If we need to keep Java 8 support, we can only go up to Java 23 or 24.

[srdo]

@mingyen066 This may be a bigger lift, but I believe Gradle supports decoupling the JDK used for invoking Gradle itself from the JDK used for compiling the project code, via the "toolchains" concept. https://docs.gradle.org/current/userguide/toolchains.html#sec:using-java-toolchains

Maybe it would be worth looking at that for trunk too, it could enable Kafka to upgrade the JDK faster in the future, even before Gradle gains support? It might also make branch switching easier, if Gradle were configured to download a JDK instead of running with the one that happens to be installed locally?

Anyway, just an idea, not sure if it's worth doing?

[chia7712]

Anyway, just an idea, not sure if it's worth doing?

That is good idea to me. To avoid introducing major changes to 3.9, let's focus on using JDK 25 just to run tests. We could implement this by creating a specific test task that uses the JDK 25 toolchain

for example:

    task test21(type: Test, dependsOn: compileJava) {
        maxParallelForks = maxTestForks
        ignoreFailures = userIgnoreFailures

        maxHeapSize = defaultMaxHeapSize
        jvmArgs = defaultJvmArgs

        javaLauncher = javaToolchains.launcherFor {
            languageVersion = JavaLanguageVersion.of(25)
        }

        testLogging {
            events = userTestLoggingEvents ?: testLoggingEvents
            showStandardStreams = userShowStandardStreams ?: testShowStandardStreams
            exceptionFormat = testExceptionFormat
            displayGranularity = 0
        }
        logTestStdout.rehydrate(delegate, owner, this)()

        exclude testsToExclude

        useJUnitPlatform {
            includeEngines 'junit-jupiter'
        }

        retry {
            maxRetries = userMaxTestRetries
            maxFailures = userMaxTestRetryFailures
        }

        testClassesDirs = sourceSets.test.output.classesDirs
        classpath = sourceSets.test.runtimeClasspath
    }

Maybe it would be worth looking at that for trunk too, it could enable Kafka to upgrade the JDK faster in the future, even before Gradle gains support? It might also make branch switching easier, if Gradle were configured to download a JDK instead of running with the one that happens to be installed locally?

I suggest keeping this solution specific to 3.9 for now, unless faster JDK updates become a priority on trunk

[srdo]

I suggest keeping this solution specific to 3.9 for now, unless faster JDK updates become a priority on trunk

We'll see with the next couple of upgrades I guess.

I feel like Gradle definitely delayed testing around the Java 24 upgrade though, so it's been a problem in the past.