Uploaded image for project: 'Groovy'
  1. Groovy
  2. GROOVY-200

at runtime, groovy incorrectly fails when choosing between signature-specialized versions of a method

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.0-beta-5
    • 1.0-beta-8
    • None
    • None
    • ArchLinux 0.6 w/ jdk 1.4.2_01

    Description

      public class Test
      {
      public void doit( Object parameter1, Object parameter2 )

      { System.out.println( "TestChild::doit( Object, Object )" ); }

      public void doit( Boolean parameter1, Object parameter2 )

      { System.out.println( "TestChild::doit( Boolean, Object )" ); }

      public void doit( Object parameter1, Boolean parameter2 )

      { System.out.println( "TestChild::doit( Object, Boolean )" ); }

      public void doit( Boolean parameter1, Boolean parameter2 )

      { System.out.println( "TestChild::doit( Boolean, Boolean )" ); }

      public static void main( String[] args )
      {
      try

      { o = new Test(); System.out.println( "Calling Test.doit( Boolean, Boolean ) -- expect Boolean, Boolean" ); o.doit( true, true ); System.out.println(""); System.out.println( "Calling Test.doit( Boolean, Integer ) -- expect Boolean, Object" ); o.doit( true, 9 ); System.out.println(""); System.out.println( "Calling Test.doit( Integer, Boolean ) -- expect Object, Boolean" ); o.doit( 9, true ); System.out.println(""); System.out.println( "Calling Test.doit( Integer, Integer ) -- expect Object, Object" ); o.doit( 9, 9 ); }

      catch( java.lang.Throwable e )

      { System.out.println(""); System.out.println( "FAIL! Caught exception: " + e.toString() ); e.printStackTrace(); }

      }
      }

      The first test (o.doit(true, true)) fails at runtime with:
      groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method: doit. Cannot resolve which method to invoke due to overlapping prototypes between: [class java.lang.Boolean, class java.lang.Object] and: [class java.lang.Object, class java.lang.Boolean]

      In this case, there is a method that exactly matches the parameters being called, and it isn't even mentioned in the ambiquity list.

      If the class is reorganized so that the matching method comes before the two listed in the ambiquity list, all tests succeed.

      One final point, should there be a runtime error for ambiguity in a scripting language? Shouldn't the runtime pick one?

      Attachments

        1. 200.patch
          1 kB
          Jochen Theodorou

        Activity

          jstrachan James Strachan added a comment -

          Well spotted

          If the runtime method dispatcher cannot decide which method to choose, it should fail rather than being non-deterministic and randomly picking one.

          But yes this looks like a bug

          jstrachan James Strachan added a comment - Well spotted If the runtime method dispatcher cannot decide which method to choose, it should fail rather than being non-deterministic and randomly picking one. But yes this looks like a bug
          jstrachan James Strachan added a comment -

          BTW fancy adding this to a unit test case in src/test/org/codehaus/groovy/runtime/*Test.java. There's a bunch of test cases in there for these kinds of things - it'd be a good place to keep this test case

          jstrachan James Strachan added a comment - BTW fancy adding this to a unit test case in src/test/org/codehaus/groovy/runtime/*Test.java. There's a bunch of test cases in there for these kinds of things - it'd be a good place to keep this test case
          jstrachan James Strachan added a comment -

          I've added a test case to src/test/groovy/bugs/MethodDispatchBug.groovy.

          This seems to work for me - fancy patching this file to reproduce your issue?

          jstrachan James Strachan added a comment - I've added a test case to src/test/groovy/bugs/MethodDispatchBug.groovy. This seems to work for me - fancy patching this file to reproduce your issue?
          jstrachan James Strachan added a comment -

          Hmm, this works fine inside Eclipse but fails when running things in the Maven build. Bizarre

          jstrachan James Strachan added a comment - Hmm, this works fine inside Eclipse but fails when running things in the Maven build. Bizarre
          bob Bob Paulin added a comment -

          testing notifications

          bob Bob Paulin added a comment - testing notifications
          cpoirier Chris Poirier added a comment -

          Hi James, my build of groovyc still fails on this issue (at runtime, of course).

          cpoirier Chris Poirier added a comment - Hi James, my build of groovyc still fails on this issue (at runtime, of course).
          jstrachan James Strachan added a comment -

          fancy taking a stab at this one ?

          no biggie, unassign it if you don't fancy it

          jstrachan James Strachan added a comment - fancy taking a stab at this one ? no biggie, unassign it if you don't fancy it

          I wrote some code (see patch) testing first for an exact match. With this the code metnioned in this issue works as expected. I didn't commit it because currently I'm not able to run the test cases

          blackdrag Jochen Theodorou added a comment - I wrote some code (see patch) testing first for an exact match. With this the code metnioned in this issue works as expected. I didn't commit it because currently I'm not able to run the test cases

          I commited a slightly changed patch

          blackdrag Jochen Theodorou added a comment - I commited a slightly changed patch

          People

            jez Jeremy Rayner
            cpoirier Chris Poirier
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: