[
https://issues.apache.org/jira/browse/GROOVY-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509148#comment-14509148
]
Jason Winnebeck commented on GROOVY-7362:
-----------------------------------------
I have to report that the override method and @CompileStatic doesn't work
consistently. Depending on how the project is built (whether clean build or
not) and what system you are on, I get different results. Any of the following
might happen:
# It works
# Class fails to load because a bytecode verifier error about an illegal
invokeVirtual call in one of the overridden methods
# Class compiles and loads, but compiler generated call to
GroovyDefaultMethods.getMetaClass instead of the super's method, which causes a
stack overflow
In my case I had an abstract class extending a concrete one, and since the
concrete base class was never instantiated, I could make it abstract. Making
both the classes abstract so far has been working for me and is less intrusive
than overriding all GroovyObject methods.
> 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)
