My observation is that method overrides (e.g., ReplaceOverride and LookupOverride) work fine with no AOT processing, but as soon as an AOT build is carried out, the generated subclasses do not contain the indirection, so you just get the behavior from the base class for all methods (even when AOT is not enabled at runtime).
If for some reason we cannot actually transform this properly, we should throw an exception rather than silently skip the method overrides.
It's interesting to note that this is the first time I actually needed to use method overrides in 20 years of using Spring. I'd love to be able to AOT them - there doesn't seem to be a technical reason not to.
Comment From: dsyer
The main part of this issue is that the method overrides are not used in AOT. I can see roughly why that happens - the bean definition instance supplier is generated using the base class, not the enhanced subclass with the overrides. It might be an ordering problem - the overrides are added in a BeanFactoryPostProcessor, which seems sensible but does obviously happen in a specific point in the lifecycle.
There is a secondary problem (with a workaround) which is that AbstractBeanDefinition.prepareMethodOverrides() is not called in the AOT build, so when the instantiating strategy is called it thinks there are no overrides on methods with arguments unless you specifically match the arguments (not necessary at runtime without AOT because prepareMethodOverrides() notices that the method name is unique).