[
https://issues.apache.org/jira/browse/GROOVY-8211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16435999#comment-16435999
]
Paul King edited comment on GROOVY-8211 at 4/12/18 5:42 PM:
------------------------------------------------------------
Fixed in 2_5_X and above. On 2_4_X the AIOOBE is avoided but the type parameter
arity mismatch is ignored.
was (Author: paulk):
Fixed.
> ArrayIndexOutOfBoundsException at compilation when accessing a generic type
> with the wrong number of type parameters
> --------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-8211
> URL: https://issues.apache.org/jira/browse/GROOVY-8211
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
> Reporter: M. Justin
> Assignee: Paul King
> Priority: Minor
> Fix For: 2.5.0-rc-2
>
>
> When using @CompileStatic, accessing a method on a type that is specified
> using too few type parameters causes an ArrayIndexOutOfBoundsException to be
> thrown by the Groovy compiler. Furthermore, there is no indication where in
> the code the error occurs, so it can be very difficult to debug the issue.
> {code}@CompileStatic
> class GenericsCompilation {
> def method() {
> Map<String> map
> map.toString() //This line causes the issue
> }
> }{code}
> The output is:
> {code}$ groovyc GenericsCompilation.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> General error during instruction selection: 1
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractPlaceholders(GenericsUtils.java:164)
> at
> org.codehaus.groovy.ast.tools.GenericsUtils.extractPlaceholders(GenericsUtils.java:136)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.typeCheckMethodsWithGenerics(StaticTypeCheckingSupport.java:1338)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.typeCheckMethodsWithGenerics(StaticTypeCheckingSupport.java:1319)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.typeCheckMethodsWithGenericsOrFail(StaticTypeCheckingVisitor.java:4529)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2966)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:317)
> at
> org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:66)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:71)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:196)
> at
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:37)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:166)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1784)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:2119)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:2078)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:164)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1078)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:249)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:123)
> at
> org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:63)
> at
> org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:134)
> at
> org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:178)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:525)
> at
> org.codehaus.groovy.tools.FileSystemCompiler.compile(FileSystemCompiler.java:61)
> at
> org.codehaus.groovy.tools.FileSystemCompiler.doCompilation(FileSystemCompiler.java:217)
> at
> org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompile(FileSystemCompiler.java:150)
> at
> org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompileWithErrorHandling(FileSystemCompiler.java:180)
> at
> org.codehaus.groovy.tools.FileSystemCompiler.main(FileSystemCompiler.java:164)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:109)
> at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:131)
> {code}
> I discovered this issue when doing a refactoring that changed the number of
> type parameters on a type, but missed updating a spot in the code to use the
> correct number of parameters. It was completely unclear to me where or what
> the issue was, other than the fact that it likely had something to do with
> generics.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
