Increasing minimum supported JDK to JDK 21 (and dropping support for JDK 17)

[cushon]

The minimum supported JDK to run Error Prone will eventually be updated from JDK 17 to JDK 21. This is tentatively planned for September 2025.

This bug is intended to collect input from the community. (Previously for the upgrade to JDK 17: #3803)

Note that using a newer JDK version to run javac during the build doesn't prevent building code that is deployed to earlier versions, the compiler just has to be configured with --release (or -source/-target/-bootclasspath). For example, it's supported to use the JDK 21 javac and pass --release 8 to compile Java 8 code that is deployed to a JDK 8 runtime.

If you're currently running Error Prone on JDK 17, do you have a timeline for upgrading to a newer version?

[TimvdLippe]

Mockito uses ErrorProne. We don't update it as often as other dependencies, since it often requires manual resolution. As such, we are on 2.23.0. When we got around to resolving it manually, we realized that the minimum version is now JDK 17: mockito/mockito#3515

Given that Mockito is one of those projects that still supports older Java projects, we are currently on JDK 11. We do see that other popular projects move to JDK 17 (Spring, JUnit, AssertJ), whereas we usually take a more conservative approach. ByteBuddy (fundamental for Mockito) still supports Java 8.

We have discussed updating the baseline of Mockito to JDK 17. We updated our baseline last in Mockito 5 released in January 2023. Given that projects like Spring (https://spring.io/blog/2022/03/28/an-update-on-java-17-adoption), JUnit (junit-team/junit-framework#4246) and AssertJ (assertj/assertj#3442) all converge on Java 17, I think 17 for us the most likely candidate. If ErrorProne updates to 21, then we are left out to use ErrorProne for the next couple of years, which I consider quite a pity.

See also this question why not to choose 21 as the baseline for all of these projects.

[cushon]

@TimvdLippe do you think the part about "using a newer JDK version to run javac during the build doesn't prevent building code that is deployed to earlier versions, the compiler just has to be configured with --release" could apply to mockito? It looks like Mockito's CI is already using JDK 17 and then configuring Gradle to run tests on older versions:

• https://github.com/mockito/mockito/blob/0215884a5e68016504be98599b3045070a558002/.github/workflows/ci.yml#L53
• https://github.com/mockito/mockito/blob/0215884a5e68016504be98599b3045070a558002/buildSrc/src/main/kotlin/mockito.test-launcher-conventions.gradle.kts#L9

[TimvdLippe]

Ah I had forgotten we did that (oops). In that case, it's not as bad as I initially thought it would. Still, I think as a JVM community we benefit from choosing 1 baseline version. For now, that appears to be JDK 17, so I rather have us all use JDK 17 as our baseline to build artifacts etc.

If ErrorProne ends up bumping, then yes in theory Mockito can update as well. Whether we will do so, I don't know yet, as I would like to discuss that with other open source maintainers first.

[scordio]

@TimvdLippe FWIW, the Javadoc issues I fixed last year (mockito/mockito#3226 and mockito/mockito#3230) forced Mockito to use Java 21 at least when releasing.

In AssertJ, we decided to adopt the latest LTS to build the project, and we haven't encountered issues so far.