java 通配符的使用-upcast

最新推荐文章于 2021-02-25 06:37:40 发布

weixin_33711647

最新推荐文章于 2021-02-25 06:37:40 发布

阅读量108

点赞数

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/u/2308739/blog/396594

本文深入探讨了Java中泛型的概念及其在数组类型转换中的应用，通过实例展示了编译器与运行时机制之间的差异，以及如何利用泛型避免常见的ArrayStoreException错误。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2019独角兽企业重金招聘Python工程师标准>>>

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
}
} ///:~