Bug 327571 - ecj compiles duplicate methods that javac 7 rejects
Summary: ecj compiles duplicate methods that javac 7 rejects
Status: VERIFIED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6.1   Edit
Hardware: PC Windows Server 2003
: P3 normal (vote)
Target Milestone: 3.8 M4   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-12 11:33 EDT by John Crisostomo CLA
Modified: 2011-12-06 05:59 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Crisostomo CLA 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 CLA 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 CLA 2010-10-26 00:39:41 EDT
Verified for 3.7 M3
Comment 3 Ayushman Jain CLA 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 CLA 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 CLA 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 CLA 2011-12-06 05:59:37 EST
Verified for 3.8M4 with build I20111204-2000.