As seen in #27753, the SpringFactoriesLoader#loadFactoryNames (introduced in #15158 ) has been very useful over the years but is too permissive for our AOT and native work. Some existing use cases can use reflection in a way that's not predictable for AOT processors.

Here are three example use cases in Spring Boot: * the ConfigDataLoaders are loading ConfigDataLoader class names and are calling non-default constructors using a set of dependencies maintained locally * the ImportAutoConfigurationImportSelector is loading auto-configuration class names. * the FailureAnalyzers is using class names to create objects directly and continue in failure scenarios.

Instead of Strings, the replacement should return a different type that allows for the actual type inspection and a Supplier to get an actual instance. Maybe something similar to ServiceLoader.Provider. This proposal will probably not solve the two use cases mentioned above, so we'll need to find proper replacements in Spring Boot or provide new features in Spring Framework to support them.

Comment From: snicoll

Superseded by #28057

Comment From: snicoll

Actually the related issue doesn't deprecate the method so let's reopen this one.

Comment From: snicoll

Moving to the next milestone since we just introduce the infrastructure and we'd need to give some time for team to use it before deprecating loadFactoryByNames.

Comment From: snicoll

"Blocked" by https://github.com/spring-projects/spring-boot/issues/29699

Comment From: sbrannen

If we deprecate loadFactoryNames(), we should keep in mind that it is still actively used in spring-test in AbstractTestContextBootstrapper.getDefaultTestExecutionListenerClassNames().

getDefaultTestExecutionListenerClassNames() and getDefaultTestExecutionListenerClasses() were originally created to support custom exception handling since there was no equivalent of SpringFactoriesLoader.FailureHandler at the time.

Unfortunately, both of these methods are protected. Thus, a custom subclass of AbstractTestContextBootstrapper may rely on them.

Comment From: snicoll

Can you please create an issue to get rid of its use? 6.0 is the right time to break this contract if we have to.

Comment From: sbrannen

Can you please create an issue to get rid of its use? 6.0 is the right time to break this contract if we have to.

See:

• 28666

Comment From: sbrannen

This issue is no longer blocked by #28666.

Though I suppose it's still blocked by https://github.com/spring-projects/spring-boot/issues/29699.