Bug 139099 - [compiler] Ambiguous method regression error
Summary: [compiler] Ambiguous method regression error
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 3.2 RC3   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-27 19:38 EDT by George Lindholm CLA
Modified: 2006-05-04 10:49 EDT (History)
2 users (show)

See Also:

Attachments
Patch (6.71 KB, patch)
2006-05-02 13:18 EDT, Kent Johnson CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description George Lindholm CLA 2006-04-27 19:38:49 EDT 
public class Foo {
    public Foo() {
    }
    public static void main(String[] args) {
        Foo l = new Foo();
        StringBuffer sb = new StringBuffer();
        sb.append(l);
    }
}

with "Compiler compliance level: 5.0" and "Source Compatibility: 1.4" is fine
with 3.1.2, but 3.2 gives me the error:

  The method append(Object) is ambiguous for the type StringBuffer

JVM 1.5.0_06-b05
Comment 1 Philipe Mulet CLA 2006-04-28 09:13:35 EDT 
Cannot reproduce in latest 3.2. 
Added LookupTest#test068
Comment 2 George Lindholm CLA 2006-04-28 14:10:02 EDT 
Is that the same as eclipse-SDK-I20060428-0010?

I just installed it in a virgin directory and with a virgin
workspace I still see the same problem.
Comment 3 Olivier Thomann CLA 2006-04-28 14:17:24 EDT 
Reproduced with latest.
Kent, any idea?
Comment 4 Kent Johnson CLA 2006-04-28 15:25:52 EDT 
Philippe - have a fix for this.

When compliance is >= 5.0 but source is less, we should not 'see' bridge methods.
Comment 5 Philipe Mulet CLA 2006-04-30 09:04:02 EDT 
+1 for 3.2RC3.

Jeff - pls cast your vote. This is a scenario where 1.5 JRE is used with 1.4 source level...

Kent - pls attach your patch. You need to wait until second vote got casted to get clearance.
Comment 6 Philipe Mulet CLA 2006-04-30 16:36:45 EDT 
BTW - I did miss the -source 1.4 in my testcase (LookupTest#test068). I tuned the test, and indeed reproduced the issue. 
Kent - pls reenable the test once the fix is made available.
Comment 7 Kent Johnson CLA 2006-05-01 13:15:34 EDT 
This is related to the fix for bug 124943
Comment 8 Kent Johnson CLA 2006-05-01 14:35:08 EDT 
Other related bugs are bug 81535 and bug 128560
Comment 9 Jeff McAffer CLA 2006-05-01 22:26:33 EDT 
no patch attached.  Can't tell how widespread the change is.
Comment 10 Philipe Mulet CLA 2006-05-02 09:32:18 EDT 
Kent - pls attach the patch asap (hoping bugzilla doesn't go down again)
Comment 11 Kent Johnson CLA 2006-05-02 13:18:13 EDT 
Created attachment 40062 [details]
Patch

The simple fix didn't work for all the cases from the related bugs.

Instead we needed to remove the change to BinaryTypeBinding for bug 124943, which became unnecessary with the changes to mostSpecificMethod from last month.

Then we needed to allow compatible (but not equal) return types in inherited methods from binary types, when the source level < 1.5 but the compliance >= 1.5.

Without this change, we think a method does not override the other because of compatible, but not equal return types (allowed in 1.5, but not 1.4).

Patch is attached. It looks bigger than it is because we moved a method up from MethodVerifier15.
Comment 12 Jeff McAffer CLA 2006-05-02 15:16:59 EDT 
+1 looks like fun
Comment 13 Kent Johnson CLA 2006-05-02 15:19:59 EDT 
Enabled LookupTest#test068
Comment 14 Olivier Thomann CLA 2006-05-03 10:45:57 EDT 
Verified using N20060503-0010 for 3.2RC3
Comment 15 Frederic Fusier CLA 2006-05-04 10:49:00 EDT 
Double-checked using N20040504-0010 + JDT/Core v_663