From 7102c3366152a86dac7478119685ccad4795a62c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20Nicoll?= Date: Tue, 4 Jun 2024 15:51:40 +0200 Subject: [PATCH] Add section about using complex data structures with AOT Closes gh-32273 --- framework-docs/modules/ROOT/pages/core/aot.adoc | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/framework-docs/modules/ROOT/pages/core/aot.adoc b/framework-docs/modules/ROOT/pages/core/aot.adoc index 88e5c169e47..9446fdc24c0 100644 --- a/framework-docs/modules/ROOT/pages/core/aot.adoc +++ b/framework-docs/modules/ROOT/pages/core/aot.adoc @@ -326,6 +326,19 @@ However, this is not a best practice and flagging the preferred constructor with In case you are working on a code base that you cannot modify, you can set the {spring-framework-api}/beans/factory/support/AbstractBeanDefinition.html#PREFERRED_CONSTRUCTORS_ATTRIBUTE[`preferredConstructors` attribute] on the related bean definition to indicate which constructor should be used. +[[aot.bestpractices.comlext-data-structure]] +=== Avoid Complex Data Structure for Constructor Parameters and Properties + +When crafting a `RootBeanDefinition` programmatically, you are not constrained in terms of types that you can use. +For instance, you may have a custom `record` with several properties that your bean takes as a constructor argument. + +While this works fine with the regular runtime, AOT does not know how to generate the code of your custom data structure. +A good rule of thumb is to keep in mind that bean definitions are an abstraction on top of several models. +Rather than using such structure, decomposing to simple types or referring to a bean that is built as such is recommended. + +As a last resort, you can implement your own `org.springframework.aot.generate.ValueCodeGenerator$Delegate`. +To use it, register its fully qualified name in `META-INF/spring/aot.factories` using the `Delegate` as the key. + [[aot.bestpractices.custom-arguments]] === Avoid Creating Bean with Custom Arguments