Provide a variant of ListableBeanFactory.findAnnotationOnBean(String, Class<A>) that does not initialize factory beans

[wilkinsona]

Affects: 5.3.x

DefaultListableBeanFactory's implementation of findAnnotationOnBean calls getType(String) which allows factory bean init. Assuming that it's intentional for findAnnotationOnBean to initialize factory beans, would it be possible to overload the method with a variant that does not do so? This would help to fix spring-projects/spring-boot#28977 where we're looking for an annotation in a bean factory post-processor.

[scantor]

It would have been nice to have a more prominent documentation note that a patch release just broke API compatibility by adding a method to a public interface. This is a blatant violation of semantic versioning, so it also shouldn't have been done at all without a darn good (i.e. security) reason.

[jhoeller]

We generally allow for adding methods to existing interfaces at any point (in a defensive form also in maintenance releases), provided that those interfaces are APIs which are designed as facades for our own implementations - in contrast to SPIs which are meant to be implemented by user code and/or third-party integrations. Even in the case of SPIs, we occasionally introduce new methods that then come declared as default methods, not forcing existing implementors to care for the new method.

We apply semantic versioning rules for source and binary compatibility with existing callers of our APIs, as well as with existing implementors of our SPIs. Not every public interface is the same in that respect. If we enforced 100% strictness even beyond the common intended use (never adding methods to APIs - or e.g. never changing a protected signature in some internal class hierarchy of ours), we would severely constrain our own ability to evolve, in particular in long-lived branches such as 5.3.x.

There are many open source projects treating their public surface selectively, we're not the odd ones out here. If you happened to build some custom ListableBeanFactory implementations or decorators, I apologize for the inconvenience, but even then you could easily declare the new method and still remain compatible with older versions of Spring (since the existence of the new method wouldn't hurt even then, as long as pre-existing types are used as argument types and return types).

[scantor]

Is there any documentation or formalism regarding which APIs are in which category? I didn't run across it but I will check the documentation again.

[jhoeller]

Not that I'm aware of. Usually the javadoc or simply the common usage model quite clearly suggests usage as an API (that application code is calling only) versus usage as an SPI (interfaces to be implemented by specific extensions/customizations), or the also common notion of callback interfaces (to be commonly implemented in application code as part of the usage model).

Good point, in any case: We should consider introducing some dedicated indications for API versus SPI characteristics. We use interfaces rather broadly for a range of different purposes, after all, and the intended treatment isn't as obvious as it should be.

[scantor]

It would be appreciated, we can more easily make special note of any we (mis)use to watch for changes more carefully. My project has much more strict policies around versioning than most, so we get bitten a lot by these sorts of changes when we have to update dependencies for security fixes.

That's another side comment. I believe 5.3.14 was a security patch as well, which means it's not so "optional" for us to pick up that version. Maybe consider a stricter review of such changes in releases that address vulnerabilities as a general principle.

I appreciate the feedback and response in any event.