I'm using SonarLint 4.1.1.3345 with IntelliJ Community 2019.2 version by binding project to our SonarQube (with SonarJava 5.3 (build 13828)installed) server. However, I got error with below stack trace from SonarLint log:
Java Main Files AST scan
60 source files to be analyzed
Unable to create symbol table for : C:\Users\username\SomeFile.java
java.lang.IllegalArgumentException: Unsupported class file major version 55
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:148)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:136)
at org.sonar.java.resolve.BytecodeCompleter.loadClass(BytecodeCompleter.java:204)
at org.sonar.java.resolve.Symbols.<init>(Symbols.java:176)
at org.sonar.java.resolve.SemanticModel.createFor(SemanticModel.java:59)
at org.sonar.java.model.VisitorsBridge.visitFile(VisitorsBridge.java:110)
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.SonarLintUserTask.run(SonarLintUserTask.java:39)
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)
"Unsupported class file major version 55" tells me that the class file Sonar used for code analysis is for java 11 version whereas my class was compiled with java 7 (I took the same class and ran it with javap it showed major version 51), and I don't even have java 11 installed on my system.
Because it works for my teammates. The only difference is they have lower version of IntelliJ installed. So I downloaded IntelliJ 2019.1.4 and it started working.
Could someone explain why it doesn't work with later version of IntelliJ and why the above error occurred? Thanks in advance!
This is a known limitation about classloaders in the IDE/sonarlint/plugin:
https://community.sonarsource.com/t/sonarlint-analysis-fails-on-intellij-2019-2-with-java-11-runtime/12905/3
https://jira.sonarsource.com/browse/SONARJAVA-3056
Example with SonarLint
In SonarLint IntelliJ running environment, this is more or less the
classpath hierarchy:
JDK -> IntelliJ classes -> SonarLint (+deps) [child-first] -> Java
plugin (+packaged deps) [child-first] -> Squid [parent-first]. So
imagine we analyze a class that is using a class X. If IntelliJ's
classloader happens to also use class X (same fully qualified name),
this will be used instead of the X provided in the analysis classpath,
even if they are to different copies of the class (different versions,
for example).
Related
I have been trying to re-familiarize myself in Java and decided to tackle making a Minecraft mod as it seemed fairly simple. I set up IntelliJ IDEA for Manjaro linux and set up my build.gradle. Everything seemed to be working smoothly until I tried to add the dependency "CottonMC:LibGui" which is a dependency for making intuitive GUI's for Minecraft mods. When I added the dependency to my project, I recieved the error, "Cannot resolve symbol 'CottonClientScreen'" which is a part of the LibGui dependency. I feel as if this is likely a beginner mistake, but I have not been able to find a solution on the internet.
What I've tried:
Running ./gradlew genSources after adding the dependency to my repositories and dependencies sections of my build.gradle
Restarting IntelliJ and clearing my cache
Searching for the dependency in IntelliJ using the "Generate Dependency" tool (the dependency did not come up even when I copied the exact link to it)
Files in Question:
build.gradle (trimmed to only contain relevent sections)
repositories {
maven {
name = "CottonMC"
url = "https://server.bbkr.space/artifactory/libs-release"
}
}
dependencies {
minecraft "com.mojang:minecraft:${project.minecraft_version}"
mappings "net.fabricmc:yarn:${project.yarn_mappings}:v2"
modImplementation "net.fabricmc:fabric-loader:${project.loader_version}"
modImplementation "net.fabricmc.fabric-api:fabric-api:${project.fabric_version}"
modImplementation include("io.github.cottonmc:LibGui:6.3.0+1.19")
}
Implementation file:
import io.github.cottonmc.cotton.gui.GuiDescription;
import io.github.cottonmc.cotton.gui.client.CottonClientScreen;
public class screen extends CottonClientScreen {
}
Exact error:
Java Version
openjdk version "18.0.2" 2022-07-19
OpenJDK Runtime Environment (build 18.0.2+0)
OpenJDK 64-Bit Server VM (build 18.0.2+0, mixed mode)
Thank you for your help!
I'm using Micronaut 3.1.3 together with Gradle 7.2 to build my project.
After switching to Gradle 7.3, built breaks emitting some context-free error message:
$ ./gradlew clean build
Executed by Gradle 7.3
- using Java 11.0.13
- using Kotlin 1.5.31
- using Groovy 3.0.9
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring root project '[PROJECT]'.
> The value for this property is final and cannot be changed any further.
With --stacktrace a very long trace appears. The following excerpt makes me guess
that the problem might lay in the Micronaut plugin:
* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring root project '[PROJECT]'.
at org.gradle.configuration.project.LifecycleProjectEvaluator.wrapException(LifecycleProjectEvaluator.java:75)
at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:68)
at org.gradle.configuration.project.LifecycleProjectEvaluator.access$400(LifecycleProjectEvaluator.java:51)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: java.lang.IllegalStateException: The value for this property is final and cannot be changed any further.
at org.gradle.api.internal.provider.AbstractProperty$FinalizedValue.beforeMutate(AbstractProperty.java:489)
at org.gradle.api.internal.provider.AbstractProperty.assertCanMutate(AbstractProperty.java:263)
at org.gradle.api.internal.provider.AbstractProperty.setSupplier(AbstractProperty.java:212)
at org.gradle.api.internal.provider.DefaultProperty.set(DefaultProperty.java:71)
at org.gradle.api.tasks.testing.Test.useTestFramework(Test.java:979)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1049)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1032)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$null$1(MicronautLibraryPlugin.java:103)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.api.internal.DefaultDomainObjectCollection.withType(DefaultDomainObjectCollection.java:201)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$apply$4(MicronautLibraryPlugin.java:101)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Cause "problem occurred configuring root project" I'm not sure which part of my
build.gradle raises the problem. So following my first guess regarding Micronaut
plugin, here is an excerpt telling you the list of plugins in use and config of this plugin:
plugins {
id('org.jetbrains.kotlin.jvm') version "${kotlinVersion}"
id('groovy')
id('org.jetbrains.kotlin.kapt') version "${kotlinVersion}"
id('com.github.johnrengelman.shadow') version '7.+'
id('io.micronaut.application') version '2.+'
id('org.jetbrains.kotlin.plugin.allopen') version "${kotlinVersion}"
id('com.google.cloud.tools.jib') version '3.+'
id('org.openapi.generator') version '5.+'
id('com.heroku.sdk.heroku-gradle') version '2.+'
}
[...]
micronaut {
runtime('netty')
testRuntime('spock2')
processing {
incremental(true)
annotations('[PACKAGE]')
}
}
Maybe this gives enough information to tackle down the cause of the problem?
If not please let me know.
Regards
I hit the same issue with my Java build and asked for help on gradle slack channel. It found to be a change in Gradle 7.3 behavior.
This issue contains an explanation of the cause and how to fix it.
It helped me to solve the issue with my build: I had options defined in one of the test tasks and then useJUnitPlatform was applied across all test tasks afterwards using this snippet:
tasks.withType(Test).configureEach {
useJUnitPlatform() // <-- this line was breaking the build
}
This broke the build after migrating to Gradle 7.3. Removing options solved the problem for me.
Here's an issue requesting to convert this breaking behavior to a warning in Gradle 7.3 and make it a breaking change in 8.0.
FYI: Upgrade to Gradle 7.3.1 brings back successful builds.
I am working on switching a module inside an existing spring-boot project to use spring native. My nativeBuild is failing with the error below.
Fatal error:com.oracle.graal.pointsto.util.AnalysisError$ParsingError:
Error encountered while parsing
com.fasterxml.jackson.core.JsonFactory._createGenerator(java.io.Writer,
com.fasterxml.jackson.core.io.IOContext) Parsing context: parsing
com.fasterxml.jackson.core.JsonFactory.createGenerator(JsonFactory.java:1318)
parsing
com.fasterxml.jackson.databind.ObjectMapper.createGenerator(ObjectMapper.java:1164)
parsing
com.fasterxml.jackson.databind.ObjectMapper.writeValue(ObjectMapper.java:3725)
parsing a.b.c.Util.writeManifest(Util.java:61)
Caused by:
org.graalvm.compiler.java.BytecodeParser$BytecodeParserError:
com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No
instances of com.fasterxml.jackson.core.io.SerializedString are
allowed in the image heap as this class should be initialized at image
runtime. To see how this object got instantiated use
--trace-object-instantiation=com.fasterxml.jackson.core.io.SerializedString.
at parsing
com.fasterxml.jackson.core.JsonFactory.(JsonFactory.java:186) at
jdk.internal.vm.compiler/org.graalvm.compiler.java.BytecodeParser.throwParserError(BytecodeParser.java:2601)
This is triggered at this piece of code:
ObjectMapper mapper = new ObjectMapper();
mapper.writeValue(writer, convertedResults);
I am using:
id 'org.springframework.boot' version '2.5.2' id
'org.springframework.experimental.aot' version '0.10.1' id
'org.graalvm.buildtools.native' version '0.9.0' nativeBuild {
buildArgs("--trace-object-instantiation=com.fasterxml.jackson.core.io.SerializedString
--verbose -H:+ReportExceptionStackTraces") }
openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment
GraalVM CE 21.1.0 (build 11.0.11+8-jvmci-21.1-b05) OpenJDK 64-Bit
Server VM GraalVM CE 21.1.0 (build 11.0.11+8-jvmci-21.1-b05, mixed
mode, sharing)
I tried reproducing this issue in a standalone spring native project, however, did not run into the same problem.
Would you have any pointers on how I can go about investigating this further?
Thanks!
I'm trying to configure the Test task inside a custom Gradle plugin written in Java.
Applying the plugins I need like so in build.gradle.kts:
plugins {
`java-gradle-plugin`
`maven-publish`
}
I can compile the code successfully through the command line as in ./gradlew clean build
But, IntelliJ complains about Test.class in the following code:
public static void configureTesting(final Project project) {
project.getTasks().withType(Test.class).configureEach(task -> {
});
}
Saying:
Required type: java.lang.Class <S>
Provided: java.lang.Class <Test>
reason: no instance(s) of type variable(s) exist so that T conforms to Task
I import the Test class like this:
import org.gradle.api.tasks.testing.Test;
Gradle version: 6.7.1
IntelliJ: 2020.2.3
I spent some (a lot of) time googling this. Eventually I found a comment somewhere saying that one could try to use the internal SDK (jbr) that ships with IntelliJ instead of a manually downloaded SDK. That made it work. The internal SDK is Java 11 and I've also installed the latest version of Java 11 from Oracle. Even though they are both Java 11, the internal SDK (jbr) is working as it should, but not the external SDK. For other projects the external SDK is working fine, but not for building a Gradle plugin.
I am trying to deploy my war file on jetty 9.4 ( tried both 9.4.0 and 9.4.8 with asm 5.1 and 6 respectively). I am getting below error. I am using java 1.8 for development
java.lang.RuntimeException: Error scanning entry org/aspectj/org/eclipse/jdt/internal/compiler/parser/UpdateParserFiles.class from jar file:///tmp/jetty-0.0.0.0-8080-xxxxx-service-8.0.0.0000-SNAPSHOT.war-_xxxx-8.0.0.0000-SNAPSHOT-any-4304648590162252598.dir/webapp/WEB-INF/lib/aspectjtools-1.8.13.jar
at org.eclipse.jetty.annotations.AnnotationParser.lambda$parseJar$0(AnnotationParser.java:883)
at java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:2893)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at org.eclipse.jetty.annotations.AnnotationParser.parseJar(AnnotationParser.java:875)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:839)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:161)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:468)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.lang.Thread.run(Thread.java:745)
Caused by:
java.lang.ArrayIndexOutOfBoundsException: 3379
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:171)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:143)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:418)
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:933)
at org.eclipse.jetty.annotations.AnnotationParser.parseJarEntry(AnnotationParser.java:918)
at org.eclipse.jetty.annotations.AnnotationParser.lambda$parseJar$0(AnnotationParser.java:879)
at java.util.TreeMap$ValueSpliterator.forEachRemaining(TreeMap.java:2893)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at org.eclipse.jetty.annotations.AnnotationParser.parseJar(AnnotationParser.java:875)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:839)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:161)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:468)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.lang.Thread.run(Thread.java:745)
The cause of that error is likely that you have too old of an ASM jar on the server side classpath.
I know you said you have already tried newer versions, but have you checked all the jars on your server classpath for all possible instances of ASM classes?
If you are using embedded-jetty, pay attention to your server Classpath, be 100% sure you don't have those ASM classes in multiple jars!
Also, under some configurations in embedded-jetty, the webapp's own WEB-INF/lib/*.jar could be used to scan the classes in that webapp. Which means an incompatible WEB-INF/lib/asm*.jar could be causing you problems.
For Java 1.8 bytecode and runtime, use ASM 5.1+
For Java 9 bytecode and runtime, use ASM 6+
The other issue is that you could have classes in that jar WEB-INF/lib/aspectjtools-1.8.13.jar which are for a bytecode that is higher then your runtime JVM (or ASM) can handle.
If you are working with JEP 238 (Multi-Release JAR spec) jars then this is more common, but I don't think aspectjtools-1.8.13.jar is one of those (note: haven't actually downloaded that jar and studied it)
See Eclipse Jetty Issue #1797 for more about JEP 238