Kiểu trả về chung giới hạn trên - giao diện so với lớp - mã hợp lệ đáng ngạc nhiên

Đây là một ví dụ trong thế giới thực từ API thư viện của bên thứ 3, nhưng được đơn giản hóa.

Được biên dịch với Oracle JDK 8u72

Hãy xem xét hai phương pháp sau:

<X extends CharSequence> X getCharSequence() {
    return (X) "hello";
}

<X extends String> X getString() {
    return (X) "hello";
}

Cả hai đều báo cáo cảnh báo "diễn viên không được kiểm tra" - tôi hiểu tại sao. Điều gây trở ngại cho tôi là tại sao tôi có thể gọi

Integer x = getCharSequence();

và nó biên dịch? Trình biên dịch nên biết rằng Integerkhông thực hiện CharSequence. Cuộc gọi đến

Integer y = getString();

đưa ra một lỗi (như mong đợi)

incompatible types: inference variable X has incompatible upper bounds java.lang.Integer,java.lang.String

Ai đó có thể giải thích tại sao hành vi này sẽ được coi là hợp lệ? Làm thế nào nó sẽ hữu ích?

Máy khách không biết rằng cuộc gọi này không an toàn - mã của máy khách sẽ biên dịch mà không có cảnh báo. Tại sao trình biên dịch không cảnh báo về điều đó / gây ra lỗi?

Ngoài ra, nó khác với ví dụ này như thế nào:

<X extends CharSequence> void doCharSequence(List<X> l) {
}

List<CharSequence> chsL = new ArrayList<>();
doCharSequence(chsL); // compiles

List<Integer> intL = new ArrayList<>();
doCharSequence(intL); // error

Cố gắng vượt qua List<Integer>cho một lỗi, như mong đợi:

method doCharSequence in class generic.GenericTest cannot be applied to given types;
  required: java.util.List<X>
  found: java.util.List<java.lang.Integer>
  reason: inference variable X has incompatible bounds
    equality constraints: java.lang.Integer
    upper bounds: java.lang.CharSequence

Nếu đó là một lỗi, tại sao Integer x = getCharSequence();không?

CharSequencelà một interface. Do đó, ngay cả khi SomeClasskhông triển khai CharSequence, việc tạo một lớp là hoàn toàn có thể

class SubClass extends SomeClass implements CharSequence

Do đó bạn có thể viết

SomeClass c = getCharSequence();

bởi vì kiểu suy ra Xlà kiểu giao nhau SomeClass & CharSequence.

Đây là một chút kỳ lạ trong trường hợp Integervì Integerlà cuối cùng, nhưng finalkhông đóng vai trò nào trong các quy tắc này. Ví dụ bạn có thể viết

<T extends Integer & CharSequence>

Mặt khác, Stringkhông phải là một interface, vì vậy sẽ không thể mở rộng SomeClassđể có được một kiểu con String, bởi vì java không hỗ trợ đa kế thừa cho các lớp.

Với Liství dụ này, bạn cần nhớ rằng generic không phải là covariant hay contravariant. Điều này có nghĩa là nếu Xlà một kiểu con của Y, List<X>thì không phải là một kiểu con cũng không phải là siêu kiểu List<Y>. Vì Integerkhông thực hiện CharSequence, bạn không thể sử dụng List<Integer>trong doCharSequencephương thức của mình .

Tuy nhiên, bạn có thể lấy cái này để biên dịch

<T extends Integer & CharSequence> void foo(List<T> list) {
    doCharSequence(list);
}  

Nếu bạn có một phương pháp mà trả về một List<T>như thế này:

static <T extends CharSequence> List<T> foo() 

bạn có thể làm

List<? extends Integer> list = foo();

Một lần nữa, điều này là do loại suy ra Integer & CharSequencevà đây là một kiểu con của Integer.

Các loại giao lộ xảy ra ngầm khi bạn chỉ định nhiều giới hạn (ví dụ <T extends SomeClass & CharSequence>).

Để biết thêm thông tin, đây là một phần của JLS nơi nó giải thích cách giới hạn loại hoạt động. Bạn có thể bao gồm nhiều giao diện, ví dụ:

<T extends String & CharSequence & List & Comparator>

nhưng chỉ ràng buộc đầu tiên có thể là một giao diện không.

Loại được trình biên dịch của bạn suy ra trước khi gán cho Xlà Integer & CharSequence. Loại này cảm thấy kỳ lạ, vì Integerlà cuối cùng, nhưng nó là một loại hoàn toàn hợp lệ trong Java. Sau đó Integer, nó được chuyển đến , điều này là hoàn toàn OK.

Có chính xác một giá trị có thể cho Integer & CharSequenceloại : null. Với việc thực hiện như sau:

<X extends CharSequence> X getCharSequence() {
    return null;
}

Nhiệm vụ sau sẽ hoạt động:

Integer x = getCharSequence();

Vì giá trị có thể này, không có lý do nào khiến việc chuyển nhượng bị sai, ngay cả khi nó rõ ràng là vô dụng. Một cảnh báo sẽ hữu ích.

Vấn đề thực sự là API chứ không phải trang web cuộc gọi

Trên thực tế, gần đây tôi đã viết blog về mẫu chống thiết kế API này . Bạn nên (hầu như) không bao giờ thiết kế một phương thức chung để trả về các loại tùy ý vì bạn có thể (hầu như) không bao giờ đảm bảo rằng loại suy ra sẽ được phân phối. Một ngoại lệ là các phương thức như Collections.emptyList(), trong trường hợp sự trống rỗng của danh sách (và xóa kiểu chung) là lý do tại sao mọi suy luận cho <T>sẽ hoạt động:

public static final <T> List<T> emptyList() {
    return (List<T>) EMPTY_LIST;
}