Nested configuration properties which are no inner classes, however, *must* be annotated with `@NestedConfigurationProperty`, otherwise they won't be detected and will not be bindable.
Without the `@NestedConfigurationProperty` annotation on the `nested` field, the `my.properties.nested.number` property would not be bindable in a native image.
It is possible to convert a Spring Boot <<executable-jar#appendix.executable-jar, executable jar>> into a native image as long at the jar contains the AOT generated assets.
* As `native-image` https://github.com/oracle/graal/issues/407[does not support cross-compilation], you can keep an OS neutral deployment artifact which you convert later to different OS architectures.
You can convert a Spring Boot executable jar into a native image using Cloud Native Buildpacks, or using the `native-image` tool that is shipped with GraalVM.
Spring Boot applications usually use Cloud Native Buildpacks via the Maven (`mvn spring-boot:build-image`), or Gradle (`gradle bootBuildImage`) integrations.
You can, however, also use https://buildpacks.io//docs/tools/pack/[`pack`] to turn an AOT processed Spring Boot executable jar into a native container image.
The GraalVM native image {graal-native-image-docs}/metadata/AutomaticMetadataCollection[tracing agent] allows you to intercept reflection, resources or proxy usage on the JVM in order to generate the related hints.
Spring should generate most of these hints automatically, but the tracing agent can be used to quickly identify the missing entries.
When using the agent to generate hints for a native image, there are a couple of approaches:
* Launch the application directly and exercise it.
* Run application tests to exercise the application.
The first option is interesting for identifying the missing hints when a library or a pattern is not recognized by Spring.
The second option sounds more appealing for a repeatable setup, but by default the generated hints will include anything required by the test infrastructure.
Some of these will be unnecessary when the application runs for real.
To address this problem the agent supports an access-filter file that will cause certain data to be excluded from the generated output.
If you need to provide your own hints for reflection, resources, serialization, proxy usage etc. you can use the `RuntimeHintsRegistrar` API.
Create a class that implements the `RuntimeHintsRegistrar` interface, then make appropriate calls to the provided `RuntimeHints` instance:
include::code:MyRuntimeHints[]
You can then use `@ImportRuntimeHints` on any `@Configuration` class (for example your `@SpringBootApplication` annotated application class) to activate those hints.
If you have classes which needs binding (mostly needed when serializing or deserializing JSON), you can use {spring-framework-docs}/core.html#aot-hints-register-reflection-for-binding[`@RegisterReflectionForBinding`] on any bean.
Most of the hints are automatically inferred, for example when accepting or returning data from a `@RestController` method.
But when you work with `WebClient` or `RestTemplate` directly, you might need to use `RegisterReflectionForBinding`.
The `RuntimeHintsPredicates` API can be used to test your hints.
The API provides methods that build a `Predicate` that can be used to test a `RuntimeHints` instance.
If you're using AssertJ, your test would look like this:
include::code:MyRuntimeHintsTests[]
[[native-image.advanced.known-limitations]]
=== Known Limitations
GraalVM native images are an evolving technology and not all libraries provide support.
The GraalVM community is helping by providing https://github.com/oracle/graalvm-reachability-metadata[reachability metadata] for projects that don't yet ship their own.
Spring itself doesn't contain hints for 3rd party libraries and instead relies on the reachability metadata project.
If you encounter problems when generating native images for Spring Boot applications, please check the {github-wiki}/Known-GraalVM-Native-Image-Limitations[Known GraalVM Native Image Limitations] page of the Spring Boot wiki.
You can also contribute issues to the https://github.com/spring-projects/spring-aot-smoke-tests[spring-aot-smoke-tests] project on GitHub which is used to confirm that common application types are working as expected.
If you find a library which doesn't work with GraalVM, please raise an issue on the https://github.com/oracle/graalvm-reachability-metadata[reachability metadata project].
