Community
Participate
Working Groups
The following construct will only give forth a simple warning in Eclipse, but javac won't compile it: Iterator<Enum<?>> it = null; Iterator<Enum> error = (Iterator<Enum>)it; javac output: ********** inconvertible types found : java.util.Iterator<java.lang.Enum<?>> required: java.util.Iterator<java.lang.Enum> Iterator<Enum> error = (Iterator<Enum>)it; ^ 1 error *********
This issue appears to correspond to Java bug 4916620 which is resolved in mustang(b55). I believe this means that eclipse is performing correctly?
Error reproduced with jdk1.5.0_09 and jdk6_b104, while Eclipse I20061102-1715 shows a warning only.
Released GenericTypeTest#1084 (inactive).
another weird case. Is this the same issue? enum SomeEnum {}; ***** Enum<?> myvar = null; if (myvar instanceof SomeEnum) { } This compiles with no warnings in Eclipse, but javac barfs at it...
Also added GenericTypeTest#test1185-1186
Created attachment 79958 [details] Proposed patch
Also added GenericTypeTest#test1187-1190.
Released for 3.4M3. Fixed
Re: comment 4 I believe this is a bug in javac. Our behavior hasn't changed for it. The two types are not provably distinct even under tighter rules; suspect javac is not handling the capture correctly. Added GenericTypeTest#test1191
Verified for 3.4 M3 using build I20071029-0010.
*** Bug 224855 has been marked as a duplicate of this bug. ***
Is this correct behaviour? or, as someone suggested, is this a bug in Java? Running javac (from JDK6uN), I still get the inconvertible types error. Sun, do however suggest that they have fixed various bugs (http://bugs.sun.com/view_bug.do?bug_id=4916620), but not this case ,it seems. Elsewhere (http://bugs.sun.com/view_bug.do?bug_id=6256789) they suggest chain casting, which works in Eclipse (apart from some Save Action issues) and JDK: i.e. While: Iterator<Enum<?>> it = null; Iterator<Enum> error = (Iterator<Enum>)it; still throws an error, Iterator<Enum> error = (Iterator<Enum>)(Iterator)it; and Iterator<Enum> error = (Iterator<Enum>)(Object)it; both compile, with warnings (if -Xlint:unchecked is specified). This, on both Sun's and Eclipse's part is a bit mad. If we can chain cast to get this effect, then we should be able to do so without chain casting. What is clear to me is that when I cast, I am saying "I know what type this is". Generics are awkward enough, without the compiler starting to think it is smarter than the programmer. In this case, I cannot see how the compiler is saving me from a ClassCastException. (Perhaps someone else can...) Also of note: Eclipse Save Actions->Remove Unnecessary Casts does some interesting stuff: For the first workaround, it gives you Iterator<Enum> error = (Iterator)it; which works with warnings, and for the second, it gives: Iterator<Enum> error = (Iterator<Enum>)it; which is our original error, and therefore fails! Reopen (both Eclipse and JDK) ?
Please do not reopen this bug, if you have issues open a new bug. Most of your argument comes from the fact you disagree with the Java language spec which expects the current behavior, enforced by both Eclipse and javac (i.e. blame the spec). As to quickfix issues, pls open a separate bug.
Not planning to re-open, but I am curious. Does the Eclipse compiler implement: the JLS or compatibility with JDK's javac ? The reason I ask is that Sun's bug database is littered with things like "Yes, the cast implementation in javac is wrong." (see http://bugs.sun.com/view_bug.do?bug_id=6270087). If the aim of the Eclipse compiler is to be a solid, open-source Java compiler, then I see no reason whatsoever why it should not implement correctly behaving generics, rather than re-implement bugs (whether they are in javac or JLS). I'd agree that there is a need for Java code portability, and that people will want code compiled in Eclipse to compile with javac, but we should at least be able to have the option of a warning instead of an error for this class of bug. Philippe: Your own comments in http://bugs.sun.com/view_bug.do?bug_id=6557279 make this exact case. Surely Eclipse deserves better than Sun's sluggishness in addressing this. Would you and those working on the compiler consider giving us an option, where the issue is a bug that Sun has agreed it is a bug, and the bug is still open?
The cast semantics are really fuzzily spec'ed today. The spec is being clarified, and cast semantics are to be made stricter. According to the spec, only unchecked cast are diagnosed for situations where it can be proven wrong statically. Until the clarified version of the spec is out there (and we will adjust to it then), it is hard to guess which way it will end up. I have seen situations where an in-progress javac bug got resolved differently in the end (i.e. not a bug, just fix spec). The comment I posted in http://bugs.sun.com/view_bug.do?bug_id=6557279 is dating from before I tightened the cast semantics in Eclipse compiler to become stricter and detect early invalid cast situations (which by the spec were unchecked). I altered the behavior for raw types, but these are arguable I agree. Until the new spec clarifications materialize, I would rather keep the current behavior.
