[
https://issues.apache.org/jira/browse/GROOVY-10124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422612#comment-17422612
]
Mauro Molinari commented on GROOVY-10124:
-----------------------------------------
This indeed was the source of a pair of headaches in Eclipse, as reported at:
https://github.com/groovy/groovy-eclipse/issues/1300
https://github.com/groovy/groovy-eclipse/issues/1301
The main problem is that the consequences of this will rise in other parts of
the code with errors which are simply wrong and won't help you to find the root
cause of the issue.
IMHO Groovy should reject the syntax {{class C extends D}} when {{D}} is a
nested class, or perhaps the Groovy compiler should makes this to be exactly
equivalent to {{class C extends C.D}} so that Java integration is preserved.
> Scope of class header (extends, implements and type parameters) should not
> include class being declared
> -------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-10124
> URL: https://issues.apache.org/jira/browse/GROOVY-10124
> Project: Groovy
> Issue Type: Bug
> Reporter: Eric Milles
> Priority: Major
>
> Similar to GROOVY-8063, the scope of the extends/implements clause is not
> consistent with Java. Consider the following:
> {code:groovy}
> class C extends D {
> class D {
> }
> }
> {code}
> Java compilers give an error like "D cannot be resolved to a type". Groovy
> compiler resolves this without a qualifier. This is a problem for Java
> integration (stubs, IDE, etc.) when the pre-resolved class (compile phase
> CONVERSION) is used. This class compiles fine for Groovy but fails on the
> Java side either by not being able to resolve D or giving a cyclic reference
> error which groovy misses.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
