This is a feature request.

As a developer, I want to use Spring's powerful annotation utility classes (e.g. AnnotationUtils, MergedAnnotations) outside of Spring projects, in order to handle meta annotations and annotations in parent classes, interfaces and methods the same way as is possible in Spring.

Background information: - Spring's annotation handling classes are quite powerful. It would be useful to be able to use them outside of a Spring context, e.g. in native Java + AspectJ projects or wherever. - Currently, this is impossible because the corresponding classes are quite entangled into Spring Core. - A while ago (about 10 months ago), I tried to find out how difficult it would be to extract them. Result: It is quite difficult, but possible. I successfully extracted them in two variants: with and without Kotlin support. See this project, which I remembered just lately, and its read-me. The latter also explains how I did it. - Lately, one of the Spring committers asked the AspectJ team (I am a member) about meta annotation support in AspectJ, see * https://github.com/eclipse/org.aspectj/issues/81 and * https://github.com/spring-projects/spring-framework/issues/27221. - I also sometimes answer questions on StackOverflow which are related to meta annotations, e.g. this one. Usually I try to solve the problems presented there in a way not relying on the spring annotation utils, so the resulting aspects can also be migrated to native AspectJ and re-used in other projects.

Even outside of any Spring or AspectJ context, Spring's advanced annotation handling would come in handy in many situations totally unrelated to AOP. Therefore, I would be quite happy if this functionality could be factored out of Spring Core in order to function without any spring dependencies. Spring Core of course would continue to depend on the new library. I believe that Spring itself would improve with regard to separation of concerns and modularisation. Other advantages would be that it could be tested independently and that community contributions would become easier.

Comment From: kriegaex

@sbrannen, I am addressing you specifically, because we might be on the same page here. I hope, you agree that there is possible synergy between Spring (AOP) and AspectJ. I also hope, you buy into my reasoning concerning general benefits of having this as a separate component/library.

Comment From: snicoll

Thanks for the suggestion but we have no desire to extract part of spring-core in a separate project. This was already discussed when JUnit 5 was in the works and declined.

Comment From: kriegaex

Thanks for this feedback after two years.

I am actually disappointed by the response, because I already showed in an example project how it could be done. That artifact is useful even outside of Spring. I also did not mean that you ought to extract it into a separate project altogether, only a separate Spring module/dependency, not depending on anything else that Java API. That artifact could be consumed by both Spring and non-Spring users. It could even be anhanced by Spring-specific code in another module depending on it or by extending the base module or some of its classes.

The functionality to handle annotations the way Spring does is pretty much generic. Why does it have to be tangled with other Spring code? What about the single-responsibility principle? One module shoulddo one thing, one thing only and do it well.

Another advantage of factoring it out into its own module would be that it could be tested separately from the rest of Spring Core, maintained separately etc. It would also be much easier for non-Spring contributors to fix bugs or add new features without in-depth knowledge of Spring internals, i.e. it would attract more community collaboration. This is why and how OSS development works: You give the community something useful and reap the benefit of that same community contributing back.

This was already discussed when JUnit 5 was in the works and declined.

Actually, I am not sure I understand how this is related to JUnit 5 in any way.

Comment From: snicoll

Sorry you are disappointed about the decision but that's the team's decision and this was carefully considered when the JUnit team had the same request back then. We don't need you to show how us how it can be done, as we've already explored those various options as I've mentioned.

Comment From: kriegaex

I have no way of knowing what the JUnit team suggested, because you didn't link to any issue, PR or mailing list thread. Hence my verbose reply.