Community
Participate
Working Groups
Build Identifier: 20110916-0149 The attached code produces a compiler error in Eclipse, but not in javac (1.6.0_26): Type mismatch: cannot convert from Comparator<Unchecked.Range<Comparable>> to Comparator<Unchecked.Range> Reproducible: Always Steps to Reproduce: 1. compile attached file
Created attachment 207741 [details] Class with compiler error in Eclipse, which should compile
BTW, quick fix offers to change type of START_COMPARATOR to Comparator<Range<Comparable>>, which results in a bound mismatch error (rejected by both javac and Eclipse).
Compiles with both 1.6 and 1.7, not with Eclipse in any compliance.
Eclipse behavior dates back to at least 3.6.2, probably longer.
Sorry, I haven't had time at all to look at this, too busy with Java 8 work. Reverting to inbox to allow someone else to investigate
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
The same can still be observed, but corner cases in type checking in the presence of raw types are not a priority.
Eclipse Version: 2021-09 (4.21.0) Build id: 20210910-1417 still shows the compiler error (tested in a Java 11 project): line 9 Java Problem Type mismatch: cannot convert from Comparator<Unchecked.Range<Comparable>> to Comparator<Unchecked.Range> /test2/src/main/java Unchecked.java Javac compiles with warning: > javac -version javac 11.0.12 > javac Unchecked.java Note: Unchecked.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. > javac -Xlint:unchecked Unchecked.java Unchecked.java:9: warning: [unchecked] unchecked method invocation: method rangeStartComparator in class Unchecked is applied to given types static final Comparator<Range> START_COMPARATOR = Unchecked.<Comparable>rangeStartComparator(); ^ required: no arguments found: no arguments Unchecked.java:9: warning: [unchecked] unchecked conversion static final Comparator<Range> START_COMPARATOR = Unchecked.<Comparable>rangeStartComparator(); ^ required: Comparator<Range> found: Comparator 2 warnings
I personally have given up on trying to align ecj with javac in situations where raw types are involved. Javac has some known bugs in this area with no sign of this ever getting fixed. Just to figure out whether javac behaves correctly in this case would require significant efforts. I realize that avoiding the raw types Range and Comparable in your example isn't easy, but then: maybe what you are trying to express isn't denotable in Java. Here's a hint at smth being fishy: omit the type argument from the invocation of rangeStartComparator() and even javac will inform you: Unchecked.java:12: error: incompatible types: no instance(s) of type variable(s) T exist so that Comparator<Range<T>> conforms to Comparator<Range> static final Comparator<Range> START_COMPARATOR = Unchecked.rangeStartComparator(); ^ where T is a type-variable: T extends Comparable<? super T> declared in method <T>rangeStartComparator() 1 error i.e. type inference is unable to find a solution for what you are trying to do. This is not a proof but could indicate that the type you intend to use doesn't exist. OTOH, if you want to cheat, then do it consistently by omitting *all* type arguments: static final Comparator START_COMPARATOR = Unchecked.rangeStartComparator();
Thanks. Yeah, we did something similar back then: A package private constant as raw as needed to pass both compilers, and a method @SuppressWarnings({ "unchecked", "rawtypes" }) public static <T extends Comparable<? super T>> Comparator<Range<T>> getStartComparator() to access the constant without warnings. Similar to java.util.Collections.emptyList(). The attachment was just the minimal code to show the assumed bug.
