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).
Comment From: 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.
Comment From: 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.
Comment From: 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).
Comment From: OrangeDog
This is purely for our own build
Oh I see. Apologies.
Comment From: BenchmarkingBuffalo
Hi @mhalbritter I would like to work on this task and will come up with a proposal.