[
https://issues.apache.org/jira/browse/GROOVY-11193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779212#comment-17779212
]
Eric Milles commented on GROOVY-11193:
--------------------------------------
{quote}
I noticed some "strange" (aka logic that looks unfamiliar even though it should
have been) code for the caller class.
{quote}
It would be helpful to have a specific reference. There were a lot of changes
required to straighten out the "super.method()" class generation and runtime
method indexing. The general approach was to have the "sender" remain the
actual class (source) containing the method invocation. Before Groovy 4, this
was actually the super class, which falls down when the super class is Java or
is not being compiled at the same time -- aka lacks super MOP methods.
Here is a concrete example:
{code:java}
public interface Face {
default void meth() {
System.out.println("default");
}
}
public class Impl implements Face {
}
{code}
{code:groovy}
class Impl2 extends Impl {
@Override
void meth() {
println 'override'
super.meth()
}
}
new Impl2().meth()
{code}
When {{Impl2}} is compiled, Groovy 3 writes "super.meth()" as
"ScriptBytecodeAdapter.invokeMethodOnSuper0(Impl.class, this, "meth")". Groovy
4+ writes it as "ScriptBytecodeAdapter.invokeMethodOnSuper0(Impl2.class, this,
"meth")". MOP method generation and method indexing were changed to match.
>From the runtime, one cannot tell if Groovy 0..3 or Groovy 4+ was used to
>compile the caller AFAIK. And you cannot look at the relation between
>"sender" and "receiver", since you may have extended {{Impl2}} and thus
>"receiver" would be an instance of that type. Thus, once this was in the
>wild, I did not see a way to accommodate pre-compiled libraries as well as new
>Groovy 4+ bytecode. Adding something to the compile stage now could help, but
>would not eliminate the compiled-with-Groovy-4 code that is out there (like
>Spock). Adding {{@CompileStatic}} to code that makes a super call seemed the
>quickest remedy.
Hope this helps at least clarify what is going on for these calls.
> Methods referenced by super cannot be found and are not executed
> ----------------------------------------------------------------
>
> Key: GROOVY-11193
> URL: https://issues.apache.org/jira/browse/GROOVY-11193
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.0
> Reporter: Marek Parfianowicz
> Assignee: Eric Milles
> Priority: Major
> Attachments: bug.zip
>
>
> When one method calls another method from a parent class via {{super}}
> keyword, the code is not executed at all.
> I tested this in version 4.0.0 and 4.0.14 - in both it fails. (x)
> It works correctly in 3.0.19. (/)
> It also fails in 2.5.23, but with a runtime exception -
> "{color:#172b4d}java.lang.AbstractMethodError" (x){color}
> Code to reproduce:
>
> {code:java}
> class MyClassBase {
> void setUp() {
> System.out.println("Called MyTestBase.setUp")
> }
> }{code}
>
> {code:java}
> class MyClass extends MyClassBase {
> void setUp() {
> super.setUp()
> System.out.println("Called MyTest.setUp")
> }
> static void main(String[] args) {
> System.out.println("About to create MyClass")
> MyClass my = new MyClass();
> my.setUp()
> }
> } {code}
> Output for Groovy 4.0.14:
> {noformat}
> [INFO] --- exec-maven-plugin:3.0.0:java (default) @ bug ---
> About to create MyClass
> [WARNING]
> groovy.lang.MissingMethodException: No signature of method:
> MyClassBase.setUp() is applicable for argument types: () values: []
> Possible solutions: setUp(), getAt(java.lang.String),
> tap(groovy.lang.Closure), sleep(long), sleep(long, groovy.lang.Closure),
> dump()
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap
> (ScriptBytecodeAdapter.java:72)
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN
> (ScriptBytecodeAdapter.java:148)
> at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0
> (ScriptBytecodeAdapter.java:166)
> at MyClass.setUp (MyClass.groovy:3)
> at MyClass$setUp.call (Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall
> (CallSiteArray.java:45)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:125)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call
> (AbstractCallSite.java:130)
> at MyClass.main (MyClass.groovy:10)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
> at java.lang.Thread.run (Thread.java:750)
> {noformat}
> Please see the attached bug.zip sample project.
>
> Workaround:
> Use {{@CompileStatic}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
