This commit leverages a subset of @philwebb initial experimentation
to compute at build time the value of specific boolean static fields
in native images. This enhancement is implemented for now as a
GraalVM feature.
The goal here is to keep an optimized footprint via build time code
removal without leveraging build-time class initialization which is known
for the blocking compatibility issues it introduces due to its viral nature.
For now, the static fields initialized at build time with native are:
- NativeDetector#imageCode
- Fields with a name ending by "Present" in "org.springframework" package
typically used for classpath check with ClassUtils#isPresent
Closes gh-28624
Move hints registration to spring-beans, where the actual behavior is
implemented. We chose not to move this to
`AutowiredAnnotationBeanPostProcessor` for now, as this would require it
to implement another AOT-related interface and add too much noise for
this.
See gh-28614
Prior to this commit, native images would dynamically check for the
presence of `jakarta.inject.*` annotations and might fail at runtime or
miss them entirely.
This change ensures that if such classes are present during the AOT
build, relevant runtime hints are registered so that these annotations
can be read at runtime.
Closes gh-28614
This commit implements 4 package private Json serializers
for JavaSerializationHints, ProxyHints, ReflectionHints
and ResourceHints to serialize GraalVM native JSON configuration
as documented in
https://www.graalvm.org/22.0/reference-manual/native-image/BuildConfiguration/.
It exposes the related functionality via
NativeConfigurationGenerator which allows to generate the
relevant files on the filesystem via the
FileNativeConfigurationGenerator implementation.
The generated *-config.json files have been validated working
with GraalVM 22.0.
Closes gh-27991
This commit repackages the Javapoet library into spring-core so that it
can be used by the AOT engine without requiring a specific version.
Closes gh-27828
Prior to this commit, our BlockHound integration tests were disabled
after the migration to a JDK 17 baseline since the build now always
runs on JDK 14 or higher.
To re-enable the tests we now supply the deprecated
-XX:+AllowRedefinitionToAddDeleteMethods command-line argument to the JVM
for tests in the Gradle build. Users can also configure this manually
within an IDE to run SpringCoreBlockHoundIntegrationTests.
If that command-line argument is removed from the JVM at some point in
the future, we will need to investigate an alternative solution.
See https://github.com/reactor/BlockHound/issues/33 for details.
Migrate `CoroutinesUtils` from Kotlin code to Java and drop the
`kotlin-coroutines` module.
This update removes the need for Kotlin tooling IDE plugins to be
installed.
Closes gh-27379
Prior to this commit, a change to Javadoc in any class in spring-core
would result in ALL tests in the entire test suite being re-run via the
Gradle build.
Thanks to a tip from @melix, this commit aims to ensure that the
spring-core JAR is "reproducible".
Prior to this commit, a change to Javadoc in any class in spring-core
would result in ALL tests in the entire test suite being re-run via the
Gradle build.
Thanks to a tip from @melix, this commit ensures that the spring-core
JAR is "reproducible".
- Build Scan plugin is now Gradle Enterprise plugin applied in settings
- Compile task dependencies are now defined through classpath
- Test fixture publication can be disabled through public API
Closes gh-24384
Prior to this commit, the Spring Framework build would partially use the
dependency management plugin to import and enforce BOMs.
This commit applies the dependency management plugin to all Java
projects and regroups all version management declaration in the root
`build.gradle` file (versions and exclusions).
Some versions are overridden in specific modules for
backwards-compatibility reasons or extended support.
This commit also adds the Gradle versions plugin that checks for
dependency upgrades in artifact repositories and produces a report; you
can use the following:
./gradlew dependencyUpdates
Prior to this commit, the Spring Framework build would mix proper
framework modules (spring-* modules published to maven central) and
internal modules such as:
* "spring-framework-bom" (which publishes the Framework BOM with all
modules)
* "spring-core-coroutines" which is an internal modules for Kotlin
compilation only
This commit renames these modules so that they don't start with
"spring-*"; we're also moving the "kotlin-coroutines" module under
"spring-core", since it's merged in the resulting JAR.
See gh-23282
This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests
With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).
See gh-23282
This commit introduces the spring-core-coroutines module
in order to avoid referencing Kotlin code from Java one,
which is currently not supported by Eclipse.
During the build, spring-core-coroutines is merged into
spring-core, so this change is expected to have no impact
for end users.
This module contains functions accessible from Java via
the CoroutinesUtils class to adapt Coroutines and Deferred
instances to and from Mono.
See gh-19975
Sébastien Deleuze
Juergen Hoeller
Brian Clozel
Phillip Webb
Stephane Nicoll
Sam Brannen
hantsy
Philippe Marschall
Rossen Stoyanchev
Sam Brannen
Jendrik Johannes
Sam Brannen
Juergen Hoeller
Andy Wilkinson
François Guillot
Brian Clozel
Stephane Nicoll
Sebastien Deleuze
Phillip Webb