[
https://issues.apache.org/jira/browse/GROOVY-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15424317#comment-15424317
]
Jochen Theodorou commented on GROOVY-7655:
------------------------------------------
If the library is precompiled with pre 2.4, then the code there already
contains the helper method. And if it is there, it will be used. So unless you
recompile, there is no problem. Of course there is then still a problem once
they recompile. But that is the case already if you use 2.3 and they use 2.4 to
compile.
I do agree, that this has to be fixed for the next release. The question is the
"how" beyond a simple "restore the old behaviour". I would like to keep the
amount of methods at least lowered. Most probably I will make the compiler
recognize the super-call and note that this will require a mop helper method
later on. Then we would still get a big reduction in generated helper methods
compared to 2.4 and it would solve your problem here.
> Wrong method is chosen when using super with generics
> -----------------------------------------------------
>
> Key: GROOVY-7655
> URL: https://issues.apache.org/jira/browse/GROOVY-7655
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.4.4
> Reporter: Marius Vaitkus
> Attachments: generics_extension_test.groovy
>
>
> Given code:
> {code:title=generics_extension_test.groovy}
> interface ParamInterface{}
> class ParamImplementation implements ParamInterface{}
> class ParamExtension extends ParamImplementation {}
> class A<T extends ParamInterface> {
> def getResult(T a) {
> return "A"
> }
> }
> class B<T extends ParamImplementation> extends A<T> {
> def getResult(T b) {
> return "B"
> }
> }
> class C extends B<ParamExtension> {
> @Override
> def getResult(ParamExtension b) {
> return super.getResult(b)
> }
> }
> String result = new C().getResult(new ParamExtension())
> assert result == "B"
> {code}
> I get output:
> {code}
> Assertion failed:
> assert result == "B"
> | |
> A false
> at generics_extension_test.run(generics_extension_test.groovy:31)
> {code}
> When calling super method, instead of looking for method in a class one
> hierarchy bellow, groovy goes through complex calculations for finding a
> better method. I debug'ed up to a point in
> groovy.lang.MetaClassImpl#chooseMostSpecificParams
> where it turned out that distance for interface was 2 and distance for class
> that directly extends the method was much bigger, therefore the method from
> class A is chosen instead of method from class B. However, looking
> objectively, it would seem that B.getResult is a much better fit:
> C extends B and B extends A
> parameter hierarchy is shorter (ParamExtension -> ParamImplementation ->
> ParamInterface)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
