Can't add value to the Java collection with wildcard generic type

后端 未结 4 1653
伪装坚强ぢ
伪装坚强ぢ 2020-11-22 12:06

Why this code does not compile (Parent is an interface)?

List list = ...
Parent p = factory.get();   // returns concrete         


        
相关标签:
4条回答
  • 2020-11-22 12:49

    Here's my understanding.

    Suppose we have a generic type with 2 methods

    type L<T>
        T get();
        void set(T);
    

    Suppose we have a super type P, and it has sub types C1, C2 ... Cn. (for convenience we say P is a subtype of itself, and is actually one of the Ci)

    Now we also got n concrete types L<C1>, L<C2> ... L<Cn>, as if we have manually written n types:

    type L_Ci_
        Ci get();
        void set(Ci);
    

    We didn't have to manually write them, that's the point. There are no relations among these types

    L<Ci> oi = ...;
    L<Cj> oj = oi; // doesn't compile. L<Ci> and L<Cj> are not compatible types. 
    

    For C++ template, that's the end of story. It's basically macro expansion - based on one "template" class, it generates many concrete classes, with no type relations among them.

    For Java, there's more. We also got a type L<? extends P>, it is a super type of any L<Ci>

    L<Ci> oi = ...;
    L<? extends P> o = oi; // ok, assign subtype to supertype
    

    What kind of method should exist in L<? extends P>? As a super type, any of its methods must be hornored by its subtypes. This method would work:

    type L<? extends P>
        P get();
    

    because in any of its subtype L<Ci>, there's a method Ci get(), which is compatible with P get() - the overriding method has the same signature and covariant return type.

    This can't work for set() though - we cannot find a type X, so that void set(X) can be overridden by void set(Ci) for any Ci. Therefore set() method doesn't exist in L<? extends P>.

    Also there's a L<? super P> which goes the other way. It has set(P), but no get(). If Si is a super type of P, L<? super P> is a super type of L<Si>.

    type L<? super P>
        void set(P);
    
    type L<Si>
        Si get();
        void set(Si);
    

    set(Si) "overrides" set(P) not in the usual sense, but compiler can see that any valid invocation on set(P) is a valid invocation on set(Si)

    0 讨论(0)
  • 2020-11-22 12:51

    It's doing that for the sake of safety. Imagine if it worked:

    List<Child> childList = new ArrayList<Child>();
    childList.add(new Child());
    
    List<? extends Parent> parentList = childList;
    parentList.set(0, new Parent());
    
    Child child = childList.get(0); // No! It's not a child! Type safety is broken...
    

    The meaning of List<? extends Parent> is "The is a list of some type which extends Parent. We don't know which type - it could be a List<Parent>, a List<Child>, or a List<GrandChild>." That makes it safe to fetch any items out of the List<T> API and convert from T to Parent, but it's not safe to call in to the List<T> API converting from Parent to T... because that conversion may be invalid.

    0 讨论(0)
  • 2020-11-22 12:58
    List<? super Parent>
    

    PECS - "Producer - Extends, Consumer - Super". Your List is a consumer of Parent objects.

    0 讨论(0)
  • 2020-11-22 13:10

    This is because of "capture conversion" that happens here.

    Every time the compiler will see a wildcard type - it will replace that by a "capture" (seen in compiler errors as CAP#1), thus:

    List<? extends Parent> list
    

    will become List<CAP#1> where CAP#1 <: Parent, where the notation <: means subtype of Parent (also Parent <: Parent).

    java-12 compiler, when you do something like below, shows this in action:

    List<? extends Parent> list = new ArrayList<>();
    list.add(new Parent());
    

    Among the error message you will see:

    .....
    CAP#1 extends Parent from capture of ? extends Parent
    .....
    

    When you retrieve something from list, you can only assign that to a Parent. If, theoretically, java language would allow to declare this CAP#1, you could assign list.get(0) to that, but that is not allowed. Because CAP#1 is a subtype of Parent, assigning a virtual CAP#1, that list produces, to a Parent (the super type) is more that OK. It's like doing:

    String s = "s";
    CharSequence s = s; // assign to the super type
    

    Now, why you can't do list.set(0, p)? Your list, remember, is of type CAP#1 and you are trying to add a Parent to a List<CAP#1>; that is you are trying to add super type to a List of subtypes, that can't work.

    0 讨论(0)
提交回复
热议问题