Java
Language-Specific properties
You can discover and update the Java-specific properties in the project Administration > General Settings > Languages > Java
Java analysis and bytecode
Compiled .class
files are required for Java projects with more than one Java file. If not provided properly, analysis will fail with the message:
If only some .class
files are missing, you'll see warnings like this:
If you are not using Maven or Gradle for analysis, you must manually provide bytecode to the analysis. You can also analyze test code, and for that, you need to provide tests binaries and test libraries properties.
Note that manually providing the sonar.java.binaries
is very error-prone. We recommend using Scanner for Gradle if you’re building with Gradle, or Scanner for Maven if you’re using Maven.
Key | Value |
---|---|
sonar.java.binaries (required) | Comma-separated paths to directories containing the compiled bytecode files corresponding to your source files. |
sonar.java.libraries | Comma-separated paths to files with third-party libraries (JAR or Zip files) used by your project. Wildcards can be used: sonar.java.libraries=path/to/Library.jar,directory/**/*.jar |
sonar.java.test.binaries | Comma-separated paths to directories containing the compiled bytecode files corresponding to your test files. |
sonar.java.test.libraries | Comma-separated paths to files with third-party libraries (JAR or Zip files) used by your tests. (For example, this should include the junit jar). Wildcards can be used: sonar.java.test.libraries=directory/**/*.jar |
Note that the Android development toolchain Jack does not provide .class
files.
Project-specific JDK
In some situations, you might have to analyze a project built with a different version of Java than the one executing the analysis. The most common case is to run the analysis with Java 17, while the project itself uses Java 11 or before for its build.
If this is your case, you will need to set the sonar.java.jdkHome
property manually to point the appropriate JDK (see below). By doing this you will specify which JDK classes the analyzer must refer to during the analysis. Not setting this property, while it would have been required, usually leads to inconsistent or even impossible to fix issues being reported, especially in relation with native JDK classes.
When setting sonar.java.jdkHome
, you need to provide the path to the JDK directory used by the project being analyzed, if different from the Java runtime executing the analysis. For example, for a Java 11 project, by setting it as follows: sonar.java.jdkHome=/usr/lib/jvm/jdk11.0.22/
This option can of course be added to your sonar.properties
configuration.
JDK preview features
To enable the JDK preview features in SonarQube Cloud, you can set the sonar.java.enablePreview
analysis parameter to true
(default is false
).
Turning issues off
The best way to deactivate an individual issue you don't intend to fix is to mark it as accepted or false positive through the SonarQube Cloud UI.
If you need to deactivate a rule (or all rules) for an entire file, then issue exclusions are the way to go. But if you only want to deactivate a rule across a subset of a file - all the lines of a method or a class - you can use @SuppressWarnings("all")
or @SuppressWarnings
with rule keys: @SuppressWarnings("java:S2077")
or @SuppressWarnings({"java:S1118", "java:S3546"})
.
Handling the Java version
Java analysis is able to react to the Java version used for sources. This feature allows the deactivation of rules that target higher versions of Java than the one in use in the project so that false positives aren't generated from irrelevant rules.
The feature relies entirely on the sonar.java.source
property, which is automatically filled by most of the scanners used for analyses (Maven, Gradle). Java version-specific rules are not disabled when sonar.java.source
is not provided. Concretely, rules that are designed to target specific Java versions (tagged "java8" or "java11") are activated by default in the Sonar Way Java profile. From a user perspective, the feature is fully automatic, but it means that you probably want your projects to be correctly configured.
When using SonarScanner to perform analyses of project, the property sonar.java.source
can be set manually in sonar-project.properties
. Accepted formats are:
- "1.X" (for instance 1.6 for Java 6, 1.7 for Java 7, 1.8 for Java 8, etc.)
- "X" (for instance 8 for Java 8, 11 for Java 11, etc. )
Example: sonar.java.source=11
If the property is provided, the analysis will take the source version into account, and execute related rules accordingly. At run time, each of these rules will be executed – or not – depending upon the Java version used by sources within the project. For instance, on a correctly configured project built with Java 11, rules targeting Java 17 and Java 21 will never raise issues, even though they are enabled in the associated rule profile.
Analyzing JSP and Thymeleaf for XSS vulnerabilities
On SonarQube Cloud, you can benefit from advanced security rules including XSS vulnerability detection. Java analysis supports analysis of Thymeleaf and JSP views when used with Java Servlets or Spring. To benefit from this analysis you need to make your views part of the project sources using sonar.sources
property. In practice this usually means adding the following in your Maven pom.xml
file:
or, if you use Gradle:
where src/main/webapp
is the directory that contains .jsp
or Thymeleaf's .html
files.
Implementation-related rule tags
- symbolic-execution: This tag is for rules that reason about the state of the program using data flow analysis. They usually work together to find path-sensitive bugs and vulnerabilities. As soon as an issue is raised, the symbolic execution (SE) analysis of the current path will stop. For that reason, it is not recommended to evaluate these rules independently of each other as it can give a false sense of undetected issues. It is important to keep in mind that SE can never achieve perfection, so we are always working on improving these rules. Finally, note that the Java rules relying on the SE engine operate cross-procedurally in certain circumstances. In particular, all non-overridable methods defined in the same file as the method under analysis and called from within the method's body, will be explored and learned from. Behaviors of overridable methods will be approximated.
Related pages
- Test coverage (JaCoCo, Surefire)
- External Analyzer Reports (SpotBugs, FindBugs, FindSecBugs, PMD, Checkstyle)
Was this page helpful?