This commit upgrades our test suite to use JUnit 6.0.1 and removes the
systemProperty("junit.platform.discovery.issue.severity.critical", "WARNING")
configuration from spring-test.gradle, so that all discovery issues will
fail the build for the spring-test module as well.
In addition, this commit prevents potential AOT test scanning failures
for JUnit 4 tests by setting the
"junit.vintage.discovery.issue.reporting.enabled" configuration
parameter to "false" in TestClassScanner.
See https://github.com/junit-team/junit-framework/issues/5030
Closes gh-35740
This commit upgrades the build to use Gradle 9.1.
To achieve that, the following changes were necessary.
- Stop using Groovy safe-navigation operator (?.) in
framework-api.gradle due to a NullPointerException.
- Switch from the io.github.goooler.shadow plugin to the
com.gradleup.shadow plugin, since the former is no longer maintained
and the latter is a fork that replaces it.
Closes gh-35508
This commit simplifies our dependency management for JUnit artifacts by
making use of the junit-jupiter and junit-platform-suite aggregator
artifacts.
Closes gh-35127
Now that we are using JDK 18+ (currently JDK 24 -- see JavaConventions
in buildSrc for details), we can reinstate links to JUnit 5 Javadoc APIs.
Closes gh-27497
This commit revisit the build configuration to enforce the following:
* A single Java toolchain is used consistently with a recent Java
version (here, Java 23) and language level
* the main source is compiled with the Java 17 "-release" target
* Multi-Release classes are compiled with their respective "-release"
target. For now, only "spring-core" ships Java 21 variants.
Closes gh-34507
This commit updates the whole Spring Framework codebase to use JSpecify
annotations instead of Spring null-safety annotations with JSR 305
semantics.
JSpecify provides signficant enhancements such as properly defined
specifications, a canonical dependency with no split-package issue,
better tooling, better Kotlin integration and the capability to specify
generic type, array and varargs element null-safety. Generic type
null-safety is not defined by this commit yet and will be specified
later.
A key difference is that Spring null-safety annotations, following
JSR 305 semantics, apply to fields, parameters and return values,
while JSpecify annotations apply to type usages. That's why this
commit moves nullability annotations closer to the type for fields
and return values.
See gh-28797
Sébastien Deleuze
Sam Brannen
Brian Clozel
Juergen Hoeller
Sébastien Deleuze
Sébastien Deleuze