java 通配符的使用-upcast
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的时候为啥报错呢？
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.
因为这对浏览器来说这是合理的，因为
Fruit[] fruit = new Appleee[10];
// Compiler allows you to add Fruit: fruit[0] = new Fruit(); // ArrayStoreException
它有一个Fruit[]类型的申明，为啥不可以将Fruit 变量赋值给它呢，或者继承Fruit的子类呢？可以的编译器认为没有问题。
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.
但是runtime 运行机制却认为她是在处理Appleee[]类型的，所以如果你放入其它类型的就会报错。
"Upcast" is actually rather a misnomer here. What you’re really doing is assigning one array
to another.
"向上转型"事实上并不是不当，你实际在做的是将一种类型的数组赋值给另外一个数组。
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."
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
}
} ///:~