Bug 37296 - Eclipse compiler error - ambiguous method call
Summary: Eclipse compiler error - ambiguous method call
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows XP
: P3 blocker (vote)
Target Milestone: 3.0 M1   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-06 16:36 EDT by James Howe CLA
Modified: 2003-06-02 06:13 EDT (History)
0 users

See Also:


Attachments
Zip file containing test project showing bug (2.25 KB, application/octet-stream)
2003-05-06 16:53 EDT, James Howe CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Howe CLA 2003-05-06 16:36:43 EDT
The following code does not compile correctly with the Java compiler supplied 
with Eclipse 2.1:

package test;

import junit.framework.TestCase;

public class Test extends TestCase{
public Test(String name) {
	super(name);
}

final private static double TOLERANCE = 1.0e-9;

static public void assertEquals(double expected, double actual) {
	double delta = Math.abs(expected * TOLERANCE);
	assertEquals(expected, actual, delta);
}

public void testAssertEqualsWithInts() {
	assertEquals( 3,  4);
}

}

The compiler erroneously complains that the assertEquals(3, 4) method is 
ambiguous.  Based on information gleaned from chapter 15.12.2.2 of the Java 
spec, this method invocation should not be ambiguous.  Also, the javac compiler 
in JDK 1.4.1_01 compiles this code just fine.  To build, you need to have the 
Eclipse junit.jar in the classpath.  I can provide a zipped Eclipse project if 
necessary.
Comment 1 James Howe CLA 2003-05-06 16:53:15 EDT
Created attachment 4806 [details]
Zip file containing test project showing bug
Comment 2 Kent Johnson CLA 2003-05-08 13:26:31 EDT
So based on your discussion in the newsgroup, do you still believe this is a 
bug? Or do you believe you must qualify the method send?
Comment 3 James Howe CLA 2003-05-08 13:50:20 EDT
It seems that the consensus is that the compiler is adhering to the Java spec.  
I don't care for that behavior, but if that is what the spec says I suppose the 
compiler should adhere to it.
Comment 4 Philipe Mulet CLA 2003-05-12 07:01:24 EDT
Our behavior is conforming to spec 15.12.2. 

Assert.assertEquals(int, int) isn't maximally specific, thus your code is 
ambiguous.

assertEquals(3.0, 4.0) would however work, since your definition of assertEquals
would be maximally specific (in the sense of JLS15.12.2).

Both Jikes and Javac agree with us.
Closing