I’ve been searching for a solution to the False Positives. The project has a class with its respective method that checks if the object is null or not, but SQ can’t read that. I’ve read this previous post, and a SonarSourcer discourages the use of Java Custom Rules (“I would definitely not try the ‘custom’ approach”), which was going to be my solution. So I’m asking, five years later, if there is a new possibility or if the solutions are the same as in the post I provided here.
I’m the very same SonarSourcer from 5 years ago.
Unfortunately, I’m also going to give you the very same answer, 5 years after.
In short, no, it’s not going to be simple to write an alternative to the rule or fix it.
As of today, I would still discourage you to write your own custom rules to try to have better results than our implementation of java:S2259. However, if you want to give it a try, our public API is now much more reliable than before and should provide you at least the basic block to start working on such a category of problems, aka, a Control Flow Graph. The engine needed to understand the state of a program will however still need to be implemented completely on your end.
Assuming you still face issues with some methods not being properly understood by our engine, another approach could be the following:
Add your own “method behaviors” to describe how your project methods are supposed to be understood, in json format, in the adequate package (java-symbolic-execution/src/main/resources/org/sonar/java/se/xproc/). It will be on your side to infer the logic here, as it is currently not documented. Having a look at other .json files from this directory might help you.
Make sure the new hardcoded behaviors are loaded by the engine (see the BehavioCache)
repackage the plugin and deploy it on your local SonarQube instance.
Note that we do not plan to allow such kind of configuration for our users in our official release, since we did not formalize the format or thought about how to integrate external configuration.
Finally, a new engine is currently being developed at Sonar, and it should be much more powerful than SonarJava’s open-source Symbolic Execution engine. We are still testing it, but it will most probably replace this engine and the rules, in the upcoming future (no ETA yet). Some rules are already available for commercial versions of SonarQube, and on SonarCloud. More rules will be deployed under the SonarQube 10.x serie.
Hello,
this answer is indeed good notice and that’s coming for you make it really funny. I’m glad that there’s a way to achieve this (Iwhether I can do it is another question).
Thank you very much,
