SONARJAVA-6912 Recognize @Inject constructor selection

[erwan-leforestier-sonarsource]

Summary

Updates S6829 so Spring components with a constructor selected by javax.inject.Inject or jakarta.inject.Inject are compliant. The issue message and generated rule description now describe both supported annotations.
RSPEC PR: https://github.com/SonarSource/rspec/pull/8141

Changes

• Recognize @Inject alongside @Autowired on constructors
• Cover javax.inject and jakarta.inject constructor annotations
• Regenerate the S6829 rule metadata and description

[hashicorp-vault-sonar-prod]

SONARJAVA-6912

[gitar-bot]

Code Review ✅ Approved 4 resolved / 4 findings

Extends S6829 to recognize @Inject constructors alongside @Autowired, but silently widens S3305 scope without updating its RSPEC documentation—users will see @Inject issues on fields that the shipped rule description does not mention. Additionally, the refactored loop logic defeats the documented required=false default-value exception, causing false positives when @Inject and @Autowired(required = false) co-annotate a field. Update S3305 RSPEC and regenerate metadata, and restore per-field exception evaluation to prevent false positives.

✅ 4 resolved

✅ Bug: S6829 now accepts @Inject but S6818 still only sees @Autowired

📄 java-checks/src/main/java/org/sonar/java/checks/spring/AutowiredOnConstructorWhenMultipleConstructorsCheck.java:59-64
S6829 now treats any constructor carrying @Autowired, javax.inject.Inject or jakarta.inject.Inject as an explicit selection, while its companion rule S6818 (AutowiredOnMultipleConstructorsCheck) still only counts @Autowired (isAutowired at line 71-77, annotation lookup at line 62-64). Concrete trigger: a @Component with two constructors both annotated @jakarta.inject.Inject (or one @Autowired plus one @Inject) — before this PR S6829 reported it, now S6829 stays silent and S6818 never fires, so a configuration that makes Spring fail at startup with "Invalid autowire-marked constructors: multiple constructors annotated" goes undetected. Extend S6818 to the same annotation set (this also needs the RSPEC message/description updated, like the S6829 change in this PR).

✅ Quality: Shared INJECTION_ANNOTATIONS not applied to remaining duplicate lists

📄 java-checks/src/main/java/org/sonar/java/checks/helpers/SpringUtils.java:50-53
The "Share Spring injection annotations" commit moved the list into SpringUtils.INJECTION_ANNOTATIONS but only migrated FieldDependencyInjectionCheck. NonSingletonAutowiredInSingletonCheck still declares a byte-identical set and consumes it with the exact same contains(fullyQualifiedName()) idiom (line 164), and SpringConfigurationWithAutowiredFieldsCheck keeps a two-element list that omits jakarta.inject.Inject, so S6798 misses field injection in Jakarta-based configurations. Point both at the new shared constant so the set has a single definition and Jakarta coverage is uniform.

✅ Quality: S3305 scope widened to @Inject but its RSPEC/description untouched

📄 java-checks/src/main/java/org/sonar/java/checks/spring/SpringConfigurationWithAutowiredFieldsCheck.java:76-86 📄 java-checks-test-sources/default/src/main/java/checks/spring/SpringConfigurationWithAutowiredFieldsCheckSample.java:20 📄 java-checks-test-sources/default/src/main/java/checks/spring/SpringConfigurationWithAutowiredFieldsCheckSample.java:22
This PR silently widens rule S3305 (SpringConfigurationWithAutowiredFieldsCheck): fields annotated with javax.inject.Inject / jakarta.inject.Inject are now reported (test sample lines 20 and 22 assert new issues), yet S3305.html and S3305.json still describe the rule purely in terms of @Autowired, and the linked RSPEC PR (rspec#8141) plus the PR description only cover S6829. Users will get issues on code the shipped rule description does not describe. Either update the S3305 RSPEC (and regenerate S3305.html/json) alongside the S6829 change, or keep the S3305 behaviour change out of this PR.

✅ Edge Case: required=false default-value exception defeated by co-annotation

📄 java-checks/src/main/java/org/sonar/java/checks/spring/SpringConfigurationWithAutowiredFieldsCheck.java:76-86
Turning the single-annotation lookup into a loop changed the early return into continue, so the documented exception for the default-value pattern is now per-annotation instead of per-field: a field such as @Inject @Autowired(required = false) private Bar bar = new Bar(); skips the @Autowired iteration but is then added by the @Inject iteration (valuesForAnnotation returns an empty non-null list for a value-less annotation), producing a false positive on the very pattern lines 81-83 intend to exempt. Evaluate the exception once for the whole field and only register it when no injection annotation opted out.

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 Fixed issues
0 Accepted issues

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

See analysis details on SonarQube

[asya-vorobeva]

💯