Bug 327571

Summary:	ecj compiles duplicate methods that javac 7 rejects
Product:	[Eclipse Project] JDT	Reporter:	John Crisostomo <john.crisostomo>
Component:	Core	Assignee:	Srikanth Sankaran <srikanth_sankaran>
Status:	VERIFIED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	amj87.iitr, jarthana, john.crisostomo, srikanth_sankaran
Version:	3.6.1
Target Milestone:	3.8 M4
Hardware:	PC
OS:	Windows Server 2003
Whiteboard:

Description John Crisostomo

2010-10-12 11:33:30 EDT

Build Identifier: ecj 3.6.1

Attached is the source code for 3 java classes. Base and child classes have the same static method. Base class doesn't have generics passed to the parameter of the method forAccountSet. 
When compiling these classes with ecj the following error is reported:

 1. ERROR in TestExecutor.java (at line 18)
 1. ERROR in TestExecutor.java (at line 18)
     ChildRequestTest.forAccountSet(null);
     ChildRequestTest.forAccountSet(null);
                      ^^^^^^^^^^^^^
                      ^^^^^^^^^^^^^
 The method forAccountSet(List<Object>) is ambiguous for the type ChildRequestTest
 The method forAccountSet(List<Object>) is ambiguous for the type ChildRequestTest
 ----------
 ----------
 1 problem (1 error)
 1 problem (1 error)
 


Reproducible: Always

Steps to Reproduce:
Try to compile the following three classes using ecj:
===========================================================
import java.util.List;

public class BaseRequestTest<R extends Object>
{
    public static <R extends Object> BaseRequestTest<R> forAccountSet(List list)
    {
        return null;
    }
}
====================================================
import java.util.List;

import com.gs.fw.common.base.VersionID;

public class ChildRequestTest<R extends Object>
        extends BaseRequestTest
{
    public static <R extends Object> ChildRequestTest<R> forAccountSet(List<R> list)
    {
        return null;
    }
}
===========================================================
public class TestExecutor
{
    public void testMe()
    {
         ChildRequestTest.forAccountSet(null);
    }
}
==============================================================

Comment 1 Ayushman Jain

2010-10-12 14:03:45 EDT

This doesn't compile any longer with java 7 ver. b76. You get the following error:
name clash: <R#1>forAccountSet(List<R#1>) in
 ChildRequestTest and <R#2>forAccountSet(List) in BaseRequestTest have the same
erasure, yet neither overrides the other
    public static <R extends Object> ChildRequestTest<R> forAccountSet(List<R>
                                                         ^
  where R#1,R#2 are type-variables:
    R#1 extends Object declared in method <R#1>forAccountSet(List<R#1>)
    R#2 extends Object declared in method <R#2>forAccountSet(List)
1 error

Eclipse behaviour is thus correct here.
This is a dup of bug 317719.

*** This bug has been marked as a duplicate of bug 317719 ***

Comment 2 Srikanth Sankaran

2010-10-26 00:39:41 EDT

Verified for 3.7 M3

Comment 3 Ayushman Jain

2011-08-09 01:52:55 EDT

Reopening because with HEAD, we no longer report name clash error, but compile the two methods fine, resulting in an "ambiguous method" error at the call site for "forAccountSet(..)"

Comment 4 Srikanth Sankaran

2011-11-21 05:05:50 EST

(In reply to comment #3)
> Reopening because with HEAD, we no longer report name clash error, but compile
> the two methods fine, resulting in an "ambiguous method" error at the call site
> for "forAccountSet(..)"

As of now, on 3.8 stream top of branch, we do issue a name clash error, as does
javac 7b147. We issue a secondary error about ambiguous call while javac7 does
not.

I think this should be closed as WORKSFORME. Ayush, do you agree ?

Comment 5 Ayushman Jain

2011-11-21 05:45:36 EST

(In reply to comment #4)
> (In reply to comment #3)
> > Reopening because with HEAD, we no longer report name clash error, but compile
> > the two methods fine, resulting in an "ambiguous method" error at the call site
> > for "forAccountSet(..)"
> 
> As of now, on 3.8 stream top of branch, we do issue a name clash error, as does
> javac 7b147. We issue a secondary error about ambiguous call while javac7 does
> not.
> 
> I think this should be closed as WORKSFORME. Ayush, do you agree ?

Yup, an ambiguous call error always occurs in name clash cases.

Comment 6 Jay Arthanareeswaran

2011-12-06 05:59:37 EST

Verified for 3.8M4 with build I20111204-2000.