Adjustments to the "Sonar way" quality profile

Sonar Updates
, , ,
1

Hi everyone,

We removed a few rules from our “Sonar way” quality profiles to ensure they remain an optimal default in our products:

  • Java:S1104: Class variable fields should not have public accessibility
  • Java:S1149: Synchronized classes "Vector", "Hashtable", "Stack" and "StringBuffer" should not be used
  • Java:S1444: "public static" fields should be constant
  • Java:S1874: "@Deprecated" code should not be used
  • Java:S2293: The diamond operator ("<>") should be used
  • Java:S3008: Static non-final field names should comply with a naming convention
  • Java:S3740: Raw types should not be used
  • Java:S8692: The system clock should not be used in unit tests
  • JavaScript:S125: Sections of code should not be commented out
  • TypeScript:S4325: Redundant casts and non-null assertions should be avoided

Those rules are still available outside of this quality profile, and if you miss them, feel free to create a quality profile based on “Sonar way” and add them back.

As a reminder, the purpose of the “Sonar way” quality profile is to be a good default set of rules for most projects and most users. The composition of this profile is likely to be adjusted at any moment to remain fit for that purpose.
If you need a stable set of rules that does not change over time, we encourage you to create your own quality profile.

This change is effective now on SonarQube Cloud for all plans and it will land in SonarQube Community Build 26.7 and SonarQube Server 2026.4.

Cheers,

2

I understand the general benefits of you curating the rules on an ongoing basis and that there is no perfect mix.

However, the removal of e.g. Java:S1444 (“public static” fields should be constant) caught our attention. While we completely understand removing purely stylistic or high-noise rules (like the diamond operator or naming conventions), S1444 feels like a different category.

In our experience, mutable global state via non-final public static fields introduces significant thread-safety risks, concurrency bugs, and potential security vulnerabilities. Because the impact of mutating shared static state can be so severe at runtime, we’ve always viewed this as a critical structural safeguard rather than general linting noise.

Could you share a bit more context or telemetry on why this specific rule was deemed too high-friction for the default profile? Were there specific widespread framework patterns or bootstrap edge cases that triggered excessive false positives for most users?

And as a commercial customer of Sonar Cloud is there a more pro-active way when we monitor these changes? I am not saying we want a “stable” set. Just trying to work out how best to be aware of these changes (adds or removes) outside the community post.