sonar-java is where SonarQube's Java rules actually live

One analyzer, three products

The README states what the repository contains, and the sentence is the whole scope. This repository contains the analyzer source used by SonarQube Server, SonarQube Cloud, and SonarQube for IDE, and SonarJava inspects Java code for bugs, vulnerabilities, and maintainability issues, then explains why each finding matters and how to fix it. That last clause is a design decision rather than a feature list, since a finding an engineer does not understand is a finding that gets suppressed, and an analyzer that explains the reasoning can be argued with. The static analysis documentation lives on the SonarSource site, and the README has a short pointer to the analysis of Java features. The audience for the code is two groups, the engineers who extend it and the organisations that run it, and the audience for the findings is everybody whose pull request it blocks.

Six hundred rules, and the split between bugs and smells

The feature list gives the numbers. There are 600 or more rules, including 150 or more bug detection rules and 350 or more code smells, and the split is the interesting part, because a bug rule says the code is wrong and a smell rule says the code is hard to read. A team that treats all 600 as blocking will disable the tool, so the ratio matters more than the total. Alongside the rules there are metrics, cognitive complexity and number of lines among them, and cognitive complexity is the one that tends to change behaviour, because it measures how hard a piece of code is to follow rather than how long it is. There is import of test coverage reports, so the coverage you already compute is not computed twice, and there is support for custom rules, which is the escape hatch for a rule that is specific to your codebase and that you would otherwise be tempted to enforce with a homegrown script.

The same analysis for code a person wrote and code a model wrote

One sentence in the README is worth pulling out on its own, because it is where the pressure is heading. SonarJava applies the same analysis to developer-written and AI-generated code, giving teams a consistent way to verify changes before they reach production. That is a deliberate design choice with consequences. If the analyzer treats generated code the same as handwritten code, then a team cannot quietly raise the bar for one and not the other, and the review of a pull request that contains a model-written patch looks like the review of any other patch. It also means the rule set that is written for human code, with its emphasis on readability and intent, is applied to code that was assembled without those intentions, and a rule that expects a human to have chosen a name deliberately will fire on a generated name. The alternative, a separate mode, would double the rule work and give people a way to route around the check.

The module layout, which is the architecture

The repository root shows how a large analyzer is split. java-checks/ is the core, with the checks and their test files, and java-frontend/ is the parsing and semantic layer that the checks sit on. java-checks-testkit/ is the harness that the rule tests are written against, and java-checks-test-sources/ holds test samples that have been moved out of the main module, with a README in java-checks-test-sources/ explaining when a sample belongs there instead of in java-checks/src/test/files. There are also java-checks-aws/ for the Amazon Web Services specific rules, java-jsp/ for the JavaServer Pages rules, sonar-java-plugin/ for the packaging that turns the analyzer into a plugin, and its/ for the integration tests. Alongside the modules are check-list/, external-reports/, docs/ and a set of agent and editor configuration directories, including .agents/, .claude/ and .cursor/, plus a mise.toml for tool versions and a .mvn/ directory for the Maven configuration.

Building it, and the two Java versions you need

The testing section is the most practical part of the README. You need Java 26 to compile and run the unit tests of the project and Java 21 to run most of the integration tests, and Java 21 can be used to build and test all modules except under java-checks-test-sources, since those require Java 26. To build the plugin and run its unit tests, you execute one command from the project root:

mvn clean install

There is a note about running the unit tests within the IDE, which might incur some issues because of the way the project is built with Maven, and the specific error to look for is a SecurityException about class signer information not matching signer information of other classes in the same package, and the fix is to remove the Maven nature of the jdt module. The project uses the forbid_junit4.txt file and the JUnit related module names, so the test stack is modern, and the build is a multi-module Maven build with a root pom.xml.

Integration tests need a SonarQube to talk to

The integration tests are the part that makes the analyzer trustworthy, and they need infrastructure. To run them you have to create a properties file like the one shown 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 presence of an orchestrator and a runtime version in the configuration tells you the shape of it, since the tests stand up a SonarQube instance, analyse a project with the analyzer and assert on the issues that come out, rather than calling the analyzer's internals directly. That is a slower and heavier test style, and it is the only style that actually proves the analyzer works inside the product. The build badges at the top of the README reflect the same arrangement, with a quality gate badge and a coverage badge pointing at the next.sonarqube.com instance for this very project, so the project analyses itself in continuous integration.

The licence, and the rule that you ask before you build

The licence badge reads SSALv1, and the repository has both a LICENSE.txt and a NOTICE.txt, so this is a source-available licence rather than one of the OSI open source licences, which matters if you are evaluating the analyzer for a distribution you intend to ship. The contribution model has a rule that catches people out. To request a new feature you create a new thread in the Sonar Community Forum, and even if you plan to implement it yourself and submit it back to the community, you are asked to start a thread first to be sure that the change can be used. Pull requests go to this repository, following the code style from the sonar-developer-toolset, with all tests passing and all checks green. For custom rules there is a similar expectation, since the README recommends following the Custom Rules 101 tutorial before diving into implementing rules from scratch, and the plugin wiki, the available rules site, the JIRA issue tracker for the SONARJAVA project and the community forum are the places to go for the rest.

Editorial conclusion

sonar-java is the right codebase to read if you want to know how a static analyzer for a real language is put together, because the rule catalogue, the semantic model and the test fixtures are all in the repository rather than in a binary, and because the same analysis is applied to developer-written and AI-generated code, which is the question every team now has to answer. It is the wrong repository to fork for a lint tool of your own, because the licence is a source-available one rather than an OSI open source licence, and the analysis is coupled to the SonarQube platform. Before you build it, read the testing section, since the unit tests need Java 26 while most integration tests need Java 21, and if you only want the rules rather than the code, the rules are published separately on the SonarSource rules site.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SonarSource/sonar-java on GitHub