SonarJava alternatives and similar libraries
Based on the "Code Analysis" category.
Alternatively, view SonarJava alternatives based on common mentions on social networks and blogs.
9.5 9.9 L3 SonarJava VS CheckstyleCheckstyle is a development tool to help programmers write Java code that adheres to a coding standard. By default it supports the Google Java Style Guide and Sun Code Conventions, but is highly configurable. It can be invoked with an ANT task and a command line program.
9.2 6.8 SonarJava VS SourcetrailSourcetrail - free and open-source interactive source explorer
7.6 7.4 SonarJava VS NullAwayA tool to help eliminate NullPointerExceptions (NPEs) in your Java code with low build-time overhead
7.5 9.3 SonarJava VS SpotbugsSpotBugs is FindBugs' successor. A tool for static analysis to look for bugs in Java code.
6.3 9.5 L2 SonarJava VS SpoonSpoon is a metaprogramming library to analyze and transform Java source code (up to Java 15). :spoon: is made with :heart:, :beers: and :sparkles:. It parses source files to build a well-designed AST with powerful analysis and transformation API.
5.8 7.0 SonarJava VS dotenv-linter⚡️Lightning-fast linter for .env files. Written in Rust 🦀
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of SonarJava or a related project?
This SonarSource project is a code analyzer for Java projects. Information about the analysis of Java features is available here.
- 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
Have question or feedback?
To provide feedback (request a feature, report a bug etc.) use the SonarQube Community Forum. Please do not forget to specify the language (Java!), plugin version and SonarQube 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.
Topic in SonarQube Community Forum
To request a new feature, please create a new thread in SonarQube 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)
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
To run tests locally follow these instructions.
Java 16 to build the project.
Java 11 to run the Integration Tests (ITs).
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
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
# version of SonarQube Server sonar.runtimeVersion=7.9 orchestrator.updateCenterUrl=http://update.sonarsource.org/update-center-dev.properties # Location of 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:
Before running the ITs, be sure your MAVEN_HOME environment variable is set.
The "Sanity Test" is a test which runs all checks against all the test sources 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
The "Plugin Test" is an integration test suite which verifies plugin features such as metric calculation, coverage etc. To launch it:
mvn clean install -Pit-plugin
The "Ruling Test" are an integration test suite which launches the analysis of a large code base, saves the issues created by the plugin in report files, and then compares those results to the set of expected issues (stored as JSON files).
To run the test, first make sure the submodules are checked out:
git submodule init git submodule update
Launch ruling test:
cd its/ruling mvn clean install -DskipTests=false
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 newly implemented rule, it means that a first build will most probably fail, caused by differences between expected results (without any values for the new rule) and the new results. You can inspect these new issues by searching for files named after your rule (
squid-SXXXX.json) in the following folder:
For existing rules which are modified, you may expect some differences between "actual" (from new analysis) and expected results. Review carefully the changes which are shown and update the expected resources accordingly.
json files contain a list of lines, indexed by file, expliciting where the issues raised by a specific rule are located. If/When everything looks good to you, you can copy the file with the actual issues located at:
Into the directory with the expected issues:
For example using the command:
cp its/ruling/target/actual/* its/ruling/src/test/resources/
Copyright 2012-2021 SonarSource.
Licensed under the GNU Lesser General Public License, Version 3.0
*Note that all licence references and agreements mentioned in the SonarJava README section above are relevant to that project's source code only.