SONARJAVA-6491: Implement S8911 - Methods annotated with @Startup should be non-static, non-producer, and parameter-free

[romainbrenguier]

Summary

This PR implements rule S8911 to detect methods annotated with @Startup (from io.quarkus.runtime.Startup) that violate CDI initialization requirements by being static, having parameters, or being annotated with @Produces.

Rule Behavior

The rule detects methods annotated with @Startup that:

1. Are declared as static (static methods cannot be managed by CDI lifecycle)
2. Have one or more parameters (framework cannot provide arguments during automatic invocation)
3. Are annotated with @Produces (producer methods serve a different purpose than initialization)

Implementation Approach

The implementation follows the pattern established by ScheduledOnlyOnNoArgMethodCheck (S7184):

1. Extends IssuableSubscriptionVisitor to subscribe to Tree.Kind.METHOD nodes
2. For each method, checks if it has the @Startup annotation (io.quarkus.runtime.Startup)
3. If @Startup is present, checks for three violations:
   • Method is static (using methodTree.symbol().isStatic())
   • Method has parameters (using !methodTree.parameters().isEmpty())
   • Method has @Produces annotation (checking for jakarta.enterprise.inject.Produces)
4. Reports issues with descriptive messages indicating which requirement is violated
5. Includes secondary locations pointing to the @Startup annotation for context

Test Coverage

The test file covers:

Noncompliant patterns:

• Static method with @Startup
• Method with @Startup and parameters
• Method with both @Startup and @Produces
• Multiple violations on same method (static + parameters, static + producer, etc.)

Compliant patterns:

