[leveretka]

SONARJAVA-7229: Java analyses currently expose a type-error total without an affected-file denominator or configuration context. Cache-only analyses can also appear healthy despite having no new semantic observations.

Add counters for evaluated and affected files/modules, resolution diagnostics excluding preview-feature diagnostics, cached files, and file processing outcomes. Record main/test classpath configuration signals for missing properties, no resolved entries, unmatched patterns, and invalid JDK fallback. Aggregate through the existing project telemetry pipeline; retain the existing type-error counter unchanged.

Metric definitions and interpretation are documented in docs/semantic-model-telemetry.md. These signals identify observed degradation and possible causes; zero observations remain unobserved. The first iteration does not measure every binding, inspect bytecode freshness, or report telemetry from scanner runs that abort before project-end submission. No source paths, type names, or diagnostic messages are transmitted.

Validation:

• Focused frontend/component/classpath/telemetry suite: 230 tests, no failures, one existing skip.
• Java sensor and project-end telemetry suite: 21 tests, no failures.
• CI passed at 3d1c7cd4e9: Windows unit tests, Plugin QA (including multi-module telemetry), all Linux/Windows ruling jobs, sanity, analysis, and license/security checks. Integration/ruling tests were not run locally.
• SonarQube quality gate passed: no new issues, 99.1% coverage on new code, and no new duplication.

No analyzer rule behavior or configuration requirements change.

[hashicorp-vault-sonar-prod]

SONARJAVA-7229

[gitar-bot]

💡 Quality: generated.cached_file_count key is defined but never emitted

JAVA_ANALYSIS_GENERATED_CACHED_FILE_COUNT is added and wired into JAVA_ANALYSIS_GENERATED, but the only caller of cachedFileCountKey() is JavaAstScanner.scanWithoutParsing. JavaFrontend.scan only calls that on astScanner (main) and astScannerForTests (test). Generated files are added to the cache total and never go through the cache, so java.analysis.generated.cached_file_count is never sent. The doc describes cached_file_count under java.analysis.<scope>. for all three scopes and says it "is emitted when that optimization is attempted". A consumer would reasonably expect the generated key to show up in cache-enabled runs, and it never does. Either remove the generated cached key (pass a null or no-op key), or say in the doc that cached_file_count only covers main and test.

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

[datadog-sonarsource]

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3d1c7cd | Docs | Give us feedback!}

[gitar-bot]

Code Review 👍 Approved with suggestions 0 closed / 1 findings

🟡 Medium risk · Adding semantic and classpath telemetry counters changes project-end data collection; aggregation errors could misrepresent Java analysis degradation or configuration.

Adds project-end telemetry for Java semantic degradation, including evaluated and affected file counts, resolution diagnostics, cached files, and main/test classpath configuration signals. The change is approved with suggestions. One open minor finding: the java.analysis.generated.cached_file_count key is defined and wired but never emitted, because generated files bypass the cache path. Either remove that key or document that cached_file_count only covers main and test.

💡 Quality: generated.cached_file_count key is defined but never emitted

📄 java-frontend/src/main/java/org/sonar/java/telemetry/TelemetryKey.java:68 📄 java-frontend/src/main/java/org/sonar/java/telemetry/TelemetryKey.java:165 📄 java-frontend/src/main/java/org/sonar/java/JavaFrontend.java:128-142 📄 java-frontend/src/main/java/org/sonar/java/ast/JavaAstScanner.java:89 📄 docs/semantic-model-telemetry.md:23

JAVA_ANALYSIS_GENERATED_CACHED_FILE_COUNT is added and wired into JAVA_ANALYSIS_GENERATED, but the only caller of cachedFileCountKey() is JavaAstScanner.scanWithoutParsing. JavaFrontend.scan only calls that on astScanner (main) and astScannerForTests (test). Generated files are added to the cache total and never go through the cache, so java.analysis.generated.cached_file_count is never sent. The doc describes cached_file_count under java.analysis.<scope>. for all three scopes and says it "is emitted when that optimization is attempted". A consumer would reasonably expect the generated key to show up in cache-enabled runs, and it never does. Either remove the generated cached key (pass a null or no-op key), or say in the doc that cached_file_count only covers main and test.

🤖 Prompt for agents

Code Review: Adds project-end telemetry for Java semantic degradation, including evaluated and affected file counts, resolution diagnostics, cached files, and main/test classpath configuration signals. The change is approved with suggestions. One open minor finding: the `java.analysis.generated.cached_file_count` key is defined and wired but never emitted, because generated files bypass the cache path. Either remove that key or document that `cached_file_count` only covers main and test.

1. 💡 Quality: generated.cached_file_count key is defined but never emitted
   Files: java-frontend/src/main/java/org/sonar/java/telemetry/TelemetryKey.java:68, java-frontend/src/main/java/org/sonar/java/telemetry/TelemetryKey.java:165, java-frontend/src/main/java/org/sonar/java/JavaFrontend.java:128-142, java-frontend/src/main/java/org/sonar/java/ast/JavaAstScanner.java:89, docs/semantic-model-telemetry.md:23

   `JAVA_ANALYSIS_GENERATED_CACHED_FILE_COUNT` is added and wired into `JAVA_ANALYSIS_GENERATED`, but the only caller of `cachedFileCountKey()` is `JavaAstScanner.scanWithoutParsing`. `JavaFrontend.scan` only calls that on `astScanner` (main) and `astScannerForTests` (test). Generated files are added to the cache total and never go through the cache, so `java.analysis.generated.cached_file_count` is never sent. The doc describes `cached_file_count` under `java.analysis.<scope>.` for all three scopes and says it "is emitted when that optimization is attempted". A consumer would reasonably expect the generated key to show up in cache-enabled runs, and it never does. Either remove the generated cached key (pass a null or no-op key), or say in the doc that cached_file_count only covers main and test.

Verification Rules 2/2 met Repos 4 inspected

Functional validation No results

Rules 2 passed 1 not applicable

✅ Internal artifact registries
✅ Repository license compliance

Broader impact Repos 4 inspected

Cross-repo 4 repositories inspected 0 open impacts

SonarSource/sonar-java-symbolic-execution Inspected
SonarSource/sonarlint-intellij Inspected
SonarSource/sonarlint-vscode Inspected
SonarSource/sonarlint-language-server Inspected

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

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

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
99.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube