What's wildcards in generics for?

Question

To be honest, wildcards make me sick all the time. I've read through related chapters in 'core java' but still don't understand the purpose of using it.Pls take a look at the below example:
package generics;
import java.util.ArrayList;
import java.util.List;
public class CovariantArrays {
  public static void main(String[] args) {
      List<? extends Fruit> list=new ArrayList<Fruit>();
      list.add(new Apple()); //wrong
class Fruit {}
class Orange extends Fruit {}
class Apple extends Fruit {}
class Jonathan extends Apple {}
  We can't even add a Apple instance to list,why,why? '? extends Fruit' represents any subtype of Fruit, doesn't it?
Edited by: fxbird on 2011-2-3 上午6:37
Edited by: fxbird on 2011-2-3 上午6:39

Answer 1

fxbird wrote:
Thank Walter and other dudes:
'core java 8th' says '? super xxx' means you can use supertype of a class,'The compiler doesn’t know the exact type of the setFirst method---void setFirst(? super Manager) but can call it with any object of type Manager, Employee, or Object, but not a subtype such as Executive.' ,on page 634. But my test prove it surely can be added subtype . Is the writer wrong?
List<? super Fruit> sList=new ArrayList<Fruit>();
sList.add(new Apple());and another question is , what's the difference between in '? extend or super type' and just 'List<Fruit>' way, I don't find the difference, if you use '? extends Fruit' as method parameter, the right type would be Fruit,Apple,Jonathan,Orange, but,so does List<Fruit>
Edited by: fxbird on 2011-2-5 下午7:19Let's create a very simplified List that is a concrete class:
public class MyList<E> {
  public void add(E e) {}
  public E get() { return null; }
}And our Fruit classes:
class Fruit {}
class Apple extends Fruit {}
class Banana extends Fruit {}Here we declare a List where E will be replaced by Fruit:
    MyList<Fruit> list1 = new MyList<Fruit>();This gives us, effectively:
  public void add(Fruit e) {}
  public Fruit get() { return null; }So this is just fine:
    Fruit f1 = new Fruit();
    list1.add(f1);
    f1 = list1.get();The add() works, because Fruit fits the (Fruit e) signature of add(), and get() works because the Fruit it promises to return fits our Fruit f1.
Now, if we have this:
    MyList<? extends Fruit> list2 = ...; // for example, new MyList<Apple>();This gives us, effectively:
  public void add(? e) {}
  public ? get() { return null; }where all the we, or the compiler, know about ? is that it will be either Fruit or some subtype of Fruit.
Now, we try this:
list2.add(new Fruit());
list2.add(new Banana());
list2.add(new Apple());But all of those are errors. We don't know if we have List<Fruit>, List<Apple>, or List<Banana>. All the add() method knows is that it expects some particular class that is Fruit or a Subtype. It doesn't know if it's add(Fruit) or add(Apple) or add(Banana). And it can't just assume that it's add(Fruit) and allow any old Fruit in, because if it does happen to be add(Apple) (such as when we do = new MyList<Apple>()), then we could end up putting Bananas into a List of Apples. Or, more precisely, we could end up passing a Banana where an Apple is expected.
On the other hand, this:
Fruit f2 = list2.get();is just fine. Even though get() doesn't know if it's public Fruit get() or public Apple get() or public Banana get(), it doesn't matter, because no matter what, whatever it returns IS-A Fruit. So anything expecting a Fruit back is satisfied.
One final note: While I've used a mini mock-up collection for this example, the rules have nothing to do with collections or add methods or get methods. They have to do with how type safety works in the Java language in any context. In this example, what matters is that we cannot pass any old Fruit as a parameter where some specific class that might be a subclass of Fruit is expected, but we can accept any Fruit as a method return value, even if that method is actually effectively declared to return Apple.
public void foo(Apple a) {}
public Apple bar() {return null;}
Fruit f = ...;
foo(f); // NOT ok
f = bar(); // ok