How To Analyze Java Application With SonarQube

In a How To Check Java Test Coverage With Jacoco post, Jacoco was introduced as a test coverage monitoring tool. In this post, Java SonarQube will be used to apply thousands of automated Static Code Analysis Rules to detect possible problems and technical debt in your code. Quality gates will be used to remain the quality of your code on a reasonable level. Java Sonar can be used in Pull Requests to prevent possible issues on a codebase.

Java Sonar Local Setup

Java SonarQube is used to analyze the source code of the java application. To do it, it should be installed somewhere. For this post, a local setup with Docker will be the optimal choice. Docker image from SonarQube will be used with exposing of 9000 port that is required in this post.

docker run --name sonar -p 9000:9000  sonarqube:9.0.1-community

Java Sonar administration UI should appear at the next URL:

http://localhost:9000/

You will be asked to enter admin/admin credentials and change the password.

Several options to set up Sonar are provided. The Manually option will be used for demo purposes. Just to feel how Sonar works, we need some project. The Spring-Boot-Simple project from the Spring Boot Application Overview course will be used. As a result, we have the next screen.

This name will be used further in the post. The project is created in Sonar. However, we should configure it. Of course, Sonar is expected to be a part of the CI/CD Pipeline in a real project. For demo purposes, the Locally option is a good way to start.

First of all, we should generate a token to access this project.

After that, we can analyze the project.

Java SonarQube Configuration

Spring Boot Simple project has a Jacoco configuration for test coverage. It will be automatically picked up by Sonar. So, we only need to follow the instructions from SonarQube.

Let’s add the SonarQube plugin.

plugins {
    id "org.sonarqube" version "3.3"
}

Let’s build the application. During the build process, Jacoco Test Coverage Reports will be generated. These reports will be used by SonarQube.

./gradlew clean build

After that, let’s start Sonar analysis. Note, that projectKey and login can be different based on your Sonar configuration.

./gradlew sonarqube -Dsonar.projectKey=spring-boot-simple -Dsonar.host.url=http://localhost:9000 -Dsonar.login=da55e6a2a39868ae22bd77aaf48e61c26b19d8b7

Go to the Overall Code at the next URL:

http://localhost:9000/dashboard?id=spring-boot-simple&selectedTutorial=manual

Code analysis results will be provided there.

As you can see, the test coverage is pretty low. Following the links, we can find why. For instance, for ErrorDto class the problem is with Lombok annotation. It is not a real problem. In this case, based on your project preferences, Lombok-generated code can be excluded from Jacoco, you can exclude packages from scanning or you can keep it as it is but set lower quality gate.

You can play around with the UI to check all possible features. For instance, one useful metric is Code Smells or Debt. By clicking on it, you can see possible issues with your code. For example, Code Smells in this code can be found on the next screen.

In this project, most of the Code Smells are related to the unnecessary public modifier.

Issues can be explicitly suppressed in your code or you can disable some of the checks in Sonar. Please look at Sonar Documentation for details.

Sonar is useful in code review using CI/CD pipelines. For instance, let’s add a new class completely without tests.

package com.datamify.spring.boot.simple.service;

public class DummyService {

    public int a1(int b, int c) {
        return b + c;
    }

    public int a2(int b, int c) {
        return b + c;
    }

    public int a3(int b, int c) {
        return b + c;
    }

    public int a4(int b, int c) {
        return b + c;
    }

    public int a5(int b, int c) {
        return b + c;
    }

    public int a6(int b, int c) {
        return b + c;
    }

    public int a7(int b, int c) {
        return b + c;
    }

    public int a8(int b, int c) {
        return b + c;
    }

    public int a9(int b, int c) {
        return b + c;
    }

    public int a10(int b, int c) {
        return b + c;
    }

    public int a11(int b, int c) {
        return b + c;
    }

    public int a12(int b, int c) {
        return b + c;
    }

}

After that, we should rerun the commands.

./gradlew clean build

./gradlew sonarqube   -Dsonar.projectKey=spring-boot-simple   -Dsonar.host.url=http://localhost:9000   -Dsonar.login=da55e6a2a39868ae22bd77aaf48e61c26b19d8b7

As you can see measures for New Code caused the quality gate to fail. This is because of 0% Test Coverage on New Code.

Summary

In this post, Java SonarQube was used to measure and validate the source code. Sonar is usually used in CI/CD pipelines and has a lot of configurations that can be applied to the source code based on your project needs and preferences. Look at Sonar Documentation for more details.

The project that was analyzed is available at Github.

The whole course:

• How To Format Your Java Code With CheckStyle
• How To Check Java Source Code With PMD
• How To Check Java Test Coverage With Jacoco
• How To Analyze Java Application With SonarQube
• How To Use CircleCI Java CI/CD Pipeline