How to handle Java version dependent code smells in mixed version project?

Code Smell Code Smell: Replace the type specification in this constructor call with the diamond operator (“<>”). (sonar.java.source not set. Assuming 7 or greater.) (squid:S2293)

See it in SonarQube

I get issues like this on one module in our codebase which is Java language level level 6. Java language level 6 doesn’t support the diamond operator. Most of the modules are Java language level 8.

How to handle Java version dependent code smells in mixed version project?

Hi,

You’re using the word “module” so I guess you have the ability to set module-level properties?

If so, this should help: https://docs.sonarqube.org/display/PLUG/Handling+Java+Source+Version

 
Ann

1 Like

Not quite. The scan is currently executed once for the entire project including all source and bytecode for all modules.

Perhaps I should split the scan into multiple projects in SonarQube. Is that my best approach if I need distinct sonar.java.source values?

In retrospect, I don’t think I can do that since I think it would delete the comments in the PR analysis and only leave only those for the last module scanned.

Hi,

I’m not talking about separate analyses, but about different parameters for different modules. If you’re using Maven, then I believe you should be able to set module-specific properties in the module poms. If you’re using a different build technology, then you’ll have to get more explicit. This page gives the principles of how to set module properties.

I should probably mention that we intend to drop the concept of module from SonarQube itself in 7.5, and I’m not sure how that will affect your ability to set essentially directory-level analysis properties.

 
Ann

1 Like

We’re using Gradle and Jenkins.

I’ll give modules a try and keep in mind the caveat that they may be removed in 7.5. Thank you.

Hi,

As a followup, I’m being told that even after 7.5, at least for the foreseeable future, your module settings should still work.

Ann

1 Like