Sébastien Deleuze

After discussing this issue with the team, I can share that changing the behavior or differentiate valid use cases from obvious errors is much more complex and nuanced than it...

I have not the bandwidth to do that for Spring Framework 5.2, but that's probably a good candidate for Spring Framework 5.3.

A significant part of the documentation has been updated, so let's close this issue and get feedback after `6.2.0-M1` release and follow-up with #32429 and #32600.

That's indeed something we don't support yet, and I understand how it can be an issue for our users that were leveraging those functional constructs because they are naturally better...

Another workaround is to use `@Bean` to include the web router as mentioned in [this comment](https://github.com/spring-projects/spring-framework/issues/29658#issuecomment-1341681414). ``` fun main() { runApplication { addInitializers( beans { bean() bean() bean() bean() }...

@vladimirfx I understand the pain, we are going to document this issue.

https://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas provides interesting background why instance supplier callback can't be supported in AOT code generation.

In addition to the short term documentation of this limitation, there could be potentially way to tackle that middle term, by skipping AOT processing for some `ApplicationContextInitializer` or specific beans...

[An interesting related blog post by Meta](https://engineering.fb.com/2022/11/22/developer-tools/meta-java-nullsafe/). An important improvement would be IMO to update the Spring Framework build to check null-safety at build-time, not just rely on IntelliJ IDEA...

In addition to the change of artifact and meta-annotations, the switch to jSpecify is expected to allow Spring to refine the following aspects of null-safety: - Support null-safety at generics,...