[aurelien-coet-sonarsource]

---

Summary by Gitar

• Character constant resolution:
  • Resolves char literals and char constants in string concatenations to their character values in ExpressionUtils
  • Decodes Unicode escapes before escape processing via LiteralUtils.charLiteralValue
• Security check tests:
  • Adds noncompliant samples for char operands in PubliclyWritableDirectories, FilePermissionsCheckSample, and WeakSSLContextCheckJava8
• Duplicate collection check:
  • Distinguishes char and int constants so Set.of('a', 97) is not flagged as duplicate in DuplicateImmutableCollectionArgumentsCheck
• False positive fix:
  • Marks the char-placeholder query in PreparedStatementAndResultSetCheckSample as compliant now that the frontend resolves it correctly

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-7228

[datadog-sonarsource]

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

[asya-vorobeva]

Generally LGTM, but should be merged after #6379 with fix of test uncompliant sample.

[gitar-bot]

Code Review ✅ Approved 1 closed / 1 findings

🟡 Medium risk · Resolving character constants in concatenations changes analyzer results across security and collection checks, potentially exposing missed findings or new false positives.

Resolves char literals and char constants in string concatenations to their character values, and decodes Unicode escapes before escape processing. Char literals are no longer treated as equal to int constants in the duplicate immutable collection argument check, addressing that finding. No open issues remain.

✅ 1 closed

✅ Bug: Char literals now equal int constants in duplicate-element check

📄 java-frontend/src/main/java/org/sonar/java/model/ExpressionUtils.java:257-259
After this change, resolveAsConstant turns a char literal into its promoted Integer value: 'a' becomes Integer(97) where it used to be null. DuplicateImmutableCollectionArgumentsCheck.areEquivalent compares e1.asConstant() with e2.asConstant() using equals and never checks the types of the source expressions.

So Set.of('a', 97) or Map.of('a', x, 97, y) now gets a duplicate-element/key issue. At runtime these values are a boxed Character and a boxed Integer, which are not equal, so the warning is a false positive. Char constants already had this problem before this PR, but the PR extends it to every char literal. The check's sample file has no char cases, so tests don't catch it.

Fix: in areEquivalent, treat two expressions as equivalent only when their resolved constants are equal and their symbolType()s match (or both are char/neither is char). Another option is to keep char values distinct in the resolver.

Verification Rules 2/2 met Repos 4 inspected · PRs 1 inspected

Functional validation No results

Rules 2 passed 1 not applicable

✅ Internal artifact registries
✅ Repository license compliance

Broader impact Repos 4 inspected PRs 1 inspected

Cross-repo 4 repositories inspected 0 open impacts

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

Cross-PR 1 PR inspected 0 open impacts

PR 6379: SONARJAVA-7215 Do not report S2695 when part of the query cannot be resolved 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
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube