SonarQube 8.1 - Unable to run check class org.sonar.java.se.SymbolicExecutionVisitor

Very good!

Due to I’m using Travis and I don’t know when tehy will apply the version, is there any workaround that I can apply in the meanwhile?

If will be able to force the build of package-info, is this a workaround?

THANK YOU!

Yes, if you provide package-info.class for all your package-info.java file, it will theoretically do the trick and pass analysis without the errors of this kind anymore.

Now, note that since version 6.0.2 of SonarJava, the NPE was not making analysis crash anymore, but just disabling a small dozen of bug-detection checks, all the other rules were still running on the files causing the issue. On my local instance of SonarQube, with the project your provided, I didn’t observed any difference in term of results, while I can guarantee that the rules which were failing are now running.

By looking at your github project, it seems to me that you are running on SonarCloud, so I would say that everything should get back to normal on Monday anyway.

Cheers,
Michael

Yes, I’m using SonarCloud.

And I’m happy to do not have issues in new version as well! :wink:

Fine! I’m gonna wait next Monday to commit into master and then let’s see if works!

Thank you again

Maybe I got another false-positive issue when the (non javadoc) is produced but next time in another thread!

Just for your info.

I have tried the workaround to create also the package-info.class. But it does not work.

If you want, you can see Travis log here:https://travis-ci.com/pepstock-org/Charba/builds/148919544

Nevertheless, due to Travis wnet in error for amount of log and not for SonarScanner exception, running the scanner redirecting the STDERR to /dev/null it works. Of course this is the Travis issue related to amount of log, but not for whom is not using Travis.

I’m looking forward to push next Monday, to test without this workaround.

Thanks a lot for support.

I can confirm that 6.1 version has resolved this issue. Thank you!

2 Likes

I can confirm that it is working also from Travis!

Thanks a a lot!

2 Likes

Thank you both for your feedback!

@Michael Now having used this for a couple days, version 6.x is about 3 times slower than 5.x.

We have our builds analyze all merge requests (and branches), which was taking between 9-10 minutes. It’s now at around 28-30 minutes for the same project. It’s a 350K line project. Is there something we can do to speed this up?

Unfortunately, this is an expected outcome of moving to 6.X. There is currently no workaround. The higher precision of the new engine as a cost in term of performance, which we didn’t had the resources to tackle yet.

Now, we are very aware of the performance issue of the 6.X serie and its consequences. We plan to work actively on it for next version of SonarJava (6.2), planned to be released in 2-4 weeks. We especially want to get back to something acceptable in term of feedback loop time.

The following JIRA ticket will be the umbrella for all the work we are going to do: MMF-1870

For any other topics related to SonarJava, please start another thread, I’m locking this one, as it is solved.

Cheers,
Michael