Summary: | Generic Method override compatibility | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Carlos Aydos <carlos_aydos> |
Component: | Core | Assignee: | Kent Johnson <kent_johnson> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P3 | CC: | carlos_aydos, markus.kell.r |
Version: | 3.1 | ||
Target Milestone: | 3.1 M7 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Carlos Aydos
2005-03-30 03:39:21 EST
I am sorry, I mistyped something on previous comment: Where I said: >And this output with javac: >Base: 1 >Sub: 1 >Exception in thread "main" java.lang.ClassCastException: java.lang.String I actually meant: Base: 1 Sub: 1 Base: as Carlos, are you sure you wanted to set severity to "critical"? IMO, it's "normal" or "minor". Click on the "Severity:" link above to see how severities are used, e.g.: Critical crashes, loss of data, severe memory leak Markus, You are right. The reason I jumped and placed it as critical is that we started using 3.1 as our main development environment. And due to lack of experience with Erasure we coded a lot based on the assumption that MyIface/MyClass code example gets compiled without any problems. To be more specific, we defined an interface for functors: public interface UnaryFunction<S> { public <T> S execute(T p); } And we have by now more than 100 functors in our code based on this interface which are implemented in a similar way as below: public class MyClass<SS> { // more stuff here public class Func implements UnaryFunction<SS> { public <TT extends Integer> SS execute(TT s) { SS out = null; // does something return out; } } } That means that when this bug is fixed, our entire project will not compile anymore as I will to rewrite my interface to something like: public interface UnaryFunction<S,T> { public S execute(T p); } and change all functors accordingly. Taking into consideration that there might be more people out there that will be silly enough (like me! L) to fall in the same trap I think this bug was quite critical. I know the Bugzilla criteria describes critical as “crashes, loss of data,etc”. For someone like me, which is now informed about the issue, I consider this Bug as Minor or Normal, but for someone less informed, this could be a Blocker. So Critical was the compromise I found here. BTW, do you have any tips for a easier work around to my problem described above? I would also qualify this defect as critical based on what you described. Having the compiler misbehaves, and let people write bogus code is nasty. We want to resolve this asap. I suspect problem comes from MethodVerifier15 boolean doTypeVariablesClash(MethodBinding one, MethodBinding substituteTwo) { TypeBinding[] currentVars = one.typeVariables; TypeBinding[] inheritedVars = substituteTwo.original().typeVariables; return currentVars.length != inheritedVars.length && currentVars.length > 0; } The variable clash detection doesn't perform bound checks. Already have a fix - just needs to be tested. Added MethodVerify test051 The error is properly reported now. Verified in I20050510-0010 |