fix: Report duplicate @Bean names by Spring Framework version and collision kind (#689)

[imuromtsev]

Stacked on #692 (#686): base branch imuromtsev/spring7-bean-override-rule. Merge #692 first; GitHub then retargets this PR to main.

Purpose

The duplicate @Bean name inspection (#597, unreleased) reports "fails Spring Boot startup" for every pair of @Bean methods that declare the same bean name. Probes on real spring-context jars show that this holds only from Spring Framework 6.2.0 for primary names, from 6.0 for a name that is the primary name of one method and an alias of the other, and on every version for an alias shared by both methods. Before that, Spring starts and silently ignores one of the two methods, so the error is a false positive on Spring Boot 2.x–3.3.x.

Change

The verdict is decided per collision, by its kind (the name is the primary name — the first declared @Bean name, else the method name — of both methods, of one, or of neither), the full spring-core version and spring.main.allow-bean-definition-overriding:

Collision	Spring Framework	missing / false	true	unresolvable
primary names	before 6.2.0	warning: one method is silently ignored	same	same
primary names	7, @Configuration with enforceUniqueMethods	error (#686)	error	error
primary names	unknown	warning naming both outcomes	existing warning (full class)	warning naming both outcomes
primary names	6.2.x, lite class, enforceUniqueMethods = false	error	—	warning
primary name + alias	6.0 and later	error	—	warning
primary name + alias	before 6.0 or unknown	warning: fails or ignores one method, depending on registration order	—	same warning
alias of both	any	error	—	warning

• The Spring 7 rule of Duplicate @Bean name inspection is silent on Spring 7 when bean definition overriding is allowed #686 applies to primary names only: on Spring 7 with overriding allowed an alias collision starts.
• New SpringBootUtil.getSpringCoreVersion (cached like the major version, which now derives from it).
• The inspection description and the unreleased Inspection: two @Bean methods with the same bean name in one configuration class fail Spring Boot startup #597 CHANGELOG line describe the rule; the line now ends (#597, #686, #689).

Framework evidence

Probes with AnnotationConfigApplicationContext, one configuration class:

Pair	5.3.31	6.0.11	6.1.13	6.2.0	6.2.1+	7.0.9
@Bean a() + @Bean("a") b(), overriding disallowed	starts, one method ignored	starts	starts	fails	fails	fails
same, overriding allowed	starts	starts	starts	starts	starts	fails (full @Configuration)
@Bean({"a","svc"}) x() + @Bean("svc") y(), disallowed	starts	fails	fails	fails	fails	fails
same, allowed	starts	starts	starts	starts	starts	starts
{"a","svc"} + {"b","svc"}, disallowed	fails	fails	fails	fails	fails	fails

Lite classes (@Component with @Bean methods) behave like full @Configuration classes before 6.2.0.

Verification

• Red commits 6a82ea0, d9d4ea3, afb0e8b, ba4a87d (Java and Kotlin twins; fixtures by full spring-core version: Boot 2.7.18 → 5.3.31, 3.1.1 → 6.0.10, 3.4.0 → 6.2.0, 4.1.0 → 7.0.8, and a spring-core jar without coordinates for an unknown version), each failing on its severity or message assertion.
• After the fixes: 104/104 SpringDuplicateBeanName* tests.
• All modules (:spring-bootstrap:test --rerun-tasks on f923cdc, fresh JUnit XML): spring-core 2463, spring-web 905 (6 skipped), spring-ai 776, spring-data 140, jpa 138, base 35, aop 6, security 6, initializr 5 — 0 failures except one Exodus ThreadLeakTracker leak assertion in SpringBootApplicationMcpToolsetTraceFunctionalRouteTest, which passed 40/40 when rerun alone (known flake).

Main only: the inspection (#669) is not on the release branches.

Follow-ups

• With overriding allowed, Spring 5.3–6.2.x silently keeps one of the two methods and nothing is reported.

Closes #689

[github-actions]

	Tests	Passed ✅	Skipped ⚠️	Failed
JUnit Test Report	4474 ran	4468 passed	6 skipped	0 failed

• View JUnit Test Report