Summary: | Name Clash and Same Erasure bugs re-emerge | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tony Weddle <tony> |
Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> |
Status: | VERIFIED INVALID | QA Contact: | |
Severity: | major | ||
Priority: | P3 | CC: | michael_giroux, Olivier_Thomann |
Version: | 3.6 | ||
Target Milestone: | 3.6 M7 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Tony Weddle
2010-03-23 18:17:20 EDT
(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. |