package localevidence; //: generics/UnboundedWildcards1.java //: generics/CovariantArrays.java class Fruit {} class Appleee extends Fruit {} class Jonathan extends Appleee {} class Orange extends Fruit {} public class Testwildcats { public static void main(String[] args) { Fruit[] fruit = new Appleee[10]; fruit[0] = new Appleee(); // OK fruit[1] = new Jonathan(); // OK // Runtime type is Appleee[], not Fruit[] or Orange[]: try { // Compiler allows you to add Fruit: fruit[0] = new Fruit(); // ArrayStoreException } catch(Exception e) { System.out.println(e); } try { // Compiler allows you to add Oranges: fruit[0] = new Orange(); // ArrayStoreException } catch(Exception e) { System.out.println(e); } } } /* Output: java.lang.ArrayStoreException: Fruit java.lang.ArrayStoreException: Orange *///:~
Fruit[] fruit = new Appleee[10];// 這是實例化fruit數組爲appleee類型
可是編譯沒有錯誤,可是在runtime的時候爲啥報錯呢?java
This makes sense to the compiler, because it has a Fruit[] reference—why shouldn’t it allow a Fruit 數組
object, or anything descended from Fruit, such as Orange, to be placed into the array? So at compile time, this is allowed.瀏覽器
由於這對瀏覽器來講這是合理的,由於app
Fruit[] fruit = new Appleee[10];
// Compiler allows you to add Fruit: fruit[0] = new Fruit(); // ArrayStoreException
它有一個Fruit[]類型的申明,爲啥不能夠將Fruit 變量賦值給它呢,或者繼承Fruit的子類呢?能夠的編譯器認爲沒有問題。ide
The runtime array mechanism, however, knows that it’s dealing with an Apple [] and throws an exception when a foreign type is placed into the array.ui
可是runtime 運行機制卻認爲她是在處理Appleee[]類型的,因此若是你放入其它類型的就會報錯。
"Upcast" is actually rather a misnomer here. What you’re really doing is assigning one array
to another.this
"向上轉型"事實上並非不當,你實際在作的是將一種類型的數組賦值給另一個數組。
spa
The array behavior is that it holds other objects, but because we are able to
upcast, it’s clear that the array objects can preserve the rules about the type of objects they
contain. It’s as if the arrays are conscious of what they are holding, so between the compile time checks and the runtime checks, you can’t abuse them.
This arrangement for arrays is not so terrible, because you do find out at run time that you’ve
inserted an improper type. But one of the primary goals of generics is to move such error
detection to compile time. So what happens when we try to use generic containers instead of
arrays?
The real issue is that we are talking about the type of the container, rather than the type that
the container is holding.
The type of flist is now List<? extends Fruit>, which you can read as "a list of any type
that’s inherited from Fruit." This doesn’t actually mean that the List will hold any type of
Fruit, however. The wildcard refers to a definite type, so it means "some specific type which
the flist reference doesn’t specify." So the List that’s assigned has to be holding some
specified type such as Fruit or Apple, but in order to upcast to flist, that type is a "don’t
actually care."
code
package localevidence; public class Holder<T> { private T value; public Holder() {} public Holder(T val) { value = val; } public void set(T val) { value = val; } public T get() { return value; } public boolean equals(Object obj) { return value.equals(obj); } public static void main(String[] args) { Holder<Applee> Applee = new Holder<Applee>(new Applee()); Applee d = Applee.get(); // Applee.set(d); // Holder<Fruit> Fruit = Applee; // Cannot upcast Holder<? extends Fruit> fruit = Applee; // OK Fruit p = fruit.get(); d = (Applee)fruit.get(); // Returns ‘Object’ try { Orange c = (Orange)fruit.get(); // No warning } catch(Exception e) { System.out.println(e); } // fruit.set(new Applee()); // Cannot call set() // fruit.set(new Fruit()); // Cannot call set() System.out.println(fruit.equals(d)); // OK } } /* Output: (Sample) java.lang.ClassCastException: Applee cannot be cast to Orange true *///:
//: generics/SuperTypeWildcards.java import java.util.*; public class SuperTypeWildcards { static void writeTo(List<? super Apple> apples) { apples.add(new Apple()); apples.add(new Jonathan()); // apples.add(new Fruit()); // Error } } ///:~