java中upcast_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,oranything descended from Fruit, such as Orange, to be placed into the array? So at compiletime, 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 dofind 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 isnow 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 Listwill hold any type of

Fruit, however. The wildcard refers to a definite type, so it means "some specific type which

the flistreference doesn’t specify." So the Listthat’s assigned has to be holding some

specified type such as Fruitor Apple, but in order to upcast to flist, that type is a "don’t

actually care."

package localevidence;

public class Holder {

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 = new Holder(new Applee());

Applee d = Applee.get();

// Applee.set(d);

// Holder 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

}

} ///:~