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

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0-beta-5
• Fix Version/s: 1.0-beta-8
• Environment: ArchLinux 0.6 w/ jdk 1.4.2_01
• Assignee: Jeremy Rayner
• Reporter: Chris Poirier
• Created: 17/Feb/04 03:56
• Updated: 11/Dec/04 17:14
• Resolved: 11/Dec/04 17:14

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?