1. 程式人生 > >Java 陣列轉型和範型

Java 陣列轉型和範型

今天寫程式碼遇到一個奇怪的問題,程式碼結構如下:

[java] view plain copy  print?
  1. ArrayList<String> list = new ArrayList<String>();  
  2. String strings[] = (String[]) list.toArray();  
這樣寫程式碼個人覺得應該沒什麼問題,編譯也沒有問題。可是具體執行的時候報異常,如下:

Exception in thread "main" Java.lang.ClassCastException: [Ljava.lang.Object;

但是如果這樣寫就沒有問題:

[java] view plain copy  print?
  1. ArrayList<String> list = new ArrayList<String>();  
  2. int len = list.size();  
  3. String strings[] = new String[len];  
  4. for(int i = 0, j = list.size(); i < j; i++){   
  5.       strings[i]=list.get(i);  
  6. }  

這個問題怎麼解釋呢?

Java中允許向上和向下轉型,但是這個轉型是否成功是根據Java虛擬機器中這個物件的型別來實現的。Java虛擬機器中儲存了每個物件的型別,而陣列也是一個物件。

陣列的型別是[Ljava.lang.Object,把[Ljava.lang.Object轉換成[Ljava.lang.String是顯然不可能的事情,因為這是一個向下轉型,而虛擬機器只儲存了這是一個Object的陣列,不能保證陣列中的元素是String的,所以這個轉型不能成功。數組裡面的元素只是元素的引用,不是儲存的具體元素,所以陣列中元素的型別還是儲存在Java虛擬機器中的。

根據上面的解釋,我們可以把這個問題歸納到下面這個模型。

    Object objs[]=new Object[10];

    String strs[]=(String[])objs;

這樣子和剛才上面編譯錯誤是一樣的,如果我們把修改一下這個程式碼,如下:

    String strs[]=new String[10];

    Object objs[]=strs;

這樣子就可以編譯通過了,所以這個問題我們可以歸結為一個Java轉型規則的一個問題。

Java陣列對範型的支援問題:

JDK5中,已經有了對泛型的支援,這樣可以保證在集合和Map中的資料型別的安全,可是List的toArray方法返回的竟然是Object []讓我很迷惑。個人感覺應該可以根據範型,直接返回相應的T []。仔細看了一下JDK的原始碼發現List轉化為array有兩個方法:

    public Object[] toArray();

這個方法把List中的全部元素返回一個相同大小的陣列,陣列中的所有元素都為Object型別。

    public <T> T[] toArray(T[] a);

這個方法把List中的全部元素返回一個相同大小的陣列,陣列中的所有元素都為T型別。

List如此設計是因為Java編譯器不允許我們new範型陣列,也就是說你不能這麼定義一個數組:

    T arr=new T[size];

但是你卻可以用T[]來表示陣列,而且可以把陣列強制轉化為T[]的。比如List中的public <T> T[] toArray(T[] a)是這麼實現的:

[java] view plain copy  print?
  1. public <T> T[] toArray(T[] a) {  
  2.     if (a.length < size)  
  3.         a = (T[]) java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), size);  
  4.     System.arraycopy(elementData, 0, a, 0, size);  
  5.     if (a.length > size)  
  6.         a[size] = null;  
  7.     return a;  
  8. }  

從上面程式碼中可以看到,你必須通過反射來建立這個陣列,因為你不知道這個陣列的型別。a.getClass().getComponentType()方法是取得一個數組元素的型別。

Java為什麼不支援建立範型陣列?

我想這個問題的答案是:這樣做會破壞型別安全,其核心的問題在於Java範型和C#範型存在根本區別:

Java的範型停留在編譯這一層,到了執行時,這些範型的資訊其實是被抹掉的;而C#的範型做到了MSIL(Microsoft Intermediate Language,微軟中間語言)這一層。

Java的做法不必修改JVM,減少了潛在的大幅改動和隨之而來的風險,也許同時也反映出Java Bytecode規範在設計之初的先天不足;

C#則大刀闊斧,連CLR(Common Language Runtime,公共語言執行時)一起改以支援更徹底的範型,換句話說,在範型這一點上,感覺C#更像C++。

在Java中,Object[]陣列可以是任何陣列的父類,或者說,任何一個數組都可以向上轉型成它在定義時指定元素型別的父類的陣列,這個時候如果我們往裡面放不同於原始資料型別,但是滿足後來使用的父類型別的話,編譯不會有問題,但是在執行時會檢查加入陣列的物件的型別,於是會拋ArrayStoreException:

String[] strArray = new String[20];

Object[] objArray = strArray;

objArray[0] = new Integer(1); // throws ArrayStoreException at runtime

因為Java的範型會在編譯後將型別資訊抹掉,如果Java允許我們使用類似:

     Map<Integer, String>[] mapArray = new Map<Integer, String>[20];

這樣的語句的話,我們在隨後的程式碼中可以把它轉型為Object[],然後往裡面放Map<Double, String>例項。

這樣做不但編譯器不能發現型別錯誤,就連執行時的陣列儲存檢查對它也無能為力,它能看到的是我們往裡面放Map的物件,我們定義的<Integer, String>在這個時候已經被抹掉了,於是而對它而言,只要是Map,都是合法的。想想看,我們本來定義的是裝Map<Integer, String>的陣列,結果我們卻可以往裡面放任何Map(如:Map<Double, String>),接下來如果有程式碼試圖按原有的定義去取值,後果是什麼不言自明。

所以,Java編譯器不允許我們new範型陣列


toArray()兩種實現方式

[java] view plain copy  print?
  1. public Object[] toArray() {  
  2.      Object[] a = c.toArray();  
  3.      for (int i=0; i<a.length; i++)  
  4.           a[i] = new UnmodifiableEntry<>((Map.Entry<K,V>)a[i]);  
  5.      return a;  
  6. }  
  7. public <T> T[] toArray(T[] a) {  
  8.      // We don't pass a to c.toArray, to avoid window of
  9.      // vulnerability wherein an unscrupulous multithreaded client
  10.      // could get his hands on raw (unwrapped) Entries from c.
  11.      Object[] arr = c.toArray(a.length==0 ? a : Arrays.copyOf(a, 0));  
  12.      for (int i=0; i<arr.length; i++)  
  13.           arr[i] = new UnmodifiableEntry<>((Map.Entry<K,V>)arr[i]);  
  14.      if (arr.length > a.length)  
  15.           return (T[])arr;  
  16.      System.arraycopy(arr, 0, a, 0, arr.length);  
  17.      if (a.length > arr.length)  
  18.           a[arr.length] = null;  
  19.      return a;  
  20. }  

toArray() 原始碼,請參見我在google code 上傳的 sdk 原始碼: src-jdk1.7.0_02

from: http://blog.csdn.net/ithomer/article/details/7532935