泛型

  

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）并将它们保存起来，以便通过反射创建实例。