As I wanted to reproduce the problem on my local machine with SQ 6.7.6 and Java Plugin 5.11, I ran into seemingly similar problems with different files:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:657)
at java.util.ArrayList.get(ArrayList.java:433)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveClassType(TypeAndReferenceSolver.java:428)
and
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:657)
at java.util.ArrayList.get(ArrayList.java:433)
at org.sonar.java.resolve.TypeSubstitutionSolver.getReturnType(TypeSubstitutionSolver.java:106)
In the first case symbols.classType.getSymbol().typeVariableTypes is an empty ArrayList, in the second case classSymbol.typeVariableTypes is also an empty ArrayList.
Do you have any idea what might cause these problems? I am currently still lost since the analysis did work correctly before upgarding the Java plugin.
I managed to trigger the exception with the following simple class:
public class Test1 {
private static final String NAME = Test1.class.getSimpleName();
}
resulting in the following exception:
[ERROR] 14:38:13.439 Unable to create symbol table for : C:\work\test-project\src\main\java\Test1.java
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:657)
at java.util.ArrayList.get(ArrayList.java:433)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveClassType(TypeAndReferenceSolver.java:428)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:382)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:371)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:364)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveMethodSymbol(TypeAndReferenceSolver.java:341)
at org.sonar.java.resolve.TypeAndReferenceSolver.visitMethodInvocation(TypeAndReferenceSolver.java:236)
at org.sonar.java.model.expression.MethodInvocationTreeImpl.accept(MethodInvocationTreeImpl.java:96)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:408)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:371)
at org.sonar.java.resolve.TypeAndReferenceSolver.resolveAs(TypeAndReferenceSolver.java:364)
at org.sonar.java.resolve.TypeAndReferenceSolver.visitVariable(TypeAndReferenceSolver.java:909)
at org.sonar.java.model.declaration.VariableTreeImpl.accept(VariableTreeImpl.java:185)
at org.sonar.plugins.java.api.tree.BaseTreeVisitor.scan(BaseTreeVisitor.java:40)
at org.sonar.plugins.java.api.tree.BaseTreeVisitor.scan(BaseTreeVisitor.java:34)
at org.sonar.java.resolve.TypeAndReferenceSolver.visitClass(TypeAndReferenceSolver.java:144)
at org.sonar.java.model.declaration.ClassTreeImpl.accept(ClassTreeImpl.java:202)
at org.sonar.plugins.java.api.tree.BaseTreeVisitor.scan(BaseTreeVisitor.java:40)
at org.sonar.plugins.java.api.tree.BaseTreeVisitor.scan(BaseTreeVisitor.java:34)
at org.sonar.plugins.java.api.tree.BaseTreeVisitor.visitCompilationUnit(BaseTreeVisitor.java:52)
at org.sonar.java.resolve.SemanticModel.createFor(SemanticModel.java:66)
at org.sonar.java.model.VisitorsBridge.visitFile(VisitorsBridge.java:121)
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:113)
at org.sonar.java.JavaSquid.scan(JavaSquid.java:107)
at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:92)
....
Doe anybody have any idea what might be the underlying problem?
You’re welcome.
But it is still a mistery that adding a dependency leads to exceptions in the SQ analysis. And this did not happen in 5.10, as the dependecy was already in use then.
I suspect that your code transitively depends on a class within this jar (or in one of its dependency) that makes the analyzer raise this index out of bound.
This might be hard to solve without identifying the class causing the trouble.
In order to investigate this could you try to share a small project reproducing the issue ?
I created following ticket to track this issue https://jira.sonarsource.com/browse/SONARJAVA-3167 , I tried to investigate the root issue, however it seems to be quite difficult. We plan to rework our semantic engine, and I believe this will be fixed in the rework eventually.