You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Christopher Smith (Jira)" <ji...@apache.org> on 2023/02/08 20:36:00 UTC
[jira] [Updated] (GROOVY-10929) Method closure somehow doesn't match argument
[ https://issues.apache.org/jira/browse/GROOVY-10929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Smith updated GROOVY-10929:
---------------------------------------
Description:
I do not understand at all how this is happening, but when I pass class literals to a method closure whose parameter is a {{Class}}, I'm getting {{MissingMethodException}}. This seems to have something to do with ASTTs, because it only happens when {{TupleConstructor}} is involved. In my business code, {{TupleConstructor}} on a top-level containing class triggers the error on a static nested class; I have a repro, but I'm only able to make it trigger on the specific class involved.
In any case, in my business code I'm using {{@CompileStatic}}, but that doesn't seem to be protecting me against runtime dynamic dispatch.
{code:groovy}
//@Grab(group = 'software.amazon.awssdk', module = 'dynamodb-enhanced', version = '2.19.25')
class BugRepl extends Specification {
Function<Class<?>, TableSchema<?>> func = TableSchema.&fromClass
def 'top-level'() {
expect:
func.apply(TopLevel)
}
def 'nested'() {
expect:
func.apply(TopLevel.Nested)
}
}
@DynamoDbBean
@TupleConstructor(defaults = false)
class TopLevel {
String id
@DynamoDbPartitionKey
String getId() { id }
@DynamoDbBean
@ToString
static class Nested {
String id
@DynamoDbPartitionKey
String getId() { id }
}
}
{code}
{code}
Condition failed with Exception:
func.apply(TopLevel)
| | |
| | class com.example.TopLevel
| groovy.lang.MissingMethodException: No signature of method: org.codehaus.groovy.runtime.MethodClosure.fromClass() is applicable for argument types: (Class) values: [class com.example.TopLevel]
| Possible solutions: getClass(), metaClass(groovy.lang.Closure)
| at com.example.BugRepl.top-level(BugRepl.groovy:19)
org.codehaus.groovy.runtime.MethodClosure@6a472566
{code}
I'm tagging this as critical because it's a "can't-possibly-happen" bug (at least in static mode) that has apparently been latent in an internal library for months and is still present as of 4.0.8.
was:
I do not understand at all how this is happening, but when I pass class literals to a method closure whose parameter is a {{Class}}, I'm getting {{MissingMethodException}}. This seems to have something to do with ASTTs, because it only happens when {{TupleConstructor}} is involved. In my business code, {{TupleConstructor}} on a top-level containing class triggers the error on a static nested class; I have a repro, but I'm only able to make it trigger on the specific class involved.
In any case, in my business code I'm using {{@CompileStatic}}, but that doesn't seem to be protecting me against runtime dynamic dispatch.
{code:groovy}
class BugRepl extends Specification {
Function<Class<?>, TableSchema<?>> func = TableSchema.&fromClass
def 'top-level'() {
expect:
func.apply(TopLevel)
}
def 'nested'() {
expect:
func.apply(TopLevel.Nested)
}
}
@DynamoDbBean
@TupleConstructor(defaults = false)
class TopLevel {
String id
@DynamoDbPartitionKey
String getId() { id }
@DynamoDbBean
@ToString
static class Nested {
String id
@DynamoDbPartitionKey
String getId() { id }
}
}
{code}
{code}
Condition failed with Exception:
func.apply(TopLevel)
| | |
| | class com.example.TopLevel
| groovy.lang.MissingMethodException: No signature of method: org.codehaus.groovy.runtime.MethodClosure.fromClass() is applicable for argument types: (Class) values: [class com.example.TopLevel]
| Possible solutions: getClass(), metaClass(groovy.lang.Closure)
| at com.example.BugRepl.top-level(BugRepl.groovy:19)
org.codehaus.groovy.runtime.MethodClosure@6a472566
{code}
I'm tagging this as critical because it's a "can't-possibly-happen" bug (at least in static mode) that has apparently been latent in an internal library for months and is still present as of 4.0.8.
> Method closure somehow doesn't match argument
> ---------------------------------------------
>
> Key: GROOVY-10929
> URL: https://issues.apache.org/jira/browse/GROOVY-10929
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 4.0.8
> Reporter: Christopher Smith
> Priority: Critical
>
> I do not understand at all how this is happening, but when I pass class literals to a method closure whose parameter is a {{Class}}, I'm getting {{MissingMethodException}}. This seems to have something to do with ASTTs, because it only happens when {{TupleConstructor}} is involved. In my business code, {{TupleConstructor}} on a top-level containing class triggers the error on a static nested class; I have a repro, but I'm only able to make it trigger on the specific class involved.
> In any case, in my business code I'm using {{@CompileStatic}}, but that doesn't seem to be protecting me against runtime dynamic dispatch.
> {code:groovy}
> //@Grab(group = 'software.amazon.awssdk', module = 'dynamodb-enhanced', version = '2.19.25')
> class BugRepl extends Specification {
> Function<Class<?>, TableSchema<?>> func = TableSchema.&fromClass
> def 'top-level'() {
> expect:
> func.apply(TopLevel)
> }
> def 'nested'() {
> expect:
> func.apply(TopLevel.Nested)
> }
> }
> @DynamoDbBean
> @TupleConstructor(defaults = false)
> class TopLevel {
> String id
> @DynamoDbPartitionKey
> String getId() { id }
> @DynamoDbBean
> @ToString
> static class Nested {
> String id
> @DynamoDbPartitionKey
> String getId() { id }
> }
> }
> {code}
> {code}
> Condition failed with Exception:
> func.apply(TopLevel)
> | | |
> | | class com.example.TopLevel
> | groovy.lang.MissingMethodException: No signature of method: org.codehaus.groovy.runtime.MethodClosure.fromClass() is applicable for argument types: (Class) values: [class com.example.TopLevel]
> | Possible solutions: getClass(), metaClass(groovy.lang.Closure)
> | at com.example.BugRepl.top-level(BugRepl.groovy:19)
> org.codehaus.groovy.runtime.MethodClosure@6a472566
> {code}
> I'm tagging this as critical because it's a "can't-possibly-happen" bug (at least in static mode) that has apparently been latent in an internal library for months and is still present as of 4.0.8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)