Code generation should not contribute (inferred) destroy method name

[snicoll]

(inferred) is used as a special method name within the core container. When AOT runs, it should handle that and not write that value.

[snicoll]

Actually I am having some second thoughts on this one. @jhoeller what do you think?

[snicoll]

We should "infer" the close method at build time rather than letting the container do this at runtime. As we're using reflection to invoke the method, that would miss a hint anyway.

[snicoll]

We're going to try to lazily infer this when setTargetType is available in AOT use cases.

[snicoll]

I am still seeing (inferred) in generated code so it looks like the fix above does not handle all cases.

[snicoll]

OK the good news is that it was a local change I was working on that mutates the bean definition late. This has the effect of making the cache stale or something which brings back the default value for some reason. We should identify why that is and keep the resolution around.

[snicoll]

2e1538a now mutates the original bean definition.

[bclozel]

Removing the workaround in ApplicationContextAotGeneratorRuntimeHintsTests still fails with the following:

Missing <"ReflectionHints"> for invocation <java.lang.Class#getMethods> on type <org.springframework.context.testfixture.context.generator.annotation.InitDestroyComponent> 
with arguments [].
Stacktrace:
<"org.springframework.beans.BeanUtils#findMethodWithMinimalParameters, Line 350
org.springframework.beans.factory.support.DisposableBeanAdapter#findDestroyMethod, Line 261
org.springframework.beans.factory.support.DisposableBeanAdapter#determineDestroyMethod, Line 250
org.springframework.beans.factory.support.DisposableBeanAdapter#<init>, Line 120
org.springframework.beans.factory.support.AbstractBeanFactory#registerDisposableBeanIfNecessary, Line 1857

Is there another instance of this problem?

[snicoll]

Thanks for sharing that. It's unrelated to this specific issue and affects any use of a destroy method. I've created #29077