Hello Community!
Another week, another roundup. We saw a couple interesting announcements this week! If you’re a Rustacean [sic], you might be interested in these recent improvements to the Rust analyzer! And if you/your AI agent is using SonarQube CLI, then don’t hesitate to upgrade to the new version to streamline even more your development workflow.
So now, like every week, we’d like to take a moment to recognize you, the users, who help improve the ecosystem for everyone by sparking valuable discussions and providing feedback to drive continuous improvement in our products.
SonarQube for IDE
@r-mennig noticed that when Autobuilding is disabled in SonarQube for Eclipse, the “results may be inaccurate” popup could appear more than once because of a race between async notifications. @fedejeanne chimed in to confirm the fix follows standard SWT practice, thanks for the sharp analysis! The fix already shipped in the latest release, see SLE-1609 for the details.
SonarQube Cloud
@milbrandt pointed out that Dependency Risks weren’t showing up in the favorite projects view on SonarQube Cloud, even though they were already visible in the portfolio view. We merged a fix and it’s live now, thanks for flagging it!
SonarQube Server / Community Build
Hovering over the project overview graph in SonarQube Community Build showed a tooltip in the wrong spot, popping up at the top of the page instead of next to the mouse, as @gian1200 flagged. We’re tracking the fix in SONAR-32324.
@magyarimiki spotted that the loading screen still flashes white for a moment in dark mode, right when logging in or refreshing SonarQube Server. Thanks for the keen eye! @gian1200 caught the same white flash on the “Focusing on new code” page, and it turns out we’re dropping that page entirely in the next release. We’re tracking the loading screen fix in SONAR-32336, rolling out with upcoming releases.
Rules & Languages
@AJ8GH originally flagged a false positive on java:S2637 when calling Optional.orElse(null) after a nullable-typed chain, and @mbrown10 and @henrykuijpers piled on as the same issue kept resurfacing over the years. @Andret2344 went above and beyond by opening a PR that fixed the underlying nullability-annotation handling, and we merged it: SONARJAVA-4121 and its twin JAVASE-87 are now resolved, with the fix landing in the next LTA. Thank you all for your patience, and especially to @Andret2344 for driving this home! Great collaboration ![]()
The “track disallowed” rule docs, like java:S3688, showed an example class-matching regex that wasn’t actually escaped correctly, and left open whether other Disallowed* Java rules support regex the same way, as @MisterPi pointed out. You’re right on both counts, and sorry it took us a while to circle back: we’ve confirmed regex isn’t supported for the other Disallowed* Java rules, and SONARJAVA-6965 will fix the rule description.
@Footed reported that SonarAnalyzer.VisualBasic crashed with a NullReferenceException when analyzing a null-conditional delegate invocation like Handler?(a, b). Thanks @Corniel for jumping in to help troubleshoot! The fix will be part of the next SonarScanner for .NET analyzer release.
javabugs:S2259 and around 30 other DBD rules stopped flagging real issues when a Sonar project was connected, as long as a try/catch block appeared later in the method body. @guidow deserves credit for the detective work
providing minimal reproducers that pinned the bug down precisely. This limitation is now fixed, and you’ll see those issues again starting with the next SonarQube Server release.
java:S2637 also raised a false positive on @NullMarked code where Objects.requireNonNullElseGet was used to guarantee a non-null value, as @reda-alaoui found. You’re right, this is another instance of the same class of false positive; we’re planning a rule engine reimplementation that will eliminate it, and in the meantime we’ve added it to our backlog as JAVASE-260.
@chml0204 noticed that line-of-code counts for PostgreSQL files didn’t match the source when large $$-delimited function bodies were involved. Thanks for the detailed logs and sample files, they made it easy to reproduce! We confirmed the bug, and a fix is in flight.
Automatic Analysis on SonarQube Cloud silently stopped working for @KORKUT-AURELIEN after the JS/TS analyzer crashed on a test file containing raw U+2028/U+2029 separator characters inside a string literal. Great root-cause work tracking that down and sharing a minimal reproducer! JS-2506 will fix the underlying crash. We’re also closely monitoring the similar case reported by @jennymgray ![]()
csharpsquid:S125 flagged a comment as commented-out code just because it contained the word switch followed by ( or {, as @MartinMM found. Thanks for sticking with us through several rounds of reproduction attempts, the dummy project you shared made all the difference! We’re on it.
java:S1158 missed autoboxing written as an explicit wrapper cast before compareTo(), as @marktiwnzhao found. We’ll fix this in SONARJAVA-7000. @marktiwnzhao also reported that java:S1168 misses an array-returning method that returns null through a conditional expression. We’re tracking the fix in SONARJAVA-7011. Thanks for taking the time to report these false negatives!
Thanks again to everyone mentioned here - and to anyone 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!