SonarLint not finding issue until after SonarQube scan: java:S4551

I am running SonarQube 9.9.6 and SonarLint 10.11.1.79663 in IntelliJ on Mac OS using connected mode.

I wrote the following code in IntelliJ

public enum WeekDay {
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY
}

public class EqualMethodInEnum {

    public boolean isMonday(WeekDay weekDay) {
        return weekDay.equals(WeekDay.MONDAY);
    }
}

I was expecting SonarLint to complain that Enum values should be compared with “==” (java:S4551) but it did not.

I ran an analysis scan and the scan results in the server did create an issue for this.

I then switched back to SonarLint and it started showing this issue too.

Why did SonarLint only identify this as an issue once an analysis scan had been executed and uploaded to the server? Is this expected behaviour?

Thanks

Hi, I checked the given rule, and it looks like it is not enabled by default. Were you connected to the server when running the first analysis? When a project is connected to SonarQube or SonarCloud, configuration from the server applies.

Yes, I was using connected mode linked to the project that I then scanned and triggered the issue appearing

If all the conditions are met(The project is correctly bound and a couple of minutes have passed for sync to happen with the quality profile after the change was made in the server) this should not happen

Could you duplicate the issue like this while being not connected and make sure there are no issues appearing for that rule:

public boolean isMonday(org.example.Weekday weekDay) {
    weekDay.equals(org.example.Weekday.MONDAY);
    return weekDay.equals(org.example.Weekday.MONDAY);
  }

Then, could you connect to SonarQube and check without doing another analysis scan on the server that 2 issues will appear for this rule(1 that was found from the previous server analysis and the new one found by non-server analysis)?

Hi

Tried this … when disconnected nothing showed up as expected.

After connecting to SonarQube and waiting a few seconds, an issue for missing copyright header showed up as expected but not the issue for the enum ==

Repeated this in VS Code and confirmed the same behaviour.

Then I did a full scan analysis and the == issue appeared in both IntelliJ and VS Code after they got a notification that the quality gate stays had changed.

Hi @stephenrpalmer

Could you also please share the SonarLint logs with us?

b4fullscan.txt (185.3 KB) contains logs for running SonarLint unconnected and then connected when copyright rule issue shows up but notate enum== rule issues see screenshot

afterFullScan.txt (185.3 KB) after doing above and then running a full scan, after which enum== starts to show up

I am going to try reducing the size of our quality profile to just the default rules plus the enum== rule and see if the strange behaviour persists.

I have confirmed that I can reproduce this behaviour using a quality profile that extends the Sonar Way profile and just adds the one additional enum== rule

Any update on this? Is this a known issues or are we doing something wrong?

Hey, sorry for the late reply on that.

I had a look at the logs and the issue is due to:

[2024-10-24T12:00:26.027] [sonarlint-analysis-engine] WARN org.sonar.java.SonarComponents - Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.
 [2024-10-24T12:00:26.027] [sonarlint-analysis-engine] DEBUG org.sonar.java.SonarComponents - Unresolved imports/types:
- WeekDay cannot be resolved to a type
 [2024-10-24T12:00:26.027] [sonarlint-analysis-engine] WARN org.sonar.java.SonarComponents - Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
 [2024-10-24T12:00:26.027] [sonarlint-analysis-engine] DEBUG org.sonar.java.SonarComponents - Use of preview features:
- WeekDay cannot be resolved to a variable

The Sonar Java analyzer could not find the WeekDay type. This could be because our analyzer relies on Bytecode for more accurate analysis. Could you try building the project and re-analyzing the project once more? This should likely fix the issue.

1 Like