• Non-static, parameter-free method with @Startup (valid usage)
• Methods using dependency injection (@Inject fields) instead of parameters
• Methods without @Startup annotation (static, producer, or parameterized methods are OK)
• Private methods with @Startup (access level doesn't matter for this rule)

Additional Changes

• Added mock io.quarkus.runtime.Startup annotation in java-checks-test-sources/default/src/main/java/io/quarkus/runtime/Startup.java following the pattern used for other external dependencies (similar to io.realm.RealmConfiguration)
• Test sample uses existing Jakarta dependencies (jakarta.enterprise.cdi-api and javax.inject) already available in the test sources pom

Resources

• Quarkus Application Lifecycle Guide
• Jakarta CDI Specification

🤖 Generated with Claude Code

[hashicorp-vault-sonar-prod]

SONARJAVA-6491

[gitar-bot]

💡 Quality: S6813 false-negative baseline increased (65->66) without explanation

diff_S6813.json records an increase in falseNegatives from 65 to 66, and a new diff_S8899.json plus the bump of rulesNotReporting from 19 to 20 are added. These are autoscan baseline changes for rules (S6813, S8899) that are unrelated to the S8911 feature this PR claims to implement.

The +1 false negative for S6813 likely stems from the new test sources added for S8911 (e.g. the mock io.quarkus.runtime.Startup / Jakarta test sample) introducing a Spring/CDI construct that S6813 no longer detects in no-binaries (autoscan) mode. This is plausibly a legitimate baseline update, but the commit message only mentions "updated autoscan test baselines" without explaining the root cause. Please confirm the new false negative is expected behavior (a true autoscan limitation) and not an actual regression introduced by the added test code, and document the reason in the PR.

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

[gitar-bot]

Code Review 👍 Approved with suggestions 3 resolved / 4 findings

Implements rule S8911 to enforce CDI requirements for @Startup methods with comprehensive test coverage. Address the unexplained increase in the S6813 false-negative baseline.

💡 Quality: S6813 false-negative baseline increased (65->66) without explanation

📄 its/autoscan/src/test/resources/autoscan/diffs/diff_S6813.json:4 📄 its/autoscan/src/test/resources/autoscan/diffs/diff_S8899.json:1-6 📄 its/autoscan/src/test/java/org/sonar/java/it/AutoScanTest.java:201

diff_S6813.json records an increase in falseNegatives from 65 to 66, and a new diff_S8899.json plus the bump of rulesNotReporting from 19 to 20 are added. These are autoscan baseline changes for rules (S6813, S8899) that are unrelated to the S8911 feature this PR claims to implement.

The +1 false negative for S6813 likely stems from the new test sources added for S8911 (e.g. the mock io.quarkus.runtime.Startup / Jakarta test sample) introducing a Spring/CDI construct that S6813 no longer detects in no-binaries (autoscan) mode. This is plausibly a legitimate baseline update, but the commit message only mentions "updated autoscan test baselines" without explaining the root cause. Please confirm the new false negative is expected behavior (a true autoscan limitation) and not an actual regression introduced by the added test code, and document the reason in the PR.

✅ 3 resolved

✅ Bug: S8911 not added to Sonar_way_profile.json

📄 sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S8911.json:3-15
The new rule S8911 has "status": "ready" and "defaultSeverity": "Critical" in S8911.json, but the key "S8911" was never added to the checked-in Sonar_way_profile.json rule list. As a result the rule will be shipped but will not be activated in the default "Sonar way" quality profile, so it will never fire for users relying on that profile. The existing profile test (JavaSonarWayProfileTest) only asserts a minimum rule count, so this omission is not caught by tests. Add "S8911" to the ruleKeys array in Sonar_way_profile.json (in the correct sorted position) so the new rule is enabled by default like other ready/critical rules.

✅ Quality: activateLicense() removed only from AutoScanTest, inconsistent with other ITs

📄 its/autoscan/src/test/java/org/sonar/java/it/AutoScanTest.java:66
The delta removes .activateLicense() from the OrchestratorRule builder in AutoScanTest, while keeping .setEdition(ENTERPRISE_LW). Other integration-test suites that target the same ENTERPRISE_LW edition still call .activateLicense() (e.g. its/plugin/tests/.../JavaTestSuite.java:68, CacheEnabledTest.java:69, JspTest.java:57,62, its/ruling/.../JavaRulingTest.java:110).

If activateLicense() is genuinely no longer required (e.g. the license is now injected via environment/CI), the same removal should be applied consistently across all ENTERPRISE_LW suites; otherwise this divergence is confusing and may indicate the AutoScanTest will silently fail to obtain enterprise features in some environments. Please confirm the removal is intentional and align the other suites, or restore the call.

✅ Quality: Build artifacts (MANIFEST.MF, .class files) committed to source control

📄 sonar-java-plugin/META-INF/MANIFEST.MF:1-8
This commit accidentally adds generated build output to the repository instead of source files:

• sonar-java-plugin/META-INF/MANIFEST.MF (contains a placeholder Build-Time: _, a hardcoded Implementation-Build commit hash, and a snapshot version)
• sonar-java-plugin/org/sonar/java/CheckListGenerator.class
• sonar-java-plugin/org/sonar/java/CheckListGenerator$Metadata.class
• sonar-java-plugin/org/sonar/java/GeneratedCheckList.class
• sonar-java-plugin/org/sonar/java/package-info.class

I verified these are now tracked by git (git ls-files) and are not covered by .gitignore (git check-ignore returns non-zero). These files are produced by the Maven build (JAR plugin / compilation) and land in non-standard locations (sonar-java-plugin/META-INF/ and sonar-java-plugin/org/, not under target/), which strongly suggests they were committed by mistake while fixing CI locally. Committing build output bloats the repo, will cause spurious diffs/merge conflicts on every build, and the embedded commit hash/version will quickly go stale.

Suggested fix: remove these files from the commit (git rm --cached) and add the offending paths to .gitignore so they are not re-added. None of them are needed for the S8911 rule implementation.

🤖 Prompt for agents

Code Review: Implements rule S8911 to enforce CDI requirements for @Startup methods with comprehensive test coverage. Address the unexplained increase in the S6813 false-negative baseline.

1. 💡 Quality: S6813 false-negative baseline increased (65->66) without explanation
   Files: its/autoscan/src/test/resources/autoscan/diffs/diff_S6813.json:4, its/autoscan/src/test/resources/autoscan/diffs/diff_S8899.json:1-6, its/autoscan/src/test/java/org/sonar/java/it/AutoScanTest.java:201

   `diff_S6813.json` records an increase in `falseNegatives` from 65 to 66, and a new `diff_S8899.json` plus the bump of `rulesNotReporting` from 19 to 20 are added. These are autoscan baseline changes for rules (S6813, S8899) that are unrelated to the S8911 feature this PR claims to implement.
   
   The +1 false negative for S6813 likely stems from the new test sources added for S8911 (e.g. the mock `io.quarkus.runtime.Startup` / Jakarta test sample) introducing a Spring/CDI construct that S6813 no longer detects in no-binaries (autoscan) mode. This is plausibly a legitimate baseline update, but the commit message only mentions "updated autoscan test baselines" without explaining the root cause. Please confirm the new false negative is expected behavior (a true autoscan limitation) and not an actual regression introduced by the added test code, and document the reason in the PR.

Options

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

Comment with these commands to change:

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