[
https://issues.apache.org/jira/browse/GROOVY-9565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203266#comment-17203266
]
John Bellassai commented on GROOVY-9565:
----------------------------------------
I have also seen this or a very similar problem in the codebase I work in. I
was able to work around it by removing generic parameters on the
self-referential classes which weren't super helpful for what we were doing
with them, but this is way less than ideal. The same code compiled with no
issue in Groovy 2.4.x.
> StackoverflowError when using an abstract class with generic parameters as
> the return value of a closure
> --------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-9565
> URL: https://issues.apache.org/jira/browse/GROOVY-9565
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 3.x, 2.5.x
> Reporter: Daniel Demus
> Priority: Major
>
> If you try to compile the project at
> [https://github.com/demus-nine/groovy-class-generic-stackoverflowerror]
> groovyc crashes with a StackoverflowError. This happens in
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport#applyGenericsContext(java.util.Map<org.codehaus.groovy.ast.GenericsType.GenericsTypeName,org.codehaus.groovy.ast.GenericsType>,
> org.codehaus.groovy.ast.ClassNode) in this bit of recursive code:
> {code:java}
> if (bound.isArray()) {
> return applyGenericsContext(spec, bound.getComponentType()).makeArray();
> }
> {code}
> although I have seen it throw in other methods in the
> StaticTypeCheckingSupport class.
>
> The class that is being handled is an abstract class with a generic
> parameter, but in the code using the type there aren't enough hints to the
> compiler to resolve the generic constraint, possibly because it is
> self-referential.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
