The following code triggers a false positive for rule java:S3078: “volatile” variables should not be used with compound operators:
class Foo {
private volatile int value;
Foo copy() {
final Foo copy = new Foo();
copy.value = value; // false positive for java:S3078 here
return copy;
}
}
A similar false positive is also triggered by a copy constructor, like this:
class Foo {
private volatile int value;
Foo(Foo other) {
value = other.value; // false positive for java:S3078 here
}
}
In both cases, the remedy suggested by SonarQube is to use AtomicInteger instead, which is certainly wrong. Even if these examples did suffer from concurrency issues (which they might, if there were multiple fields being copied and no other synchronization), using AtomicInteger instead of a volatile int wouldn’t do anything to help.
These false positives seem to be relatively common. As a single data point, we currently have 14 reported violations of this rule in our codebase and they all appear to be false positives of this type.
I initially observed this issue with SonarQube Server Enterprise Edition v2026.2.1 (121354). It is also reproducible with SonarQube for IDE version 12.8.0.85170.