Usually, i.e. in the case of C/C++, the static analysis workflow is a two-steps process:



  • In the first step the Static Analyzers perform their analysis on the source code and produce their results.
  • In the second step the analysis results are gathered together with the source code by SonarQube so that the results, that is the found issues, are displayed from within the code itself.


For the C/C++ languages the Static Analyzers are invoked externally from SonarQube: either manually or by some external tool, i.e. the SAFacilitator.


For the Java language it is the SonarQube Analysis which automatically calls the StaticAnalyzers.



In the case of Java the SonarQube Analysis:

  1. first triggers the Static Analyzers;
  2. then waits for the Static Analyzers to produce their results;
  3. and finally gathers these results together with the source code.


This difference between C/C++ and Java holds true also for the configuration information required by the Static Analyzers.



In the case of C/C++ the configuration information (files) is provided either manually or by some external tool, i.e. the SAFacilitator.




On the contrary, in the case of Java the configuration information (files) is provided by the build tool: i.e. either Gradle or Maven.


Because of this, the workflow to be followed when performing static analysis depends on the programming language in use.