Skip to content

Incorrect call hierarchy #141

@doktorjw

Description

@doktorjw

I ran across this trying to debug why some unit tests weren't working from within eclipse Mars, but they pass via the maven command line. I'm using eclipse Mars with groovy-eclipse 2.9.2.xx-2015081211448-e45 using the groovy compiler 2.4.3.

In a class hierarchy, one of the classes in the hierarchy has it's method skipped in favor of it's parent when invoked with super.. Via the command line with groovy 2.4.3 (not the eclipse compiler), execution is correct, or via eclipase with the 2.3.x compiler, it's correct.

What's I've built is this hierarchy:

package com.foo

class A {
  boolean aCalled = false

  protected Map itemAsMap( def item ) {
    println "A itemAsMap"
    aCalled = true
    return [:]
  }
}
package com.foo

class B extends A {
  boolean bCalled = false

  protected Map itemAsMap( def item ) {
    println "B itemAsMap"
    super.itemAsMap( item )
    bCalled = true
    return [:]
  }
}

package com.foo

class C extends B {
  boolean cCalled = false

  protected List flattenAsMap( def item ) {
    println "C flattenAsMap"
    super.itemAsMap( item )
    cCalled = true
    return []
  }
}
package com.foo

import org.junit.Test

class CTest {
  @Test
  public void test() {
    def c = new C()
    def ret = c.flattenAsMap( "stuff" )
    assert c.aCalled
    assert c.bCalled  // 2.4 within eclipse fails here.
    assert c.cCalled
  }
}

When run from within Eclipse with the 2.4.3 groovy-eclipse compiler, I get the incorrect result:

C flattenAsMap
A itemAsMap

and the test fails on the line indicated.

When run with the earlier 2.3.10 compiler, or via 2.4 on the commandline (avoiding groovy-eclipse), I get the correct output:

C flattenAsMap
B itemAsMap
A itemAsMap

As you can see, with the 2.4.3 compiler within eclipse, the call to class B is skipped.

Interestingly enough, if the super.itemAsMap(...) call in class C is replaced with just itemAsMap(...) (eliminating the super keyword), than all is fine and the hierarchy of calls is as expected. It's as if the super call is resulting in an incorrect advancement up the hierarchy by one level, skipping the immediate parent. This is similar to the groovy issue report at https://issues.apache.org/jira/browse/GROOVY-6663

For now, no 2.4.x compiler for me within Mars.

1/20/2016 - made an edit as I missed the "super" calls in the sample code (don't know how I missed that on the initial report ... likely I was manually transcribing code from my VM to this post).

4/13/2016 - simplified the test case, and provided a real unit test. Also added link to similar groovy issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions