Hello,
the SonarLint plugin on IntelliJ doesn’t work anymore when binding to a SonarQube server
versions used :
SonarLint 4.1.0.3312
IntelliJ ultimate 2019.2.1 Ultimate
SonarQube server 6.7.4
error observed :
Files analysis fails with message : "Using configuration of ‘xxx’ in server ‘yyy’
Analysing ‘SomeClass.java’…
File won’t be refreshed because there were errors during analysis
(xxx and yyy are correctly set)
The exact same configuration works fine with IntelliJ 2019.1.3
Maybe it is related to the kind of old version of SonarQube we have, let me know if you think so
Hi,
I’m having exactly the same issue here using the same versions of SonarLint and IntelliJ but SonarQube server 7.0 (build 36138).
Unfortunately I’ve updated to IntelliJ 2019.2 and additionally installed JDK 11 in parallel so maybe this error is related to the Java version? The SonarQube server supports JDK 8 only so far.
Best regards
Florian
Since my colleagues meanwhile get the same error we decided to estimate this issue a bit deeper.
SonarLint plugin version is now 4.1.1.3345.
Running with the configuration from my post above we found this in the log:
Starting analysis with configuration: snip extraProperties: {sonar.java.target=1.8, snip Configured Java source version (sonar.java.source): 8 snip
Unable to create symbol table for : …/MyClass.java
java.lang.IllegalArgumentException: Unsupported class file major version 55
at org.objectweb.asm.ClassReader.(ClassReader.java:166)
at org.objectweb.asm.ClassReader.(ClassReader.java:148)
at org.objectweb.asm.ClassReader.(ClassReader.java:136)
at org.sonar.java.resolve.BytecodeCompleter.loadClass(BytecodeCompleter.java:242)
at org.sonar.java.resolve.Symbols.(Symbols.java:176)
at org.sonar.java.resolve.SemanticModel.createFor(SemanticModel.java:60)
at org.sonar.java.model.VisitorsBridge.visitFile(VisitorsBridge.java:109)
at org.sonar.java.ast.JavaAstScanner.simpleScan(JavaAstScanner.java:96)
at org.sonar.java.ast.JavaAstScanner.scan(JavaAstScanner.java:68)
at org.sonar.java.JavaSquid.scanSources(JavaSquid.java:116)
at org.sonar.java.JavaSquid.scan(JavaSquid.java:110)
at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:93)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.executeSensor(SensorsExecutor.java:81)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.execute(SensorsExecutor.java:72)
at org.sonarsource.sonarlint.core.container.analysis.AnalysisContainer.doAfterStart(AnalysisContainer.java:132)
at org.sonarsource.sonarlint.core.container.ComponentContainer.startComponents(ComponentContainer.java:125)
at org.sonarsource.sonarlint.core.container.ComponentContainer.execute(ComponentContainer.java:110)
at org.sonarsource.sonarlint.core.container.storage.StorageAnalyzer.analyze(StorageAnalyzer.java:75)
at org.sonarsource.sonarlint.core.container.storage.StorageContainerHandler.analyze(StorageContainerHandler.java:82)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.lambda$analyze$0(ConnectedSonarLintEngineImpl.java:152)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:344)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.withReadLock(ConnectedSonarLintEngineImpl.java:334)
at org.sonarsource.sonarlint.core.ConnectedSonarLintEngineImpl.analyze(ConnectedSonarLintEngineImpl.java:149)
at org.sonarlint.intellij.core.ConnectedSonarLintFacade.analyze(ConnectedSonarLintFacade.java:74)
at org.sonarlint.intellij.core.SonarLintFacade.startAnalysis(SonarLintFacade.java:63)
at org.sonarlint.intellij.analysis.SonarLintAnalyzer.analyzeModule(SonarLintAnalyzer.java:97)
at org.sonarlint.intellij.analysis.SonarLintTask.analyze(SonarLintTask.java:176)
at org.sonarlint.intellij.analysis.SonarLintTask.run(SonarLintTask.java:100)
at org.sonarlint.intellij.analysis.SonarLintJobManager.lambda$runTask$1(SonarLintJobManager.java:120)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:169)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:591)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:537)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:59)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:156)
at org.sonarlint.intellij.analysis.SonarLintJobManager.lambda$runTask$2(SonarLintJobManager.java:120)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
So it looks like SonarLint tries to analyse a class compiled with JDK 11 but expects a JDK 8 compiled class. Any ideas??
Hi @florian, thanks for investigating this deeper on your side.
As far as I can tell, “official” support for Java 11-compatible class files (major version 55) was brought with SonarJava 5.8, released in October 2018, the critical component here being ASM 6.2.1.
I understand that you are using connected mode with SonarQube 7.0, could you please check which version of SonarJava is installed?
Another thing you could check is that your project in IntelliJ is properly configured to compile Java 8-compatible class files (major version 52).
thanks for your feedback,
My project in IntelliJ is still configured to use Java8 but for other projects I’ve also installed JDK 11.
The SonarQube server 7.0 (build 36138) is running with SonarJava 5.6 (build 15032).
Probably an update of the SonarJava plugin would fix my problems but this also requires an update of the SonarQube server which I cannot do in the short run.
I was hoping there is another way to make this work since everything is fine on the SonarQube server and only the SonarLint plugin refuses to do anything.
TL;DR: the best fix to this issue is to update SonarJava on the server to a version greater than 5.8, and the second best fix is indeed to run IntelliJ with a JDK 8.
My hypothesis is that SonarLint, as an IntelliJ extension, runs inside IntelliJ’s VM. So it also loads the SonarJava analyzer inside this same VM, no matter what is configured at the project level. SonarJava in turn tries to load classes from IntelliJ’s VM when resolving classes used by MyClass - e.g, java.lang.Object - and gets the aforementioned ASM error.
As far as I can tell, there is no way to tell SonarJava to load Java standard library classes from another version than the one it is running with, hence my advice to upgrade SonarJava to a version that supports Java 11.
Beware that last plugin version is built with JDK 11 so if you choose an older JDK it won’t work anymore and you will have to install a previous version (been there…).
