Commons-lang StringUtils isNotBlank method still raise NPE

Rules and Languages Report False-positive / False-negative...
1

Does Sonar support commons-lang StringUtils ?

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <version>3.7</version>
 </dependency>

Env:

INFO: SonarQube Scanner 3.2.0.1227
INFO: Java 1.8.0_121 Oracle Corporation (64-bit)
INFO: Linux 4.19.2-1.el7.elrepo.x86_64 amd64

Community EditionVersion 7.6 (build 21501)

code to reproduce this issue:

public class DetectorImport {
    public String check1(Nonentity nonentity) {
        String s;
        if(nonentity == null) {
            s = null;
        }else {
            s = nonentity.getName();
        }
        if(StringUtils.isNotBlank(s)) {
            s = s.replaceAll("（", "(");
        }
        return s;
    }
}

NPE
NPE1734×824 66.1 KB

[JAVA] squid:S2259 False Positive with Utility methods
from this thread, I get the following info:

We currently support methods from commons-lang StringUtils (v2, and v3), guava preconditions, and java 8 methods from java.util.Objects (nonNull, isNull, requireNonNull). As we know how these methods behave, we are able to correctly handle such call and discard similar FPs. Of course, I don’t want to force you using such libraries to make the analyzer happy. :slight_smile:

According to this thread Sonarqube is raising false-positive NPE, NullPointer issue should be checked in the same file.

changing above code to following one indeed solve this issue:

public class DetectorImport {

    public String check1(Nonentity nonentity) {
        String s;
        if(nonentity == null) {
            s = null;
        }else {
            s = nonentity.getName();
        }
        if(s !=null) {
            s = s.replaceAll("（", "(");
        }

        return s;
    }
}

It seems that commons-lang StringUtils isn’t supported yet :frowning:

1 Like
2

We have the same issue.

SonarQube Scanner 3.3.0.1492
12:41:32.334 INFO: Java 1.8.0_222 Oracle Corporation (64-bit)
12:41:32.334 INFO: Linux 3.10.0-957.27.2.el7.x86_64 amd64
12:41:33.039 DEBUG: Enterprise 7.9.1.27448

3

Hello

Welcome to the community and thanks for the clear description of your problem.

By looking at this file, it seems that we are supporting StringUtils since already a few years.
I tried with a simple maven project (with SonarScanner for Maven), and StringUtils.isNotBlank is correctly handled.

Then I tried to analyze the same project directly with SonarScanner, without correctly setting up any properties. In this case, the FP appears.
I expect you will find the message:

WARN: Bytecode of dependencies was not provided for analysis of source files, you might end up with less precise results. Bytecode can be provided using sonar.java.libraries property.

in the logs, I believe “less precise results” describes well the problem you face here.

All in all, you should consider using SonarScanner for Maven. If not possible (for any reason), you should make sure the project is correctly configured.

Feel free to come back with more details (how you run the analysis, logs, properties), if you still face the issue.

Hope this helps,

Quentin

1 Like
4

I looked through my logs but I didnt see any “Bytecode of dependencies was not provided” warning.

We are using the SonarScanner and not the maven sonar plugin. And for us the issue was that the “sonar.java.libraries” variable was not properly set. I added the target “dependency:copy-dependencies” as part of the maven execution. This copied all the dependencies to the right location, then I set the property “-Dsonar.java.libraries=target/dependency” in our case.

5

Glad to see that you managed to find a working configuration.

Indeed, this log arises when the property is not set, not when the dependencies are actually missing.
There is already a ticket (SONARJAVA-3114) to improve this situation, we will make sure that the confusion you faced won’t happen again.

Best,
Quentin

1 Like
6

You are right, Quentin.

There is Warning in SonarQube web saying that:

Bytecode of dependencies was not provided for analysis of source files, you might end up with less precise results. Bytecode can be provided using sonar.java.libraries property.

Thanks to Arungeorge101 . I tryed your solution manually and it works indeed.

1 Like