GitHub-Spring/spring-boot
1
0
Fork 0
mirror of https://github.com/spring-projects/spring-boot.git synced 2026-05-04 05:01:06 +01:00
Code Issues Projects Releases Wiki Activity

Clarify that Spring AOT imposes further restrictions

Browse Source 
Closes gh-35032
This commit is contained in:
Moritz Halbritter
2023-10-30 09:14:12 +01:00
parent bf195798ce
commit 57ddb20cc9
1 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
spring-boot-project/spring-boot-docs/src/docs/asciidoc/native-image/introducing-graalvm-native-images.adoc
+5 -3
View File
@@ -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 <<native-image#native-image.introducing-graalvm-native-images.understanding-aot-processing, Spring Ahead-of-Time processing>>, 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 <<native-image#native-image.introducing-graalvm-native-images.key-differences-with-jvm-deployments, the limitations created by GraalVM itself>>, 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 <<howto#howto.aot.conditions,have limitations>>.
- 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: