SONARJAVA-6721 Extend rule S2442 to more "java.util.concurrent" objects

[NoemieBenard]

---

Summary by Gitar

• New checks:
  • Implemented SynchronizedOnConcurrentObjectCheck (S9141) to detect synchronized blocks on java.util.concurrent objects
• Tests and documentation:
  • Added rule metadata, HTML documentation, JSON definition, test samples, and verifier tests for S9141

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-6721

[romainbrenguier]

Could we also test withoutSemantic? In preparation for getting rid of autoscan.

✅ All code review findings resolved.

_{Configure merge blocking}

[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

[github-actions]

This PR is stale because it has been open 7 days with no activity. If there is no activity in the next 7 days it will be closed automatically

[gitar-bot]

Code Review ✅ Approved 3 resolved / 3 findings

Extends rule S2442 to detect synchronized blocks across all java.util.concurrent objects and updates the rule documentation and metadata accordingly. No issues found.

✅ 3 resolved

✅ Edge Case: Rule flags all java.util.concurrent types, not just sync primitives

📄 java-checks/src/main/java/org/sonar/java/checks/SynchronizedOnConcurrentObjectCheck.java:48-54
isFromConcurrentPackage matches any type whose FQN starts with java.util.concurrent., so synchronized on concurrent collections (e.g. ConcurrentHashMap, CopyOnWriteArrayList, ConcurrentLinkedQueue) or utility types (Future, TimeUnit, ThreadLocalRandom) is also reported. Externally locking such objects is occasionally a legitimate pattern, so this may produce false positives beyond the synchronization primitives the RSPEC emphasizes. If the intent is truly the whole package this is fine; otherwise consider restricting to the lock/semaphore/latch/barrier/queue subtypes and adding compliant test cases for concurrent collections to document the intended scope.

✅ Quality: S2442 rule metadata not updated for extended scope

📄 java-checks/src/main/java/org/sonar/java/checks/SynchronizedOnConcurrentObjectCheck.java:30 📄 java-checks/src/main/java/org/sonar/java/checks/SynchronizedOnConcurrentObjectCheck.java:60-64
This PR re-points the check to rule S2442 and extends it to flag Semaphore, CountDownLatch, CyclicBarrier, atomics, blocking queues, etc., but S2442.json/html still only describe synchronizing on a "Lock" object (title: "Synchronizing on a "Lock" object should be avoided", HTML shows only a Lock example). Users now get issues on non-Lock concurrent types with documentation that doesn't cover them. Update the S2442 title and HTML (why/noncompliant/compliant examples) to reflect the full set of java.util.concurrent synchronization primitives the check reports.

✅ Bug: without-semantic test expects issues the check cannot raise

📄 java-checks/src/test/java/org/sonar/java/checks/SynchronizedOnConcurrentObjectCheckTest.java:34-41 📄 java-checks/src/main/java/org/sonar/java/checks/SynchronizedOnConcurrentObjectCheck.java:49-63
SynchronizedOnConcurrentObjectCheck decides entirely on expression.symbolType() / fullyQualifiedName() / superTypes(), which resolve to the unknown type when semantics are disabled, so the check raises zero issues in this mode. But test_without_semantic calls .verifyIssues() on the sample file, whose 12 // Noncompliant comments are still parsed as expected issues, so verification fails with "No issue raised. At least one issue expected". Change the assertion to .verifyNoIssues(), which is the correct idiom for verifying a semantics-dependent check behaves gracefully without semantics.

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