Community
Participate
Working Groups
Build Identifier: I20100312-1448 I don't know if the fix for bug 302358 has introduced a bug that was previously fixed (293384) but, following installation of 3.6M6, I found that the first mentioned error had, indeed, now gone but something very similar to the older error has re-emerged, though the error message is different. The test case for the older error doesn't fail now so I'm not sure if it's an old bug that has resurfaced in a different guise, or a new error introduced by some other change. Note that the test case below compiles without any errors in MyEclipse build 8.0-20091120 (which is built on Eclipse JDT 3.5.1.r351_v20090810-0600-7r88FEoFI0WTo6Az-1qFRHm37ChJ and eclipse platform 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7). It fails using the 3.6M6 build. Reproducible: Always Steps to Reproduce: Create the following class in eclipse: package sample; import java.io.Serializable; import java.util.AbstractList; public class SameErasure { static public abstract class BaseA { public BaseA link(AbstractList arg1, Object arg2) { return null; } }; static public class B<T extends AbstractList> extends BaseA { public B<T> link(T arg1, Object arg2){ return null; } } public static <T extends BaseA> T ask(String prompt, Class<T> clazz) { return null; } public static <T extends Serializable> T ask(String prompt, Class<T> clazz) { return null; } } The older version of eclipse will show no problems with the code, apart from a couple of warnings. The newer version will show the following errors: "Method ask(String, Class<T>) has the same erasure ask(String, Class<T>) as another method in type SameErasure" - this message appears twice, once for each ask method. "The method link(T, Object) of type SameErasure.B<T> has the same erasure as link(AbstractList, Object) of type SameErasure.BaseA but does not override it"
(In reply to comment #0) Note that javac7 (b77) refuses to compile this program and reports: SameErasure.java:21: name clash: <T#1>ask(String,Class<T#1>) and <T#2>ask(String ,Class<T#2>) have the same erasure public static <T extends Serializable> T ask(String prompt, Class<T> clazz) { ^ where T#1,T#2 are type-variables: T#1 extends Serializable declared in method <T#1>ask(String,Class<T#1>) T#2 extends BaseA declared in method <T#2>ask(String,Class<T#2>) SameErasure.java:12: name clash: link(T,Object) in B and link(AbstractList,Objec t) in BaseA have the same erasure, yet neither overrides the other public B<T> link(T arg1, Object arg2){ ^ where T is a type-variable: T extends AbstractList declared in class B 2 errors
This issue has no connection to either bug#302358 or bug# 293384, but has come about because of the conscious change introduced due to bug#289247 which was raised in response to sun bug http://bugs.sun.com/view_bug.do?bug_id=6182950 Eclipse behavior is deliberately chosen to match (the correct) behevior shown by javac 7. Closing current defect as INVALID.
It seems reasonable to mark the bug as invalid, but only if eclipse 3.6 won't be released until Java 7 is released. Otherwise, even though it's not strictly a bug in pure Java terms, it will mean different results between an external compile and an internal eclipse parse when eclipse 3.6 is generally available. Will eclipse 3.6 only be released after Java 7 is released?
(In reply to comment #3) > It seems reasonable to mark the bug as invalid, but only if eclipse 3.6 won't > be released until Java 7 is released. Otherwise, even though it's not strictly > a bug in pure Java terms, it will mean different results between an external > compile and an internal eclipse parse when eclipse 3.6 is generally available. > > Will eclipse 3.6 only be released after Java 7 is released? The release schedules of these two are unconnected. The stated aim of this fix (from bug#289247 comment#0 is:) "We have decided to make this change across all compliance levels (1.5, 1.6, 1.7) in the 3.6 release so users will not be surprised by the change if they compile their code using javac 7."
Verified for 3.6M7 using I20100425-2000
Target Milestone 3.6 M7 suggests this should be resolved, but I ran into it on 3.6 RC3. I just tried 3.6 RC3 and got an error on generic. You can duplicate the problem using a scrapbook page. Here is a snip of the failing code: abstract class ErasureIssue { public abstract <T extends ErasureIssue> T clone(); } Execute this and you will get: Name clash: The method clone() of type ErasureIssue has the same erasure as clone() of type Object but does not override it Same code compiles w/o error in 3.5 SR2.
(In reply to comment #6) > Target Milestone 3.6 M7 suggests this should be resolved, but I ran into it on > 3.6 RC3. I just tried 3.6 RC3 and got an error on generic. You can duplicate > the problem using a scrapbook page. Here is a snip of the failing code: > > abstract class ErasureIssue { > public abstract <T extends ErasureIssue> T clone(); > > } > > > Execute this and you will get: > > Name clash: The method clone() of type ErasureIssue has the same erasure as > clone() of type Object but does not override it > > Same code compiles w/o error in 3.5 SR2. This is expected to fail. As mentioned in comment 2, the eclipse compiler is aligned with what should be the right behavior (JDK7 builds are also failing to compile this code). It doesn't make sense to keep this bug in just because this is not backporting to JDK6 builds. If we do allow it today, this means that once the code is compiled on a JDK7 build, it will start reporting errors and then we will get new bug reports because we don't match javac behavior. Javac (JDK7b93) reports: X.java:2: name clash: <T>clone() in X and clone() in Object have the same erasure, yet neither overrides the other public abstract <T extends X> T clone(); ^ where T is a type-variable: T extends X declared in method <T>clone() 1 error Hope this clarify the resolution of this bug.
