Use Gradle toolchains so that we fail with a useful error message on JDK < 24

[mhalbritter]

As we now have JSpecify and NullAway in our build, we should configure our build to always compile with JDK 24, no matter what JDK is used to run Gradle.

Compiling with JDK 17 fails because of a compiler bug, which is fixed in 24 (and maybe get backported to 17).

[mhalbritter]

Right now, when using JDK 17, it fails with this:

/home/mhalbritter/Projects/spring-boot/main/core/spring-boot/src/main/java/org/springframework/boot/context/properties/bind/ValueObjectBinder.java:423: error: [NullAway] Method returns @Nullable String @Nullable [], but overridden method returns String [], which has mismatched type parameter nullability
                public @Nullable String @Nullable [] getParameterNames(Constructor<?> constructor) {
                                                     ^
    (see http://t.uber.com/nullaway )
/home/mhalbritter/Projects/spring-boot/main/core/spring-boot/src/main/java/org/springframework/boot/logging/structured/StructuredLogFormatterFactory.java:240: error: [NullAway] referenced method returns @Nullable, but functional interface method java.util.function.Function.apply(T) returns @NonNull
                                        ArgumentResolver.from(StructuredLogFormatterFactory.this.instantiator::getArg));
                                                              ^
    (see http://t.uber.com/nullaway )
2 errors

which looks like something is wrong in the code. With JDK 24, the build passes.

We should add something to our Gradle scripts so that if the build is run with a JDK < 24 it fails with a useful error message.

[OrangeDog]

JDK 24 is not an LTS release, and support ends next month. I don't think Spring should be requiring anything higher than JDK 21 right now.

[wilkinsona]

JDK 24 is not an LTS release, and support ends next month

Thanks, but we're already quite familiar with the JDK's release schedule.

I don't think Spring should be requiring anything higher than JDK 21 right now.

We're not. This is purely for our own build due to a javac bug (a fix for which may be back ported at some point). We can either drop back to 17 for our build should the fix be back ported or upgrade to 25.

Either way, 17 remains the JDK baseline for consuming Spring Boot (and the rest of the Spring portfolio).

[OrangeDog]

This is purely for our own build

Oh I see. Apologies.

[BenchmarkingBuffalo]

Hi @mhalbritter
I would like to work on this task and will come up with a proposal.

[mhalbritter]

Superseded by #46818.