Custom JSON Behavior Not Loaded in SonarJava Symbolic Execution Plugin

SonarQube Server / Community Build
,
1

Hi everyone,

I’m trying to extend the symbolic execution engine in SonarJava by adding support for a custom utility method that performs a null check.

What I did:

  • I created a file called faf.app.common.json with behavior definitions for my utility method CommonFunctionsHLP.vacio(Object).
  • I placed this file inside src/main/resources/org/sonar/java/se/xproc/ of the java-symbolic-execution-plugin module.
  • I added the following entry to the BEHAVIORS_RESOURCES array in BehaviorCache.java:
    First I tried:
"faf.app.common.json"

then:

"org/sonar/java/se/xproc/faf.app.common.json"
  • I verified the JAR file contains the JSON resource using:
jar -tf plugin.jar | grep faf.app.common.json
  • I tried placing the resulting plugin JAR in both:
    • $SONAR_HOME/lib/extensions/
    • $SONAR_HOME/extensions/plugins/
  • I restarted SonarQube (running via Docker Compose) after each change.

What I expected:

The symbolic execution engine to load the behavior from the JSON and recognize the method as a valid null-check during analysis.

What I got:

When running the analysis in debug mode (-X), I see the following log lines:

[DEBUG] [SE] Unable to load hardcoded method behaviors. Defaulting to no hardcoded method behaviors.
[DEBUG] [SE] Loaded 0 hardcoded method behaviors

It seems like the JSON isn’t being picked up, even though it’s present in the classpath. I’m attaching the log.

Is there anything else I need to do to ensure that the behavior file is properly loaded by BehaviorCache during analysis?

Thanks in advance!
salida-sonar-2.txt (700.9 KB)

2

Hi,

Can you share what led you to believe this would work?

 
Thx,
Ann

3

Hi,

I based it on a response from a few years back: sonarqube forum.

Thanks for the response,
Rafael

4

Hi Rafael,

So, to be clear, you’re creating a custom plugin? Not trying to hack the one that’s shipped with SonarQube?

 
Thx,
Ann

5

Hi,
There was no intention to modify the original. I was using the “java-symbolic-execution-plugin” directory from the “sonar-java” repository.
I was trying to avoid false positives with rule S2259. In the post I shared, I understood that it was possible to declare the behavior of my code and thus prevent issues from being raised in those specific cases using this custom plugin.

Thanks,
Rafael

6

Hi Rafael,

The post you pointed to suggests creating a custom plugin:

What you’re trying to do isn’t intended to work.

 
HTH,
Ann

7

Hi,
Oh, it’s good to know, thanks. And is there any way to use the plugin to achieve the goal? Or there is no solution for this specific case?

Thanks,
Rafael

8

Hi Rafael,

Your best option here is to lay out a convincing case for us to make the rule change.

Would you care to share your context and what you’d like to see changed?

 
Ann

9

This use case is very specify and I don’t believe that it would be relevant for other users.
I’m working with a legacy Java codebase where it use a custom utility method called CommonFunctionsHLP.vacio(Object) that has multi-purpose logic: it serves as a generic check for “null or empty” values across a wide range of types (e.g., String, Integer, Collection, EntidadVO, etc.) and there are indirect call to user-defined methods. The method is defined like this:

public static boolean vacio(Object value) {
    return vacio(value, Boolean.FALSE);
}

public static boolean vacio(Object value, Boolean onlyNull) {
    if (value == null) return true;
    // More logic for other types...
}

In many places throughout the codebase (hundreds, actually), we do things like:

if (!CommonFunctionsHLP.vacio(dbh)) {
    dbh.close();
}

Because this is a large legacy system with hundreds of such checks, updating all usages would be time-consuming and error-prone. That’s reason I tried to modify the behavior of the rule.

Thanks

1 Like
15

Hi @raphael !

We’re developing a new version of our symbolic execution engine, which includes an updated S2259 (Null check) rule, now identified as S6555. This enhanced rule analyzes the entire project and isn’t yet active in the default profile. I believe it could resolve your issue without requiring custom behavior.

While this new rule isn’t available in the SonarQube Community Build, you can test it out using the free edition of SonarQube Cloud.

Let me know if this helps!

2 Likes