import java.util.HashMap;
import java.util.Map;
import java.util.Set;
//本方法无实际用途,只是用于说明泛型<T>在方法中作参数的用法
public class EntryTest {
//想要使用泛型<T>时要在方法前面声明如下,那么在方法的参数中才能使用T类型的参数
private static <T> void swap(T arr[],int x,int y){
}
//主方法说明Map.Entry在程序中遍历map的优势
public static void main(String[] args) {
HashMap<String, Integer> map=new HashMap<String, Integer>();
map.put("jack", 10);
map.put("rose",11);
map.put("pete", 9);
Set<Map.Entry<String, Integer>> set=map.entrySet();//set集合中存放的时entry
for(Map.Entry<String, Integer> entrySet:set){
System.out.println("key:"+entrySet.getKey()+" value:" + entrySet.getValue());
}
}
}
泛型的擦除:
因为泛型基本上都是在 Java 编译器中而不是运行库中实现的,所以在生成字节码的时候,差不多所有关于泛型类型的类型信息都被“擦掉”了。换句话说,编译器生成的代码与您手工编写的不用泛型、检查程序的类型安全后进行强制类型转换所得到的代码基本相同。与 C++ 不同,List<Integer>
和List<String>
是同一个类(虽然是不同的类型但都是 List<?>
的子类型,与以前的版本相比,在 JDK 5.0 中这是一个更重要的区别)。
擦除意味着一个类不能同时实现 Comparable<String>
和 Comparable<Number>
,因为事实上两者都在同一个接口中,指定同一个compareTo()
方法。声明 DecimalString
类以便与 String
与Number
比较似乎是明智的,但对于 Java 编译器来说,这相当于对同一个方法进行了两次声明:
public class DecimalString implements Comparable<Number>, Comparable<String> { ... } // nope |
擦除的另一个后果是,对泛型类型参数是用强制类型转换或者 instanceof
毫无意义。下面的代码完全不会改善代码的类型安全性:
public <T> T naiveCast(T t, Object o) { return (T) o; } |
编译器仅仅发出一个类型未检查转换警告,因为它不知道这种转换是否安全。naiveCast()
方法实际上根本不作任何转换,T
直接被替换为Object
,与期望的相反,传入的对象被强制转换为 Object
。
擦除也是造成上述构造问题的原因,即不能创建泛型类型的对象,因为编译器不知道要调用什么构造函数。如果泛型类需要构造用泛型类型参数来指定类型的对象,那么构造函数应该接受类文字(Foo.class
)并将它们保存起来,以便通过反射创建实例。