Tại sao Function.identity() phá vỡ sự phân loại kiểu nhưng t -> t thì không?

Question

Câu trả lời được tìm thấy tại Java 8 lambdas, Function.identity() or t->t dường như ngụ ý rằng Function.identity() hầu như luôn luôn tương đương với t -> t. Tuy nhiên, trong testcase được thấy bên dưới, thay thế t -> t bởi Function.identity() dẫn đến lỗi trình biên dịch. Tại sao vậy?

public class Testcase { 

    public static <T, A, R, K, V> Collector<T, A, R> comparatorOrdering(
      Function<? super T, ? extends K> keyMapper, 
      Function<? super T, ? extends V> valueMapper, 
      Comparator<? super K> keyComparator, 
      Comparator<? super V> valueComparator) { 
     return null; 
    } 

    public static void main(String[] args) {  
     Map<Integer, String> case1 = Stream.of(1, 2, 3). 
       collect(comparatorOrdering(t -> t, t -> String.valueOf(t), 
         Comparator.naturalOrder(), Comparator.naturalOrder())); 
     Map<Integer, String> case2 = Stream.of(1, 2, 3). 
       collect(comparatorOrdering(Function.identity(), t -> String.valueOf(t), 
         Comparator.naturalOrder(), Comparator.naturalOrder())); 
    } 
} 

Trường hợp 1 biên dịch tốt nhưng trường hợp 2 không thành công với:

method comparatorOrdering in class Testcase cannot be applied to given types; 
       collect(comparatorOrdering(Function.identity(), t -> String.valueOf(t), 
    required: Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V> 
    found: Function<Object,Object>,(t)->Strin[...]Of(t),Comparator<T#2>,Comparator<T#3> 
    reason: inferred type does not conform to upper bound(s) 
    inferred: Object 
    upper bound(s): Comparable<? super T#4>,T#4,Object 
    where T#1,A,R,K,V,T#2,T#3,T#4 are type-variables: 
    T#1 extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>) 
    A extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>) 
    R extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>) 
    K extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>) 
    V extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>) 
    T#2 extends Comparable<? super T#2> 
    T#3 extends Comparable<? super T#3> 
    T#4 extends Comparable<? super T#4> declared in method <T#4>naturalOrder() 

Môi trường của tôi là Windows 10, 64-bit, Oracle JDK xây dựng 1.8.0_92-b14.

CẬP NHẬT: Xem bản dịch này dưới dạng ecj, tôi có câu hỏi tiếp theo: Đây có phải là lỗi trong số javac không? JLS phải nói gì về trường hợp này?

Answer 1

Ecj có thể thực hiện đúng đối số kiểu (?) (Số nguyên) để khớp với các ràng buộc. Javac vì một lý do nào đó đến một kết quả khác.

Đó không phải là lần đầu tiên javac/ecj hoạt động khác nhau theo suy luận của các thông số loại.

Trong trường hợp đó, bạn có thể cho gợi ý javac bằng Hàm. <Integer> identity() để làm cho nó compileable với javac.

Đối với chênh lệch giữa Function.identity() và t-> t:

• Function.identity() là hàm < T, T >
• t-> t trong trường hợp đó là chức năng < ? siêu Integer,? mở rộng Integer >

Vì vậy, t là linh hoạt hơn trong các phương thức có thể khớp với.