Java 數組轉型和範型

今天寫代碼遇到一個奇怪的問題，代碼結構如下：

ArrayList<String> list = new ArrayList<String>();<br />String strings[] = (String[]) list.toArray();這樣寫代碼個人覺得應該沒什麼問題，編譯也沒有問題。可是具體啟動並執行時候報異常，如下：

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

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

ArrayList<String> list = new ArrayList<String>();<br /> int len = list.size();<br /> String strings[] = new String[len];<br /> for(int i = 0, j = list.size(); i < j; i++){<br /> strings[i]=list.get(i);<br /> }

這個問題怎麼解釋呢？

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)是這麼實現的：

public <T> T[] toArray(T[] a) {<br />if (a.length < size)<br />a = (T[]) java.lang.reflect.Array.newInstance(a.getClass().getComponentType(), size);<br />System.arraycopy(elementData, 0, a, 0, size);<br />if (a.length > size)<br />a[size] = null;<br />return a;<br />}

從上面代碼中可以看到，你必須通過反射來建立這個數組，因為你不知道這個數組的類型。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()兩種實現方式

public Object[] toArray() {<br /> Object[] a = c.toArray();<br /> for (int i=0; i<a.length; i++)<br /> a[i] = new UnmodifiableEntry<>((Map.Entry<K,V>)a[i]);<br /> return a;<br />}</p><p>public <T> T[] toArray(T[] a) {<br /> // We don't pass a to c.toArray, to avoid window of<br /> // vulnerability wherein an unscrupulous multithreaded client<br /> // could get his hands on raw (unwrapped) Entries from c.<br /> Object[] arr = c.toArray(a.length==0 ? a : Arrays.copyOf(a, 0));</p><p> for (int i=0; i<arr.length; i++)<br /> arr[i] = new UnmodifiableEntry<>((Map.Entry<K,V>)arr[i]);</p><p> if (arr.length > a.length)<br /> return (T[])arr;</p><p> System.arraycopy(arr, 0, a, 0, arr.length);<br /> if (a.length > arr.length)<br /> a[arr.length] = null;<br /> return a;<br />}toArray() 源碼，請參見我在google code 上傳的 sdk 源碼： src-jdk1.7.0_02