Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0-beta-5
-
None
-
None
-
ArchLinux 0.6 w/ jdk 1.4.2_01
Description
public class Test
{
public void doit( Object parameter1, Object parameter2 )
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
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?
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