SONARKT-739 S6518 Add class exceptions for common user errors where operator is provided via java interop

[matthew-reid-sonarsource]

Part of

[hashicorp-vault-sonar-prod]

SONARKT-739

[sonar-review-alpha]

Summary

What changed: Rule S6518 now includes class-level exceptions for Java interop operators that should not be converted to indexed access syntax.

Previously, the rule aggressively flagged all get() and set() calls for replacement with [] syntax, including Java interop methods like Calendar.get() and CompletableFuture.get(). These are not intended to be indexed access—using calendar[YEAR] would be semantically wrong.

The fix adds logic to:

1. Detect whether a get/set call is a Java method (using KaSymbolOrigin.JAVA_SOURCE / JAVA_LIBRARY)
2. If it's Java interop, check if the type is in an allow-list of classes where indexed access is idiomatic (ByteBuffer, BitSet, AtomicIntegerArray, etc., plus any List or Map implementation)
3. Only report violations for Java interop operators on allowed types; skip everything else

This eliminates ~40 false positives across test projects (Corda, IntelliJ Rust, Kotlin, etc.) while preserving legitimate warnings for actual collection types.

Why: Java has no operator overloading syntax for get/set, so Kotlin treats all Java get() and set() methods as operators via interop. Without this distinction, the rule penalizes correct Kotlin code when developers intentionally call domain-specific Java methods.

What reviewers should know

Start here: Review IndexedAccessCheck.kt lines 30–45 (the allow-list definition) and lines 88–103 (the check logic). These are the core logic changes.

Key decisions:

• Allow-list design: Specific types (ByteBuffer, BitSet, atomic arrays, Android sparse arrays) plus any List/Map subtype. This balances precision (avoiding false positives on domain-specific types like Calendar) with coverage (catching actual collections).
• Kotlin library handling: Types from compiled Kotlin libraries (Guava, OkHttp, user libraries) with real operator fun get/set are not Java interop—they're flagged even though semantically they're operators. This is correct because it encourages idiomatic Kotlin syntax.
• Semantics dependency: The check uses KaSymbolOrigin to distinguish Java from Kotlin; without full semantics (e.g., no classpath), some concrete List/Map implementations (ArrayList, HashMap) may not be caught as false negatives—documented in test samples.

Test coverage notes:

• IndexedAccessCheckSample.kt: Four separate test methods showing all cases (Java interop excluded, Java interop allowed, Kotlin library types, Java library types with clear Compliant/Noncompliant expectations).
• IndexedAccessCheckSampleNoSemantics.kt: Mirrors the full sample but expects false negatives where the classpath is unavailable.
• Ruling files: ~40 violations removed across multiple OSS projects now that Calendar/CompletableFuture and similar no longer raise.
• JAR size adjusted from 53.4–53.9 MB to 53.5–54.0 MB to account for added symbol origin checks.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[petertrr]

Good progress, but more examples with non-stdlib dependencies are needed.

[petertrr]

LGTM!

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
91.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube