From 57ddb20cc98767d8d26fb1e8430e607b3ad39f68 Mon Sep 17 00:00:00 2001 From: Moritz Halbritter Date: Mon, 30 Oct 2023 09:14:12 +0100 Subject: [PATCH] Clarify that Spring AOT imposes further restrictions Closes gh-35032 --- .../native-image/introducing-graalvm-native-images.adoc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/native-image/introducing-graalvm-native-images.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/native-image/introducing-graalvm-native-images.adoc index d86ea34005a..bacc73c7130 100644 --- a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/native-image/introducing-graalvm-native-images.adoc +++ b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/native-image/introducing-graalvm-native-images.adoc @@ -27,6 +27,9 @@ The main differences are: * There is no lazy class loading, everything shipped in the executables will be loaded in memory on startup. * There are some limitations around some aspects of Java applications that are not fully supported. +On top of those differences, Spring uses a process called <>, which imposes further limitations. +Please make sure to read at least the beginning of the next section to learn about those. + TIP: The {graal-native-image-docs}/metadata/Compatibility/[Native Image Compatibility Guide] section of the GraalVM reference documentation provides more details about GraalVM limitations. @@ -39,12 +42,11 @@ In fact, the concept of Spring Boot auto-configuration depends heavily on reacti Although it would be possible to tell GraalVM about these dynamic aspects of the application, doing so would undo most of the benefit of static analysis. So instead, when using Spring Boot to create native images, a closed-world is assumed and the dynamic aspects of the application are restricted. -A closed-world assumption implies the following restrictions: +A closed-world assumption implies, besides <>, the following restrictions: -* The classpath is fixed and fully defined at build time * The beans defined in your application cannot change at runtime, meaning: - The Spring `@Profile` annotation and profile-specific configuration <>. - - Properties that change if a bean is created are not supported (for example, `@ConditionalOnProperty` and `.enable` properties). +- Properties that change if a bean is created are not supported (for example, `@ConditionalOnProperty` and `.enable` properties). When these restrictions are in place, it becomes possible for Spring to perform ahead-of-time processing during build-time and generate additional assets that GraalVM can use. A Spring AOT processed application will typically generate: