SonarJava

SonarJava inspects Java code for bugs, vulnerabilities, and maintainability issues, then explains why each finding matters and how to fix it. Information about the analysis of Java features is available here.

This repository contains the analyzer source used by SonarQube Server, SonarQube Cloud, and SonarQube for IDE. SonarJava applies the same analysis to developer-written and AI-generated code, giving teams a consistent way to verify changes before they reach production.

Learn more about Java analysis on the Sonar website.

Features

• 600+ rules (including 150+ bug detection rules and 350+ code smells)
• Metrics (cognitive complexity, number of lines, etc.)
• Import of test coverage reports
• Custom rules

Use SonarJava

SonarJava runs through SonarQube Server, SonarQube Cloud, and SonarQube for IDE. Read the Java analysis documentation for setup and coverage guidance.

Useful links

• Project homepage
• Issue tracking
• Available rules
• Sonar Community Forum
• Demo project analysis
• Plugin Wiki

Have questions or feedback?

To provide feedback (request a feature, report a bug, etc.) use the Sonar Community Forum. Please do not forget to specify the language (Java!), plugin version and SonarQube Server version.

If you have a question on how to use plugin (and the docs don't help you), we also encourage you to use the community forum.

Contributing

Topic in Sonar Community Forum

To request a new feature, please create a new thread in Sonar Community Forum. Even if you plan to implement it yourself and submit it back to the community, please start a new thread first to be sure that we can use it.

Pull Request (PR)

To submit a contribution, create a pull request for this repository. Please make sure that you follow our code style and all tests are passing (all checks must be green).

Custom Rules

If you have an idea for a rule but you are not sure that everyone needs it you can implement a custom rule available only for you. Note that in order to help you, we highly recommend to first follow the Custom Rules 101 tutorial before diving directly into implementing rules from scratch.

Work with us

Would you like to work on this project full-time? We are hiring! Check out https://www.sonarsource.com/hiring

Testing

To run tests locally follow these instructions.

Java versions

You need Java 26 to compile and run the Unit Tests of the project and Java 21 run most Integration Tests (ITs). Note that Java 21 can be used to build and test all modules except under java-checks-test-sources (as they require Java 26). If you are adding or moving rule test samples, see java-checks-test-sources/README.md for guidance on when samples belong in the dedicated test-source modules instead of java-checks/src/test/files.

Build the Project and Run Unit Tests

To build the plugin and run its unit tests, execute this command from the project's root directory:

mvn clean install

Note that

Running unit tests within the IDE might incur in some issues because of the way the project is built with Maven. If you see something like this:

java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package

try removing the Maven nature of the 'jdt' module.

Integration Tests

To run integration tests, you will need to create a properties file like the one shown below, and set the URL pointing to its location in an environment variable named ORCHESTRATOR_CONFIG_URL.

# version of SonarQube Server
sonar.runtimeVersion=LATEST_RELEASE

orchestrator.updateCenterUrl=http://update.sonarsource.org/update-center-dev.properties

# The location of the Maven local repository is not automatically guessed. It can also be set with the env variable MAVEN_LOCAL_REPOSITORY.
maven.localRepository=/home/myName/.m2/repository

With for instance the ORCHESTRATOR_CONFIG_URL variable being set as:

export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties

Before running the ITs, be sure your MAVEN_HOME environment variable is set.

Sanity Test

The "Sanity Test" is a test that runs all checks against all the test source files without taking into account the result of the analysis. It verifies that rules are not crashing on any file in our test sources. By default, this test is excluded from the build. To launch it:

mvn clean install -P sanity

Plugin Test

The "Plugin Test" is an integration test suite that verifies plugin features such as metric calculation, coverage, etc. To launch it, build the plugin first (mvn clean install), then run:

cd its/plugin
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true

Note for internal contributors: in order to also execute the tests that depend on the SonarQube Server Enterprise Edition, use:

mvn clean install -Pit-plugin

Ruling Test

The "Ruling Test" is an integration test suite that launches the analysis of a large code base, saves the issues created by the plugin in SARIF reports, and then compares those results to the expected SARIF reports.

To run the test, first make sure the submodules are checked out:

git submodule update --init --recursive

Then, ensure that the JAVA_HOME environment variable is set for the ruling tests execution and that it points to your local JDK 21 installation. Failing to do so will produce inconsistencies with the expected results.

From the its/ruling folder, launch the ruling tests:

mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java21/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true

Note for internal contributors: in order to also execute the tests that depend on the SonarQube Server Enterprise Edition, use:

mvn clean install -Pit-ruling

To run the ruling tests for only a subset of rules, use the sonarRules property with a comma-separated list of rule keys:

mvn clean install -Pit-ruling -DsonarRules=S100,S101

This test gives you the opportunity to examine the issues created by each rule and make sure they're what you expect. Any implemented rule is highly likely to raise issues on the multiple projects we use as ruling code base.

• For a newly implemented rule, the first build will most probably fail because no expected results exist for the new rule. Inspect the new issues in java-SXXXX.sarif for each project under:

    /path/to/project/sonar-java/its/ruling/target/actual/...
  

• For existing rules which are modified, you may expect some differences between "actual" (from new analysis) and expected results. Review carefully the changes that are shown and update the expected resources accordingly.

Each SARIF report contains a runs[].results[] entry for each issue, with its rule ID, message, and location. After reviewing the differences, copy the relevant actual report from:

its/ruling/target/actual/

Into the directory with the expected issues:

its/ruling/src/test/resources/expected/

For example, from the repository root, to update one rule in one project:

cp its/ruling/target/actual/<project>/java-SXXXX.sarif its/ruling/src/test/resources/expected/<project>/

Debugging Integration Tests

You can debug ITs by adding -Dmaven.binary=mvnDebug as an option when running the tests. This will cause the analyzer JVM to wait for a debugger to be attached before continuing.

Updating licenses:

When dependencies change, update the committed license files using the updateLicenses profile:

mvn clean package -PupdateLicenses

This regenerates licenses in sonar-java-plugin/src/main/resources/licenses/ based on current project dependencies.

License

Copyright 2012-2026 SonarSource.

SonarQube analyzers released after November 29, 2024, including patch fixes for prior versions, are published under the Sonar Source-Available License Version 1 (SSALv1).

See individual files for details that specify the license applicable to each file. Files subject to the SSALv1 will be noted in their headers.