Community
Participate
Working Groups
the following doesn't compile with javac and I don't think eclipse should compile it either. Eclipse 3.1M5a however doesn't complain: --------------------------------------------------- class B extends A<Object> { void m2() { m3((X2) m()); } void m3(X2 i) { } } public class A<T> { X<? extends T> m() { return null; } } class X2 extends X<String> { } class X<T> { } ------------------------------------------------------------
P.S. javac says: C:\eclipse\workspace\Scratch\src\A.java:5: inconvertible types found : X<capture of ? extends java.lang.Object> required: X2 m3((X2) m()); ^ 1 error
Reproduced. Indeed this feels like our bug.
I remember reading that one of the recent nightly builds of eclipse was JCK 1.5 compliant. With this bug reproduced (I presume with the latest build) it would seem silly to declare the eclipse compiler 1.5 compliant. Perhaps its worth letting whomever is in charge of the JCK test (Sun I presume) of this test case.
1.5 compliance means you pass some serie of tests, it doesn't mean you have zero bugs. Looks like the compliance test suites doesn't have the quality you expect.
Actually, I take my previous comment back. Based on JLS this should only be an unsafe warning. I believe javac has a bug; we do the right thing. Glancing through the javac bug database, they have quite a few defects in this area. To prove my point, instead of casting to X2, it will allow casting to X<String> only issuing a warning. The rule is for a cast to be wrong, that expression type and cast type erasures must be non compatible (only erasures at this point), and that there is some intermediate type which is provably distinct, here that would be X<? extends Object> and X<String> which aren't probably distinct. Thus the cast should be unsafe at worst. Added GenericTypeTest#test545
To prove my point, javac complains on: Object o3 = (X2) xo; but doesn't on the following: Object o1 = (X<String>) xo; Object o5 = (X3<String>) xo; Only unchecked warnings should be issued here. ==================== import java.util.*; public class X<T> { public static void main(String[] args) { X<? extends Object> xo = null; X<String> xs = null; X2 x2 = null; Object o1 = (X<String>) xo; Object o2 = (X<? extends Object>) xs; Object o3 = (X2) xo; Object o4 = (X<? extends Object>) x2; Object o5 = (X3<String>) xo; } } class X2 extends X<String> { } class X3<U> extends X<U> { }
I agree with what you have said, however instead of saying that this bug is invalid can I just point out that as it stands eclipse does not even warn about the cast as you suggest it should. Therefore this bug can be changed to say that a warning should be produced with the example code. P.S. can you point me to the relevant Sun Javac bug?
Interesting, I am not seeing the warning in IDE either, though I can see it produced by compiler in test suite. Investigating. As for javac bug, I am guessing, found no exact match in database. Feel free to report it to them.
Understood, I wasn't testing latest jdt/core with change in cast check for raising proper unchecked warning. Given this defect conducted to fix up the unchecked diagnosis, will rather consider it to be fixed.
Fixed unchecked warning diagnosis, updated title to reflect actual issues.
Verified in I20050330-0500
