The imperative for Clean Code in today's software development world cannot be overstated. SonarQube comes to the rescue, helping developers write Clean Code that is both fit for production and fit for development.
From day one, SonarQube has been known for its powerful Java analysis which today includes over 600 rules for Java developers (we’re Java developers ourselves).
Let's delve into why SonarQube 9.9 LTS is a must-have upgrade in your coding arsenal, enhancing the Java analysis already available in SonarQube 8.9 LTS.
Updates to the analysis engine
Speedier code analysis
In SonarQube 8.9 LTS, Java files were processed one at a time. SonarQube 9.9 LTS enables batch mode, processing files in bulk and making analysis 30% faster in our tests. The improvement was as high as 47% when analyzing SonarSource/sonar-java itself. The performance improvements were measured to be the greatest on projects with a lot of dependencies or on a slow filesystem like NFS.
This performance improvement is further enhanced for commercial SonarQube users through the introduction of incremental analysis for pull requests. This feature focuses on analyzing only the changes introduced in a pull request instead of the entire codebase. You can learn more about this in the SonarQube 9.9 LTS announcement.
All of these speed boosts will ensure that you spend less time waiting and more time coding.
Support for Java 16 - 19
A new SonarQube LTS means support for new language versions, which means we’ve updated parsing to understand any new syntax and to update rules for how they apply to the new language elements.
Keeping up with the evolving Java ecosystem, SonarQube 9.9 now extends its support to new constructs introduced in Java 16, 17, 18, and 19. This ensures you can harness the latest features and enhancements in Java, like record classes or pattern matching, while maintaining high code standards.
While SonarQube does support the latest Java preview features, this support is still experimental. Users may face parsing errors or rule inconsistencies with these features. However, SonarQube is in principle compatible with the latest versions of Java.
We appreciate your understanding and patience as we work towards enhancing our support for these evolving features.
Best effort analysis when semantics are incomplete
Analyzing Java code with the SonarScanner for Maven or SonarScanner for Gradle is highly recommended for accurate analysis results, as those scanners infer the necessary analysis configuration from the build environment. While it is possible to configure the analysis manually after a build, it’s painful and easy to get it wrong.
Sometimes (despite all our warnings!), users choose to analyze their code with the vanilla SonarScanner. When misconfigured, it can lead to false-postives and false-negatives in the analysis results.
While not perfect, SonarQube 9.9 LTS offers more accurate results than SonarQube 8.9 LTS in the case of missing semantic information.
Consistent handling of nullability annotations
Dealing with nullability in Java is not an easy task, so SonarQube offers help with many rules about the correct use of nullability annotations, and several rules use them in determining whether to raise an issue or not.
But it's a complex topic, even - maybe especially - on the analysis side. Part of the complexity comes from the fact that there are many annotations available, from many different sources, each with slightly different approaches to controlling and documenting nullability. Some rules implemented in SonarQube 8.9 LTS suffered from this complexity and ended up inconsistently supporting the different ways these annotations should be used.
To give an idea of the complexity of this topic, sometimes code elements are:
- Non-null (never null)
- Weakly Nullable (can be null or not depending on the context, which a developer can usually predict)
- Nullable (everything that could be null at one point)
- Strongly Nullable (must be checked for null)
The nullability of elements can be determined by reading annotations made directly on the element itself, at the method level, at the class level, or even at the package level. These levels determine the priority, along with an order of precedence. Annotations can be annotated with meta-annotations…to say it’s complicated is an understatement.
We improved nine rules and our symbolic execution engine in their precision (and documentation) to reflect the nuanced world of nullability in Java. Find the list of rules here.
New taint analysis configuration raises more true-positives
Understanding how data flows through an application is crucial to identifying potential security vulnerabilities. For instance, if user input is used in constructing a database query, it's critical to ensure that the input is properly sanitized to prevent SQL injection attacks.
It’s one thing to track data through the code you have written yourself (and that SonarQube is analyzing), but it’s entirely another thing to track data as it flows through the Java libraries developers are using in your project.
SonarQube 9.9 LTS extends its support to the top 100 most commonly used Java libraries, enabling it to detect potential vulnerabilities due to specific software dependencies. The addition of support for libraries like Apache HttpClient, Spring Boot Starter Web, Apache Log4j Core, H2 Database Engine, MySQL Connector/J, HttpClient, Xerces2 J, MongoDB Driver, Dom4j, and Retrofit provides a more comprehensive analysis of your code.
Support for Android APIs were also added, meaning that SonarQube can detect injection-based vulnerabilities specific to Android applications written in Java!
These rules are available in commercial editions of SonarQube.
Fixing false-positives
A few years ago SonarQube began to use the Eclipse Compiler for Java (ECJ) to generate the Abstract Syntax Tree and semantic information required to perform analysis. The ECJ also produces compiler warnings, and we realized that in some cases these compiler warnings raise fewer false-positives and false-negatives than our own rule implementations.
SonarQube 9.9 LTS now integrates ECJ Compiler Warnings to act as the logic behind some well-known rules, offering greater precision.
Consider the import of this statically imported `OK` constant that was reported as a false-positive in our community:
package test;
import static io.netty.handler.codec.http.HttpResponseStatus.OK; // False-positive
class MyHttpEndpoint {
Object handleRequest(Object request) {
// ... some request handling code
return respond(OK); // The OK constant is used here
}
private Object respond(Object status) {
return status;
}
}S1128: Unnecessary Imports should be removed was raised on this code in SonarQube 8.9 LTS. This issue is no longer raised in SonarQube 9.9 LTS, owing to the greater precision offered by the UnusedImport compiler warning.
These other rules were also migrated to ECJ compiler warnings:
- S1905: Redundant casts should not be used
- S4970: Derived exceptions should not hide their parents' catch blocks
- S1656: Variables should not be self-assigned
Not counting all the increased precision introduced incidentally by other updates to our analysis engine, there were also over 100 specific false-postives and false-negatives that were addressed in SonarQube 9.9 LTS!
New Rules
Secure your Android applications with confidence
In the realm of mobile application development, security is paramount. This is especially true for popular platforms like Android, which are targeted by a wide range of potential threats.
SonarQube 9.9 LTS steps up to this challenge by introducing specific rules designed to ensure secure configurations for Android applications. These rules target potential security pitfalls, helping you to write safer and more reliable mobile applications. See the list of rules here
Improve your AWS applications with Clean Code
Cloud computing has become the backbone of modern IT infrastructures, and AWS is one of the leading platforms in this space. With the increasing complexity of cloud applications, maintaining clean and efficient code is vital.
SonarQube 9.9 LTS introduces specific rules that promote cleaner code for AWS applications. By pointing out code smells and potential issues in your AWS codebase, SonarQube enables you to keep your cloud applications as streamlined and efficient as possible. See the list of rules here
Find more cases of insecure XML processing
XML processing is a common activity in Java development, but it often opens a pandora's box of potential security issues. One such vulnerability involves insecure XML processing, which can leave your application exposed to threats such as XML External Entity (XXE) Injection.
SonarQube 8.9 LTS already detects some forms of insecure XML processing, including XML external entity (XXE) injection. SonarQube 9.9 LTS takes this further by adding four additional rules to detect insecure XML processing from other vectors. See the list of rules here.
Detect secrets with little configuration and fewer false-positives
Hard-coding credentials directly into your source code is tantamount to walking on thin ice. It is as precarious as it sounds; one slip or accidental check into source control, and your credentials may as well be considered compromised.
SonarQube 8.9 LTS made an attempt to address this by offering a security hotspot rule that performed a basic check for fields that could potentially contain a password. It did this based on a set of predetermined field names (password,passwd,pwd,passphrase).
However, users wishing to probe for "secret" values, such as API tokens, found themselves needing to further modify this rule. Unfortunately, this often led to a considerable number of false positives. After all, the term 'token' has several meanings in the software development world!
This is where SonarQube 9.9 LTS leaps into the fray with a separate, more refined rule (S6418: Hard-coded secrets are security-sensitive). This new rule comes preconfigured with an extended pattern (secret,token,credential,auth,api[_.-]?key) for secret detection, reducing the legwork for developers.
Additionally, it incorporates a configurable heuristic to discern whether the field value is a credential or not. This is based on the randomness of the value, meaning that an issue won’t be raised for the following code:
private static final String token = "newToken";On the other hand, it will flag an issue in cases like this:
private static final String token = "47828a8dd77ee1eb9dde2d5e93cb221ce8c32b37";Unearth advanced Java bugs with symbolic execution
SonarQube 9.9 LTS now has the ability advanced Java bugs using a new symbolic execution engine.
Symbolic execution engines are an invaluable tool in the arsenal of software development, designed to traverse all feasible execution paths, even across method calls. The objective? To discover elusive bugs nestled within your source code.
Symbolic execution has been a part of SonarQube’s Java analysis for years, and we made a significant effort to build a new, more powerful engine building upon the work we’ve done in security analysis.
Consider, for instance, the following code:
public class Main {
public static void main(String[] args) {
int number = 5;
long factorial = calculateFactorial(number);
System.out.println("Factorial of " + number + " is " + factorial);
}
public static long calculateFactorial(int n) {
return n * calculateFactorial(n - 1);
}
}
}
In this program, calculateFactorial is a recursive function. For other values of n, it multiplies n by the factorial of n-1. This is the recursive step, where the function calls itself with a smaller value.
Without a case for n=0, the program will run forever.
Previously, issues in such cases might have slipped through unnoticed. However, SonarQube 9.9 LTS's enhanced bug detection capability flags the recursion so that developers can fix it.
Five rules using this new engine are available in commercial editions of SonarQube. See the list of rules here.
Just an upgrade away from it all
SonarQube is made by developers, for developers. Our goal is to help all developers be able to write Clean Code. The enhancements in SonarQube 9.9 LTS reflect our ongoing commitment to providing you with an analytical tool that tackles this goal head-on.
If you haven’t tried SonarQube 9.9 LTS yet, I hope you now have even more reasons to prepare this upgrade with your team. Like all SonarQube releases, this is a free version upgrade, and you can get the LTS in just a few clicks at SonarQube Downloads. You won't just be upgrading your SonarQube instance – you'll be upgrading your entire coding experience.
Need more help getting started? Check the following resources:
- SonarQube LTS Upgrade Checklist
- Get help upgrading using the 9.9 LTS Upgrade category of the Sonar Community
Remember, these improvements aren't just limited to SonarQube. If you're using SonarCloud, you'll find all these enhancements there too.