SONARJAVA-6412 Implement Visitor for grouping beans per types

[NoemieBenard]

---

Summary by Gitar

• New features:
  • Added TypeToBeanNamesIndexGatherer to map type hierarchies of Spring beans to bean names
• Refactorings:
  • Extracted Spring bean and method name resolution helpers into SpringUtils
• Tests:
  • Added comprehensive unit tests in TypeToBeanNamesIndexGathererTest covering stereotype and @Bean methods

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-6412

[asya-vorobeva]

The logic for filling index looks correct. Please move it to existing gatherer and rename it.

[asya-vorobeva]

What's the point of implementing this visitor as separated one? We can fill needed data in existing BeanDefinitionGatherer as we already have all the needed machinery there.

[asya-vorobeva]

💯

[gitar-bot]

Code Review ✅ Approved 8 resolved / 8 findings

Implements TypeToBeanNamesIndexGatherer to map Spring bean types and extracts resolution helpers into SpringUtils, addressing multiple null-guard, caching, and constructor injection findings.

✅ 8 resolved

✅ Edge Case: resolveStereotypeBeanName lacks null-guard on annotation value

📄 java-frontend/src/main/java/org/sonar/java/utils/SpringUtils.java:105-109 📄 java-frontend/src/main/java/org/sonar/java/utils/SpringUtils.java:134
In SpringUtils.resolveStereotypeBeanName the stream does .map(v -> (String) v.value()) followed by .filter(s -> !s.isBlank()) with no null check, so a null annotation value would throw NPE. The sibling method resolveBeanMethodName guards this with s != null && !s.isBlank(). Although a null value is unlikely from the semantic model, make the two methods consistent by filtering nulls (e.g. .filter(s -> s != null && !s.isBlank())).

✅ Quality: @Bean/stereotype name aliases beyond the first are dropped

📄 java-frontend/src/main/java/org/sonar/java/utils/SpringUtils.java:122-136 📄 java-frontend/src/main/java/org/sonar/java/utils/SpringUtils.java:101-115 📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/TypeToBeanNamesIndexGatherer.java:55-64
resolveBeanMethodName returns only arr[0] for @Bean(name={"a","b"}), and resolveStereotypeBeanName returns a single name. Spring treats additional entries as bean aliases, so the type-to-bean-names index will not contain those aliases and lookups by an alias name will miss the bean. If alias-based resolution is in scope for this index, register all names; otherwise this is acceptable and could be documented.

✅ Edge Case: extractBeanName drops null-guard on annotation value

📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/BeanDefinitionGatherer.java:257-261
extractBeanName maps (String) v.value() then filters with .filter(s -> !s.isBlank()), which throws NPE if the annotation value is null. This re-introduces the exact defect previously fixed in SpringUtils.resolveStereotypeBeanName, which guards with s != null && !s.isBlank() (and the sibling @bean logic at lines 287 correctly keeps s != null). Add the null check for consistency and safety.

✅ Quality: Bean-name resolution duplicated instead of reusing SpringUtils

📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/BeanDefinitionGatherer.java:253-267
extractBeanName/defaultBeanName and the inline @bean name logic reimplement what SpringUtils.resolveStereotypeBeanName and resolveBeanMethodName already do. TypeToBeanNamesIndexGatherer still resolves bean names via those SpringUtils helpers, so the two gatherers now have separate code paths that must stay in sync — if they diverge, bean names in the registry won't match names indexed by type (as already happened with the dropped null-guard above). Consider delegating to the shared SpringUtils methods to keep both gatherers consistent.

✅ Edge Case: Single-constructor injection skipped when any other dep exists

📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/BeanDefinitionGatherer.java:329-343
The implicit single-constructor injection is only applied when deps.isEmpty(), so a @Component that has both an @Autowired field (or @Autowired setter) and a single non-default constructor gets its constructor parameters dropped from dependingBeans — Spring injects both in that case. Trigger: @Component class A { @Autowired Foo foo; A(Bar bar) {...} } yields only the Foo edge, silently losing the Bar dependency from the model other rules will consume. Collect the single unannotated constructor's parameters unconditionally (only skipping when a constructor/method is already @Autowired), instead of gating on deps.isEmpty().

...and 3 more resolved from earlier reviews

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
44 Dependency risks
91.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube