New issues showing in 6.1 - no rule change

[Christine Nof]

Dear SonarQube users and experts,

We recently upgraded from Sonar 5.1 to Sonar 6.1. We imported the rules from sonar 5.1 into 6.1 and set them as the default rule set. Other than a few rules that are no longer in 6.1, I don't believe there are any changes to our rule set.

However, when we run analysis, we are seeing a sharp spike in the number of issues found. In one of our repos, we went from having 250 blocker issues to over 1300 blocker issues.

We have analyzed some of these issues and we found that in 5.1 no issue existed. However, in 6.1 on the same line of code, an issue is detected. The Squid rule was from 2015 and it is active on both the 5.1 and the 6.1 instances.

Is there any reason why moving versions would cause this behavior? Could it be that moving to Java 8 is causing the code to be executed differently?

We use the maven plugin for our analysis.

Thank you,

Christine

[Michael Gumowski]

Hello Christine,

Based on your message, I'll assume you are speaking about Java language, as you are using maven analysis. I also guess that if you updated SonarQube from 5.1 to 6.1, you may have updated the SonarJava analyzer in the same time. SonarQube analyzers are very regularly updated, new rules are added and some are significantly improved. 

About the issue appearing depending of the version of SQ, we would need a bit more information in order to see if there is an issue or our side, or if you are simply benefiting of a more efficient analyzer.

Can you share a code snippet, self-contained, reproducing the issue? 

Share the related rule key?

Share the version of the SonarJava analyzer used in both SQ instance?

The java analyzer needs bytecode to be efficient. Maybe bytecode was missing or was not correctly provided when analyzing with earlier version.

Some rules are also only played on java 8 code.

Regards,

Michael

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/e143d75b-9e09-4875-a4fa-fe39c4453868%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Gumowski | SonarSource

Software Developer, Language Team
http://sonarsource.com

[Christine Nof]

Dear Michael,

Thank you for the response.

The code that I've been looking at is Java and JavaScript code. We compile the Java code using Java 7 and then we run the sonar analysis (using Java 8). 

Along with the upgrade, we updated SonarQube analyzer. Previously, we were using org.codehaus.mojo:sonar-maven-plugin:2.6:sonar and now we are using org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar. Before moving to the new analyzer, we had been using Java 7 as the Maven Java version. Now we are using Java 8. Additionally, we were using sonar.analysis.mode=analysis and now we are using sonar.analysis.mode=publish. Can we run the 2.6 analyzer with SonarQube 6.1? Maybe that would be a good option for us in the short term.

We compile the code just before running the sonar analysis, so all of the bytecode should be available.

Below are three examples of code changes.

Example1: 

For a simple example, we have this code snippet, which is throwing squid:S2095 "Resources should be closed." This issue was not detected in SonarQube 5.1 with the 2.6 analyzer.

try
			{
			certStoreName = getCertStorePath(certificateTypeEnum);
			out = new BufferedWriter(
			new FileWriter(certStoreName, true));

Example 2: 
Another is the JavaScript rule javascript:UnusedVariable "Unused local variables and functions should be removed" is now identifying unused functions. Before, the rule was called "Unused local variables should be removed" and it did not do the same behavior.

                function isDefinedInteger(val) {

return val || val === 0;
			}

Example 3:

In one module, there were 29 blocker defects identified in 5.1 and now that number has jumped to 359. Most of those were "Null pointers should not be dereferenced". There is a blocker thrown below on the line that says " adjustColumnWidths(task);"

    private void adjustColumnWidths(final BaseTaskResource task)

    {

        nameColumnWidth = computeColumnWidth(nameColumnWidth, NAME_COLUMN_HEADER, task.getName());

        stateColumnWidth = computeColumnWidth(stateColumnWidth, STATE_COLUMN_HEADER, task.getTaskState().toString());

        teamColumnWidth = computeColumnWidth(teamColumnWidth, TEAM_COLUMN_HEADER, findPartnerTeamName(task));

        uriColumnWidth = computeColumnWidth(uriColumnWidth, TASK_URI_COLUMN_HEADER, task.getUri());

        createdColumnWidth = computeColumnWidth(createdColumnWidth, CREATED_COLUMN_HEADER, task.getCreated());

        runningColumnWidth = computeColumnWidth(runningColumnWidth, RUNNING_COLUMN_HEADER, NEVER_FINISHED);

        rsrcCategoryColumnWidth = computeColumnWidth(

                rsrcCategoryColumnWidth,

                RSRC_CATEGORY_COLUMN_HEADER,

                getAssociatedResourceCategory(task));

        rsrcUriColumnWidth = computeColumnWidth(rsrcUriColumnWidth, RSRC_URI_COLUMN_HEADER, getAssociatedResourceUri(task));

    }

    public List<TaskResourceV2> filterAssociatedRsrcTaskCollections(final List<TaskResourceV2> list, final String targetUri)

    {

        final List<TaskResourceV2> matchingTasks = Lists.newArrayList();

 

        for (final TaskResourceV2 task : list)

        {

            //Build lists of tasks that we want to point out later

            if (targetUri.equalsIgnoreCase(this.getAssociatedResourceUri(task)))

            {

                matchingTasks.add(task);

 !              adjustColumnWidths(task);

            }

        }

        return matchingTasks;

    }