📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/ComponentScanPackageGatherer.java:135-149
packageNameOf walks symbol.owner() until a package symbol is reached and returns its name (ComponentScanPackageGatherer.java:174-180). For an unresolved type referenced by @ComponentScan(basePackageClasses = ...) / @SpringBootApplication(scanBasePackageClasses = ...), the symbol's owner chain terminates at the root package, whose name is the empty string. The loop terminates safely (no NPE/infinite loop, verified against JSymbol/Symbols), but an empty string "" is then added to the scanned-package set, which silently represents "scan everything". This may broaden downstream scan-coverage decisions unexpectedly when classpath resolution fails. Consider filtering out null/empty package names before adding them, or guarding on symbol.isUnknown().

📄 java-checks-testkit/src/main/java/org/sonar/java/checks/verifier/internal/JavaCheckVerifier.java:99-100
In JavaCheckVerifier.java the new field is declared @VisibleForTesting private SpringContextModel springContextModel;. @VisibleForTesting documents that a member's visibility was relaxed to enable testing, but the field is private, so the annotation is misleading and serves no purpose here (the field is already exposed via the public getSpringContextModel() accessor). Remove the annotation or the private modifier to match intent.

📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/ComponentScanPackageGatherer.java:91-105 📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/ComponentScanPackageGatherer.java:151-155
In collectFromSpringBootApplication, the decision whether to fall back to the annotated class's own package is computed as useOwnPackageAsFallback = packagesCollectedAtFileLevel.isEmpty() (ComponentScanPackageGatherer.java:130). The intent, documented in the comment at lines 152-154, is to only skip the own-package fallback when packages were already collected via @ComponentScan on the same class. However, packagesCollectedAtFileLevel is a file-scoped accumulator that is only cleared in setContext/leaveFile, so it carries over state from previously-visited classes in the same compilation unit.

Consequence: a .java file containing more than one top-level class — e.g. an unrelated @ComponentScan(basePackages="x") class followed by a @SpringBootApplication class with no scan attributes — will incorrectly suppress the SpringBoot class's own-package contribution, because packagesCollectedAtFileLevel is non-empty by the time the SpringBoot class is visited (visit order depends on declaration order). Multi-class files are realistic in this domain (the PR's own test source ComponentScanWithBasePackages.java declares four annotated classes in one file).

Fix: track the component-scan packages collected for the current class only, rather than relying on the file-level set. For example, capture collectedPackages/packagesCollectedAtFileLevel size before processing the class, or have collectFromComponentScan return whether it added anything for this class, and pass that boolean into collectFromSpringBootApplication.

📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/ComponentScanPackageGatherer.java:135-149 📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/ComponentScanPackageGatherer.java:147-150 📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/ComponentScanPackageGatherer.java:182-188
This PR deliberately filters out blank package names everywhere else: @ComponentScan values are filtered in addAnnotationValueToCollectedPackages (!oString.isBlank(), !pkg.isBlank()), and scanBasePackages/scanBasePackageClasses are filtered in resolvePackage. However, the @SpringBootApplication own-package fallback bypasses this check:

return useOwnPackageAsFallback ? Collections.singletonList(classPackageName) : List.of();

classPackageName comes from packageNameOf(classSymbol), which returns the (possibly empty) package symbol name. For a @SpringBootApplication class declared in the default package, packageNameOf returns "", and that empty string is added directly to collectedPackages without a blank check. This is inconsistent with the rest of the gatherer and may pollute ProjectPackageScan with an empty package entry, which downstream prefix/containment matching could treat as matching everything. A @SpringBootApplication in the default package is unusual but legal.

Suggested fix: guard the fallback so a blank own-package name is dropped, mirroring the other paths.

📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/SpringContextModelGatherer.java:35 📄 java-frontend/src/main/java/org/sonar/java/model/springcontext/SpringContextModelGatherer.java:46-50
The class Javadoc at SpringContextModelGatherer.java:35 still states: "All gatherers are skipped when spring-context is not present in the module classpath." After this commit, isCompatibleWithDependencies also returns true for spring-beans, spring-boot-starter, and spring-boot-starter-web. The documentation is now inaccurate and should be updated to reflect that any of these Spring dependencies enables the gatherers.