Community
Participate
Working Groups
I modified an existing source file to make a method return a generic type in order to eliminate an Eclipse compiler warning in a different file. Once I did this, Eclipse showed no errors or warnings. But after checking in the file, the nightly build broke. Later checking the build with IntelliJ on the same PC machine (using the Sun JDK 1.5.0_07 compiler) the errors resulting from the change were clearly visible. The original source file contained the iterface method declaration: public interface IValue extends Serializable { public Comparable getComparableValue(); } This was changed to: public interface IValue extends Serializable { public <T extends Comparable<? super T>> T getComparableValue(); } In a different file, the following line was fine in Eclipse, but failed to compile in IntelliJ and in our nightly build that uses the Sun 1.5.0_07 JDK: IValue id1 = ...; IValue id2 = ...; return id1.getComparableValue().compareTo(id2.getComparableValue()); The error message at "id1.getComparableValue()" and another at "id2.getComparableValue()" was: "Inferred type 'java.lang.Object' for type parameter 'T' is not within its bound; should implement 'java.lang.Comparable<? super java.lang.Object>'" Clearly, the Eclipse compiler should consistently report (at least as much as, if not more than) the same errors and warnings as the Sun JDK compiler.
Reproduced with latest 1.5.0 and 1.6b98.
Try to compile the following code: import java.io.Serializable; interface IValue extends Serializable { public <T extends Comparable<? super T>> T getComparableValue(); } public class X { public static int foo() { IValue id1 = null; IValue id2 = null; return id1.getComparableValue().compareTo(id2.getComparableValue()); } } I don't get exactly the same error message, but Eclipse compiles it fine and not javac 1.5.0 or 1.6b98.
Alternatives: import java.io.Serializable; interface IValue extends Serializable { public <T extends Comparable<? super T>> T getComparableValue(); } public class X { public static void foo() { IValue val1 = null; Object o = val1.getComparableValue(); // 0 } public static void foo1() { IValue val1 = null; String s = val1.getComparableValue(); // 1 } public static int foo2() { IValue val1 = null; IValue val2 = null; return val1.getComparableValue().compareTo(val2.getComparableValue()); // 2 } public static int foo3() { Comparable<? super String> c = "aaa"; // 3 return 0; } }
Lowering severity. This is actually an area where the JLS has a flaw, and compilers are diverging. Javac is inferring invalid types, and we do infer slightly less invalid types, which allow to better process your code. Until the JLS is clarified, no action is planned as our inference produces better results than javac already.
similar issue to bug 121369. pls find there pointers to known JLS and javac bug reports. Added GenericTypeTest#test1031 *** This bug has been marked as a duplicate of 121369 ***
Wouldn't it make sense for the Eclipse project's compiler to mimic the behavior of Sun's compiler in the case where the JLS is unclear? Sun is the standard by which other compilers are compared (as far as most of the industry is concerned) so it is not acceptable for Eclipse to show code compiling without errors only to find that the reference builds that use the Sun compiler fail. This is both embarrasing to the developer (me) and causes project delays. I would not want my management to tell me that I can no longer use Eclipse because it is not dependable!
Javac's behavior is clearly wrong as type variables cannot surface from inference. NEVER. Our behavior is better, and you should expect Javac behavior to change soon once they get the spec adjusted. So relying on a bug in Javac is fairly risky for you. Our behavior is closer to reality, and you should expect this code to compile in the long term. So we are a better guess. I understand your claim for one behavior everywhere, but we do not have plans to be bug compatible with javac. My recommendation is to step away from writing such code until the JLS issue has been resolved. *** This bug has been marked as a duplicate of 121369 ***
