Community
Participate
Working Groups
This is a FUP of bug 317719. This is the test that Ayush mentioned in bug 317719 comment 36. I have modified the code to use the function too ########### package p; import java.util.ArrayList; import java.util.List; public class ErasureBug { public String output(List<String> integers) { System.out.println("In List<String>"); return ""; } public void output(List doubles) { System.out.println("In List#RawType"); return; } public static void main(String[] args) { new ErasureBug().output(new ArrayList()); } } ######## javac6 gives an error here, but ecj doesn't complain when the project compliance is 1.6.Not giving an error is ok, but in this example, the runtime differ from what is expected otherwise and hence we should better fix it. If the compiler doesn't report an error, I will expect the call to output which takes the rawtype, but with ecj the call is going to List<String>.
Created attachment 202217 [details] proposed fix v1.0 I believe all's not well with the way we compare erasure of one method against the signature of another. This is because what we actually want to check is that if one method is foo(List<String>), and another is foo(List). erasure of first is foo(List), same as the second foo. But with the current approach when we compare params[index].erasure != params[index] , we actually end up comparing List<E> with List. This patch tries to fix that. Passes all tests apart from one, which is a dup of the reported case here. Srikanth, what do you think?
(In reply to comment #1) > Created attachment 202217 [details] > proposed fix v1.0 > > I believe all's not well with the way we compare erasure of one method against > the signature of another. This is because what we actually want to check is > that if one method is foo(List<String>), and another is foo(List). erasure of > first is foo(List), same as the second foo. But with the current approach when > we compare params[index].erasure != params[index] , we actually end up > comparing List<E> with List. > > This patch tries to fix that. Passes all tests apart from one, which is a dup > of the reported case here. > Srikanth, what do you think? (1) Can you please check whether the unrestored part of code from https://bugs.eclipse.org/bugs/attachment.cgi?id=146981 (essentially the changes to MethodBinding.java as others have been restored over two passes) has any effect on this bug without your patch ? (2) Can you check what was eclipse's behavior on this before Kent's original changes went in ? If things matched javac, why and how ? If things didn't match javac, then did it match HEAD without your patch ?
(In reply to comment #2) > (1) Can you please check whether the unrestored part of code from > https://bugs.eclipse.org/bugs/attachment.cgi?id=146981 (essentially > the changes to MethodBinding.java as others have been restored over > two passes) has any effect on this bug without your patch ? No. I tried, but those changes don't have any effect. > (2) Can you check what was eclipse's behavior on this before Kent's > original changes went in ? If things matched javac, why and how ? > If things didn't match javac, then did it match HEAD without your > patch ? I tried 3.5.2 and he behaviour matches the current HEAD behaviour i.e. both are incompatible with javac6. I still stand by my analysis in comment 1.
Patch looks ok to me.
Created attachment 204248 [details] fix + tests Added regression test and updated a previous test to the new behavior (matches javac6 now)
Released commit 7cddbfa7d184b903e6606f21236d46be8958fe44 into HEAD for 3.8M3
Verified for 3.8 M3 using build id: N20111022-2000
