SpringBoot Fix possible type pollution in ConditionEvaluationReport

Hi,

I've been playing around with the https://github.com/RedHatPerf/type-pollution-agent from @franz1981 and found one case in Spring-Boot that caught my eye. On a vanilla app startup the output shows the following:

--------------------------
Type Pollution Statistics:
--------------------------
1:  org.springframework.beans.factory.support.DefaultListableBeanFactory
Count:  350
Types:
    org.springframework.beans.factory.config.ConfigurableListableBeanFactory
    org.springframework.beans.factory.config.ConfigurableBeanFactory
    org.springframework.beans.factory.BeanFactory
    org.springframework.beans.factory.HierarchicalBeanFactory
    org.springframework.beans.factory.ListableBeanFactory
    org.springframework.beans.factory.support.BeanDefinitionRegistry
    org.springframework.beans.factory.config.SingletonBeanRegistry
Traces:
    org.springframework.boot.autoconfigure.condition.ConditionEvaluationReport.find(ConditionEvaluationReport.java:171)
        class: org.springframework.beans.factory.config.ConfigurableListableBeanFactory
        count: 156
    org.springframework.boot.autoconfigure.condition.ConditionEvaluationReport.find(ConditionEvaluationReport.java:170)
        class: org.springframework.beans.factory.config.ConfigurableBeanFactory
        count: 150

On another much much bigger app of mine it's still TOP 13:

13:     org.springframework.beans.factory.support.DefaultListableBeanFactory
Count:  3795
Types:
        org.springframework.beans.factory.config.ConfigurableBeanFactory
        org.springframework.beans.factory.config.ConfigurableListableBeanFactory
        org.springframework.beans.factory.HierarchicalBeanFactory
        org.springframework.beans.factory.ListableBeanFactory
        org.springframework.beans.factory.BeanFactory
        org.springframework.beans.factory.support.BeanDefinitionRegistry
        org.springframework.beans.factory.config.AutowireCapableBeanFactory
        org.springframework.beans.factory.config.SingletonBeanRegistry
Traces:
        org.springframework.boot.autoconfigure.condition.ConditionEvaluationReport.find(ConditionEvaluationReport.java:171)
                class: org.springframework.beans.factory.config.ConfigurableListableBeanFactory
                count: 1635
        org.springframework.boot.autoconfigure.condition.ConditionEvaluationReport.find(ConditionEvaluationReport.java:170)
                class: org.springframework.beans.factory.config.ConfigurableBeanFactory
                count: 1566

Imho, the (unlikely but) possible pollution here doesn't really matter in terms of performance and is neglectable. (At least I didn't see an improvement or regression in some measurements) What's weird about this is that ConditionEvaluationReport.find does an instanceof check on ConfigurableBeanFactory but casts to ConfigurableListableBeanFactory.

We have two options here, I think: - Aligning the cast ConfigurableBeanFactory - Check for ConfigurableListableBeanFactory with instanceof

Ultimately, I chose the former for this PR , because everything that ConditionEvaluationReport.get internally needs seems to be satisfied with ConfigurableBeanFactory and thus seems like the more appropriate type. But since this changes a public method, we might want to go for the instanceof check on ConfigurableListableBeanFactory instead.

Let me know what you think.

Cheers, Christoph

Comment From: wilkinsona

Thanks, @dreis2211. Irrespective of the possible type pollution, there's a bug at the moment as the cast will fail in the (unlikely) event that the ConfigurableBeanFactory isn't a ConfigurableListableBeanFactory. I would prefer to fix that by changing the instanceof rather than the public API. That will allow us to fix the bug in 2.6.x without the burden of keeping the public API backwards compatible which would require deprecating get(ConfigurableListableBeanFactory) and introducing get(ConfigurableBeanFactory) as a replacement. This deprecation and replacement would require quite a number of casts in calling code to avoid deprecation warnings.

Comment From: dreis2211

@wilkinsona Adjusted the PR accordingly.

Comment From: wilkinsona

Thanks very much, @dreis2211.