[
https://issues.apache.org/jira/browse/GROOVY-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509005#comment-14509005
]
Jason Winnebeck commented on GROOVY-7362:
-----------------------------------------
I thought this worked for me before, but now I just tried to put it into actual
use, and while it compiled I got a stack overflow when running getMetaClass. In
dynamic mode, the call is delgated to ScriptBytecodeAdapter to call
invokeMethodOnSuperN, but the first thing this does is call getMetaClass so it
can call invokeMethod with isCallToSuper true. This actually sort of makes
sense, since every function call in Groovy goes through the Metaclass.
I annotated all of the GroovyObject override methods with @CompileStatic and it
worked, since it generates in bytecode a call directly to parent class.
> Can't compile Java class extending Groovy abstract class with explicit
> GroovyObject interface
> ---------------------------------------------------------------------------------------------
>
> Key: GROOVY-7362
> URL: https://issues.apache.org/jira/browse/GROOVY-7362
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 2.4.0
> Reporter: Peter Gromov
>
> That's a more advanced version of GROOVY-3877
> Compile classes.groovy:
> {code}
> abstract class AbstractClass extends ConcreteClass implements GroovyObject {}
> class ConcreteClass {}
> {code}
> Then compile JavaClass.java:
> {code}
> public class JavaClass extends AbstractClass {}
> {code}
> You get:
> {quote}
> JavaClass.java:1: error: JavaClass is not abstract and does not override
> abstract method setMetaClass(MetaClass) in GroovyObject
> public class JavaClass extends AbstractClass {
> ^
> 1 error
> {quote}
> That's likely because setMetaClass is added as a synthetic method in
> ConcreteClass and not overridden in AbstractClass.
> This also happens without explicit GroovyObject interface when using joint
> compilation
> (https://youtrack.jetbrains.com/issue/IDEA-137722#comment=27-952814). Before
> generating stubs, "implements GroovyObject" is added to Groovy classes, and
> if it so happens that AbstractClass is visited before ConcreteClass, then
> "implements GroovyObject" will be added to both Groovy classes, but the
> (synthetic) implementations somehow end up being only in ConcreteClass.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
