[
https://issues.apache.org/jira/browse/GROOVY-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-12363:
-------------------------------
Summary: Anonymous inner class declared in a @CompileStatic method: super
call fails with MissingMethodException (no MOP bridge generated) (was: Native
image: MOP super call from a dynamic subclass fails with MissingMethodException)
> Anonymous inner class declared in a @CompileStatic method: super call fails
> with MissingMethodException (no MOP bridge generated)
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12363
> URL: https://issues.apache.org/jira/browse/GROOVY-12363
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
>
> *Suggested retitle:* "Anonymous inner class declared in a @CompileStatic
> method: super call fails with MissingMethodException (no MOP bridge
> generated)". This was first seen in a GraalVM native image, but it reproduces
> on a plain JVM and on Groovy 5.1.2 as well as 6.0 master; native image is not
> a factor.
> An anonymous inner class declared inside a method annotated with
> {{@CompileStatic}} (the enclosing *class* is not annotated) that calls
> {{super.someMethod(...)}} fails at run time:
> {noformat}
> groovy.lang.MissingMethodException: No signature of method: publish for
> class: java.util.logging.StreamHandler is applicable for argument types:
> (java.util.logging.LogRecord) values: [java.util.logging.LogRecord@783a467b]
> Possible solutions: publish(java.util.logging.LogRecord),
> publish(java.util.logging.LogRecord)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:85)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:156)
> at Holders$1.publish(Repro.groovy:6)
> {noformat}
> h3. Reproducer
> {code:groovy}
> import java.util.logging.*
> class Holders {
> @groovy.transform.CompileStatic
> static Logger csLogger() {
> def l = Logger.getLogger('cs'); l.useParentHandlers = false
> l.addHandler(new StreamHandler(System.out, new SimpleFormatter()) {
> void publish(LogRecord r) { super.publish(r); flush() } })
> l
> }
> static Logger dynLogger() { // identical, no annotation
> def l = Logger.getLogger('dyn'); l.useParentHandlers = false
> l.addHandler(new StreamHandler(System.out, new SimpleFormatter()) {
> void publish(LogRecord r) { super.publish(r); flush() } })
> l
> }
> }
> Holders.dynLogger().info('works')
> Holders.csLogger().info('fails') // MissingMethodException
> {code}
> Putting {{@CompileStatic}} on the class {{Holders}} instead of the method
> makes it work (the super call then compiles to {{invokespecial}}). The JDK
> superclass is not essential; any {{super}} call from such an anonymous class
> takes the same path.
> h3. Root cause
> The two anonymous classes compile to *identical* bytecode for the super call,
> {{ScriptBytecodeAdapter.invokeMethodOnSuperN(Holders$1.class, this,
> "publish", args)}}, i.e. a dynamic MOP super call. That call only works if
> the class carries the compiler-generated {{super$N$publish}} bridge, which
> the MOP uses to reach the superclass implementation
> ({{MetaMethodIndex.methodsForSuper}}). {{javap}} shows the difference:
> {noformat}
> Holders$1 (in @CompileStatic method): public void publish(LogRecord)
> Holders$2 (in dynamic method): public void publish(LogRecord)
> public void super$3$publish(LogRecord)
> {noformat}
> With no bridge, {{MetaClassImpl.getSuperMethodWithCaching}} finds
> {{methodsForSuper == null}} and the call ends in {{invokeMissingMethod}}.
> The inconsistency comes from the order in which {{StaticCompilationVisitor}}
> marks things:
> # {{visitClass(outer)}} marks every inner class, including the anonymous one,
> with {{STATIC_COMPILE_NODE = false}} because the outer class is not
> statically compiled (the {{isSC}} computation over
> {{node.getInnerClasses()}}).
> # The type checker then visits the anonymous class body from the constructor
> call. At that point {{isStaticallyCompiled(publish)}} resolves through the
> declaring class to {{false}}, so the {{super.publish(r)}} call gets no
> {{DIRECT_METHOD_CALL_TARGET}} and no {{SUPER_MOP_METHOD_REQUIRED}} entry is
> recorded.
> # Only afterwards does {{visitConstructorCallExpression}} flip the anonymous
> class to {{STATIC_COMPILE_NODE = true}} (copied from the enclosing method)
> and give it the static {{WriterControllerFactory}}.
> # At class generation the class is therefore treated as statically compiled:
> {{StaticTypesWriterController}} uses {{StaticCompilationMopWriter}}, which
> emits bridges only for the (empty) {{SUPER_MOP_METHOD_REQUIRED}} list, while
> the method body, lacking a direct target, falls back to the dynamic
> {{invokeMethodOnSuperN}}.
> So the class is compiled as "static" for the purpose of omitting MOP bridges
> and as "dynamic" for the purpose of the call itself.
> h3. Expected
> Either outcome is acceptable as long as both halves agree: the anonymous
> class body should be statically compiled like the enclosing method (matching
> the class-level {{@CompileStatic}} behaviour and giving an
> {{invokespecial}}), or, if it stays dynamic, the ordinary {{MopWriter}} must
> still generate the {{super$}} bridges. Marking the anonymous class from the
> enclosing method's flag *before* its body is type-checked (in
> {{visitConstructorCallExpression}} ahead of
> {{super.visitConstructorCallExpression}}, or when {{visitClass}} marks inner
> classes) would give the first.
> Verified on Groovy 6.0.0-SNAPSHOT master and 5.1.2 on JDK 21, and inside a
> GraalVM 25.2.4 native image where it was first noticed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
