"!unknownSymbol!" is returned while visitMethodInvocation


(Julien Bréda) #1
  • versions used (SonarQube, Scanner, Plugin, and any relevant extension)

Not really usefull as the problem can be reproduced with a test (see below)
SonarQube Community Edition Version 7.5 (build 20543)

The most revelant :
java-frontend (also tried with

  • error observed (wrap logs/code around triple quote ``` for proper formatting)

org.sonar.plugins.java.api.semantic.Symbol.type() returns null because of org.sonar.plugins.java.api.tree.MethodInvocationTree.symbol() returning !unknownSymbol!

  • steps to reproduce
  1. Clone the repository https://github.com/Droofit/sonar-unknown-symbol
  2. Import the project in your prefered editor (I used Eclipse)
  3. Run the test named org.test.testy.NoBigDecimalRuleTest
  4. Test should success
  5. Move the “Entity” class for src/test/java to src/main/java
  6. Run the test again
  7. Test should fail because of the raised IllegalStateException

That’s the same if you move the class to a dependency, which is the problem I encounter in some production code, but it’s more painfull to use a dependency within a test.

(Tibor Blenessy) #2

Hello @Julien_Breda,

this is expected behavior, unit test framework consider only single file for the analysis, and will not automatically pick up other files. You can provide compiled class file as part of the classpath using the overload org.sonar.java.se.JavaCheckVerifier#verify(java.lang.String, org.sonar.plugins.java.api.JavaFileScanner, java.util.Collection<java.io.File>) if you want to test behavior of the rule with specific classes available on the classpath.

Now you might be surprised why does this work when class is in test directory, the reason for this is that sonar-java will use the classpath of the jvm running the test itself, and you will have the Entity class available there, because IDE will provide it on the classpath.

If you see this happening in the production, most likely the analysis is misconfigured and sonar.java.libraries is not set correctly. Anyway good strategy for writing rules is always check returned value, because analysis can be configured incorrectly.

(Julien Bréda) #3

Hi @saberduck,

Thanks for your reply.
You’re right and I maybe tried to simplify the problem too much : unit test isn’t as revelant as I expected.
However I still have an equivalent problem with analysis on production code.

As I exposed earlier, I use sonar-maven-plugin
This plugin should set sonar.java.libraries correctly, doesn’t it ? (assuming dependency is declared at scope ‘compile’)

I’ll try to give you a more representative repository as soon as I can :

  • a project containing a similar rule (to add to a SonarQube)
  • a project which can be considered as “production” project

(Tibor Blenessy) #4

yes, sonar-maven-plugin should handle sonar.java.libraries property automatically. Please come back to us when you manage to narrow down the problem.