False positive "Annotated Mockito objects should be initialized" (java:S5979)

SonarQube v8.9 (build 43852) complains that we should “Initialize mocks before using them”:

However, as the outer class is annotated as instructed (Rules explorer) this seems to be a false positive?

Hello @fniessink

This issue looks really similar to SONARJAVA-3687, which should already be solved in SonarQube 8.9.

Can you confirm that:

  • You are using a version of the Java analyzer >= 6.13?
  • The import for @Nested is from JUnit 5 (org.junit.jupiter.api.Nested)?
  • The logs of the analysis does not contain warnings about unresolved types?
    See Unresolved imports/types have been detected during analysis, [...]


Hi @Quentin,

  • The Java analyzer has version
  • The import for @Nested is indeed from org.junit.jupiter.api.Nested.
  • We turned off the rule and the logs of builds before that have been wiped, so I can’t check them at the moment. I’ll see whether we can at least temporarily turn the rule back on to check for the warnings.

Thanks, Frank

Thank you for the clarifications.

These logs are independent of the rule, if types are missing, you should still be able to see warnings even when the rule is not enabled.

For the record, we decided to remove this rule from the default profile. In any case, it seems worth checking that the types are correctly resolved since it can have an impact on other rules as well.

Found them. I see several log lines like these:

[ERROR] Unable to parse source file : ‘foo.java’
[ERROR] Parse error at line 87 column 54: Lambda expressions are allowed only at source level 1.8 or above
[ERROR] Unable to parse source file : ‘bar.java’
[ERROR] Parse error at line 56 column 44: Lambda expressions are allowed only at source level 1.8 or above
[INFO] 46/46 source files have been analyzed
[WARNING] Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.

As I see several instances of errors like above followed by the unresolved imports/types warning I’m wondering whether they are related? Anyway, I’ll turn on DEBUG mode for more info.

They may be related indeed, if the rule needs a type that is unresolved, it can be confused.

I suspect here that a few properties are missing in your configuration. Are you using the default SonarScanner or another one (ex: the Scanner for maven)?

By the way, when possible, you should always try to use the one matching your build system.
If you are using SonarScanner anyway, you might want to check the different properties (see documentation), mainly:

  • sonar.java.source
  • sonar.java.binaries
  • sonar.java.libraries
  • sonar.java.test.binaries
  • sonar.java.test.libraries