Sonar Community Roundup, October 11 - October 17

Sonar Updates
1

Hi all,

This week I was at LeadDev NYC, where I gave a talk about AI-generated code and code review—specifically how the chocolate factory scene from I Love Lucy captures what many developers are experiencing right now. It was great to connect with the community there!

As always, we want to take a moment to recognize everyone who sparked interesting discussions and gave us valuable feedback to drive continuous improvement.

SonarQube Server & Community Build:

  • Report processing failed with Unknown status: TO_REVIEW errors blocking analysis for @Floh when processing Ansible files with SARIF reports. SONAR-26020 was created to handle this case which we can now easily reproduce but still don’t fully understand. Thanks for the detailed error logs!

SonarQube Cloud:

SonarQube for IDE:

  • Issues disappear while typing in VS Code when syntax errors are introduced, as @gquerret discovered. After initially detecting 54 issues in a Java file, introducing a syntax error caused all issues to vanish rather than persist alongside the parse error. SLCORE-1770 was created to ensure issues remain visible even when code temporarily has syntax problems. Thanks for the detailed logs!

Rules & Languages Improvements:

  • Duplication detection in large switch yards is very noisy when multiple functions contain switch statements exhaustively handling all enum cases, as @Evangelos_Denaxas originally reported and @grimsa resurfaced. CPP-7134 was created to improve the detection logic. Thanks for bringing this back!

  • java:S2384 incorrectly flags Lombok’s @SuperBuilder with @Builder.Default on final fields, as @Raphiraph7 discovered. SONARJAVA-5796 was created to fix this. Thanks for the clear reproduction case!

  • java:S6814 flags optional boolean parameters in Spring controllers as requiring boxed types, as @micopiira and @grimsa noted. While the rule aims to enforce deterministic behavior, Spring already deterministically sets missing boolean parameters to false, and using Boolean adds unnecessary cognitive overhead. SONARJAVA-5794 was created to relax the rule for boolean parameters. Great discussion on the tradeoffs!

  • java:S5542 missed a false negative when weak encryption algorithms were passed through method parameters, as @RJerrica reported. The rule should have caught AES/CBC/PKCS5Padding being passed to Cipher.getInstance() but didn’t, likely due to how string states are modeled in detection logic. Action items created to fix this. Thanks for the detailed code example!

  • java:S2053 showed inconsistent behavior when detecting hard-coded salt values, as @RJerrica discovered. The rule flagged "salty".getBytes() but not the functionally equivalent byte array {115, 97, 108, 116, 121}. We’re working to improve consistency in detection. Thanks!

  • java:S4423 missed detecting weak SSL/TLS protocols in loop contexts, as @Belle reported. When weak protocols like "TLSv1.1" and "TLSv1" were used in an array iterated over in a loop, the rule didn’t flag them. This is likely due to how loops are modeled in the detection logic.Thanks for the clear reproduction!

  • typescript:S2187 incorrectly flags test files using Jest’s tagged template literal syntax as having no tests, as @kjonski reported. The rule doesn’t recognize it.each or test.each with template literal syntax, only the array syntax. JS-180 is already tracking this, and a fix PR has been created. Expect the fix in the next couple of weeks!

Thank you again to everyone mentioned—and to those we may have missed—for your ongoing contributions in making this community stronger and helping us improve Sonar products.

If you’d like to give a shout-out to someone, whether a community member or a SonarSourcer who helped you, please do so below. And if there’s someone you think we should acknowledge next week, let us know!