Reporting against SonarQube Server Data Center Edition v2025.4.2 (112048)
kotlin:S6519 recommends replacing calls to the .equals() method with the == and != operators for testing structural equality. This is valid normally, but not when the .equals(ignoreCase=true) variant is used for testing string equality, e.g. “A”.equals(“a”,ignoreCase=true)
There is no operator equivalent for string comparisons ignoring case.
Here are example lines from our codebase that trigger the rule:
val isEligible = "A".equals (policy.homeRentersCondoEligibility, ignoreCase = true)
Reports as kotlin:S6519 Replace “equals” with binary operator “==”.
val shouldShowHomeownersNotRenters = !“A”.equals(policy.renterQuoteAvailability, ignoreCase = true)
Reports as kotlin:S6519 Replace “!” and “equals” with binary operator “!=”.
In both cases, the use of ignoreCase = true means switching to the suggested operator would change the meaning of the comparison. kotlin:S6519 should not trigger if the ignoreCase variant of .equals is being used.
Thanks for the report. This behavior indicates that the analysis is missing some semantic information and as a result is resolving the equals call incorrectly. By providing the analyzer with the corresponding semantic information, you can improve the quality of the analysis overall. How are you currently launching the analysis?
That being said, I agree that it is not a great experience to see false positives, even if some semantic information may be missing. I will investigate possibilities to improve the behavior in this case.
The analysis is being launched as part of an ADO pipeline that builds and runs unit tests prior to triggering the analysis step.
Not sure what additional semantic information would be needed? This seems like all the information needed for the analysis is present in the local context, i.e. is .equals() being called with ignoreCase=true parameter or not.
The analyzer needs the compiled binaries as a reference to be able to infer semantic information about the code. Depending on how the scan is triggered, this may be automatically configured or requires a manual property (sonar.java.binaries) to be set.
The SonarScanner for Gradle is typically able to pick this up by itself. So as long as the project is compiled when launching the scan and the binaries can be found in sourceSets.main.output.classesDir, you usually don’t need to perform any additional configuration.
If you use the SonarScanner CLI, you will need to set the aforementioned property manually to point to the directories where your binaries can be found.
If you are using the Sonar Azure DevOps Extension, to scan a Gradle project, I’d recommend to set the scannerMode to other and the scan launched via Gradle.