[
https://issues.apache.org/jira/browse/GROOVY-11822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles reassigned GROOVY-11822:
------------------------------------
Assignee: Eric Milles
> metadata methods on static nested class fail compilation if extended class
> uses slightly different signature
> ------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-11822
> URL: https://issues.apache.org/jira/browse/GROOVY-11822
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.29
> Reporter: Björn Kautler
> Assignee: Eric Milles
> Priority: Major
>
> Given the [following
> code|https://groovyconsole.dev/?g=groovy_4_0&codez=eNqNjUsKwkAQRPdzit5FQRvdSUAILswBPEFnbONgTA_d46CE3N34WYuL2hSvXlW1UjPL1N0YtlCItkiR_JmxVZH8wJabcsrSovhLucEVrosFJKXeQgr5tTpRZzx31b8qL8o_TeEaRRNMLL5vsebmENk75zsyg70IDA7AEqXg4VPuSIHvifujwZeHAUY3PgEE2Exx]:
> {code:groovy}@Grab(value = 'org.apache.groovy.geb:geb-spock:8.0.1',
> transitive = false)
> @Grab(value = 'org.apache.groovy.geb:geb-core:8.0.1', transitive = false)
> import geb.spock.GebSpec
> class Foo {
> static class Bar extends GebSpec { }
> }{code}
> If you try to compile it, you get a compiler error
> {quote}The return type of void propertyMissing(java.lang.String,
> java.lang.Object) in Foo$Bar is incompatible with java.lang.Object in
> geb.spock.GebSpec{quote}
> The reason is, that the extended class has a {{propertyMissing}} setter with
> {{Object}} return type instead of {{void}}.
> This is perfectly fine as far as the metaprogramming functionality is
> concerned and works as intended.
> But the Groovy compiler tries to generate a {{void}} version for the static
> nested class and then fails as only the return type of the signature is
> different which cannot work.
> If you would have such metaprogramming methods directly in your code, the
> compiler would fail with a meaningful error telling that you must not use
> those methods on static nested classes which is sad but at least clear.
> So maybe supertypes should be checked for the exact signature used and then
> the same signature should be used to not get a compile error due to return
> types of methods you are not involved in directly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
