六-1 在泛型代碼中使用遺留代碼
[url=http://xoj.blogone.net][url]
當(dāng)你在享受在代碼中使用泛型帶來的好處的時候，你怎么樣使用遺留代碼呢？
假設(shè)這樣一個例子，你要使用com.Foodlibar.widgets這個包。Fooblibar.com
的人要銷售一個庫存控制系統(tǒng)，主要部分如下：
package com.Fooblibar.widgets;
public interface Part { ... }
public class Inventory {
/**
*Adds a new Assembly to the inventory databse.
*The assembly is given the name name, and consists of a set
*parts specified by parts. All elements of the collection parts
*must support the Part interface.
**/
public static void addAssembly(String name, Collection parts) {...}
public static Assembly getAssembly(String name) {...}
}
public interface Assembly{
Collection getParts();//Returns a collection of Parts
}
現(xiàn)在，你可以用上面的API來增加新的代碼，它可以很好的保證你調(diào)用參數(shù)恰當(dāng)
的addAssembly()方法，就是說傳遞的集合是一個Part類型的Collection對象，當(dāng)
然，泛型是最適合做這個：
package com.mycompany.inventory;
import com.Fooblibar.widgets.*;
public class Blade implements Part{
...
}
public class Guillotine implements Part {
}
public class Main {
public static void main(Sring[] args) {
Collection<Part> c = new ArrayList<Part>();
c.add(new Guillotine());
c.add(new Blade());
Inventory.addAssembly("thingee", c);
Collection<Part> k = Inventory.getAssembly("thingee").getParts();
}
}
當(dāng)我們調(diào)用addAssembly方法的時候，它想要的第二個參數(shù)是Collection類型的，
實參是Collection<Part>類型，但卻可以，為什么呢？畢竟，大多數(shù)集合存儲的都不是
Part對象，所以總的來說，編譯器不會知道Collection存儲的是什么類型的集合。
在正規(guī)的泛型代碼里面，Collection都帶有類型參數(shù)。當(dāng)一個像Collection這樣
的泛型不帶類型參數(shù)使用的時候，稱之為原生類型。
很多人的第一直覺是Collection就是指Collection<Object>，但從我們先前所
看到的可以知道，當(dāng)需要的對象是Collection<Object>，而傳遞的卻是Collection<Part>
對象的時候，是類型不安全的。確切點的說法是Collection類型表示一個未知類型的
集合，就像Collection<?>。
稍等一下，那樣做也是不正確的！考慮一下調(diào)用getParts()方法，它返回一個
Collection對象，然后賦值給k，而k是Collection<Part>類型的；如果調(diào)用的結(jié)果
是返回一個Collection<?>的對象，這個賦值可能是錯誤的。
事實上，這個賦值是允許的，只是它會產(chǎn)生一個未檢測警告。警告是需要的，因為
編譯器不能保證賦值的正確性。我們沒有辦法通過檢測遺留代碼中的getAssembly()方法
來保證返回的集合的確是一個類型參數(shù)是Part的集合。程序里面的類型是Collection，
我們可以合法的對此集合插入任何對象。
所以，這不應(yīng)該是錯誤的嗎？理論上來說，答案是：是；但實際上如果是泛型代碼
調(diào)用遺留代碼的話，這又是允許的。對這個賦值是否可接受，得取決于程序員自己，在
這個例子中賦值是安全的，因為getAssembly()方法約定是返回以Part作為類型參數(shù)的
集合，盡管在類型標記中沒有表明。
所以原生類型很像通配符類型，但它們沒有那么嚴格的類型檢測。這是有意設(shè)計成
這樣的，從而可以允許泛型代碼可以與之前已有的遺留代碼交互。
在泛型代碼中調(diào)用遺留代碼固然是危險的，一旦把泛型代碼和非泛型代碼混合在一
起，泛型系統(tǒng)所提供的全部安全保證就都變得無效了。但這仍比根本不使用泛型要好，
最起碼你知道你的代碼是一致的。
泛型代碼出現(xiàn)的今天，仍然有很多非泛型代碼，二者混合同時使用是不可避免的。
如果一定要把遺留代碼與泛型代碼混合使用，請小心留意那些未檢測警告。仔細的
想想如何才能判定引發(fā)警告的代碼是安全的。
如果仍然出錯，代碼引發(fā)的警告實際不是類型安全的，那又怎么樣呢？我們會看
那樣的情況，接下來，我們將會部分的觀察編譯器的工作方式。
六-2 擦除和翻譯
public String loophole(Integer x){
List<String> ys = new LinkedList<String>();
List xs = ys;
xs.add(x);//編譯時未檢測警告
return ys.iterator().next();
}
在這里我們定義了一個字符串類型的鏈表和一個一般的老式鏈表，我們先插入
一個Integer對象，然后試圖取出一個String對象，很明顯這是錯誤的。如果我們
忽略警告繼續(xù)執(zhí)行代碼的話，程序?qū)谖覀兪褂缅e誤類型的地方出錯。在運行時，
代碼執(zhí)行大致如下：
public String loophole(Integer x) {
List ys = new LinkedList;
List xs = ys;
xs.add(x);
return (String)ys.iterator().next();//運行時出錯
}
當(dāng)我們要從鏈表中取出一個元素，并把它當(dāng)作是一個字符串對象而把它轉(zhuǎn)換為
String類型的時候，我們將會得到一個ClassCastException類型轉(zhuǎn)換異常。在
泛型版本的loophole()方法里面發(fā)生的就是這種情況。
出現(xiàn)這種情況的原因是，Java的泛型是通過一個前臺轉(zhuǎn)換“擦除”的編譯器實現(xiàn)
的，你基本上可以認為它是一個源碼對源碼的翻譯，這就是為何泛型版的loophole()
方法轉(zhuǎn)變?yōu)榉欠盒桶姹镜脑颉?BR>結(jié)果是，Java虛擬機的類型安全性和完整性永遠不會有問題，就算出現(xiàn)未檢測
的警告。
基本上，擦除會除去所有的泛型信息。尖括號里面的所有類型信息都會去掉，比
如，參數(shù)化類型的List<String>會轉(zhuǎn)換為List。類型變量在之后使用時會被類型
變量的上界（通常是Object）所替換。當(dāng)最后代碼不是類型正確的時候，就會加入
一個適當(dāng)?shù)念愋娃D(zhuǎn)換，就像loophole()方法的最后一行。
對“擦除”的完整描述不是本指南的范圍內(nèi)的內(nèi)容，但前面我們所給的簡單描述
也差不多是那樣了。了解這點很有好處，特別是當(dāng)你想做諸如把現(xiàn)有API轉(zhuǎn)為使用
泛型（請看第10部分）這樣復(fù)雜的東西，或者是想知道為什么它們會那樣的時候。
六-3 在遺留代碼中使用泛型
現(xiàn)在我們來看看相反的情況。假設(shè)Fooblibar.com把他們的API轉(zhuǎn)換為泛型的，
但有些客戶還沒有轉(zhuǎn)換。代碼就會像下面的：
package com.Fooblibar.widgets;
public interface Part { ... }
publlic class Inventory {
/**
*Adds a new Assembly to the inventory database.
*The assembly is given the name name, and consists of a set
*parts specified by parts. All elements of the collection parts
*must support the Part interface.
**/
public static void addAssembly(String name, Collection<Part> parts) {...}
public static Assembly getAssembly(String name){ ... }
}
public interface Assembly {
Collection<Part> getParts();//Return a collection of Parts
}
客戶代碼如下：
package com.mycompany.inventory;
import com.Fooblibar.widgets.*;
public class Blade implements Part {
...
}
public class Guillotine implements Part {
...
}
public class Main {
public static void main(String[] args){
Collection c = new ArrayList();
c.add(new Guillotine());
c.add(new Blade());
Inventory.addAssembly("thingee", c);//1: unchecked warning
Collection k = Inventory.getAssembly("thingee").getParts();
}
}
客戶代碼是在引進泛型之前寫下的，但是它使用了com.Fooblibar.widgets包和集
合庫，兩個現(xiàn)在都是在用泛型的。在客戶代碼里面使用的泛型全部都是原生類型。
第1行產(chǎn)生一個未檢測警告，因為把一個原生Collection傳遞給了一個需要Part類型的
Collection的地方，編譯器不能保證原生的Collection是一個Part類型的Collection。
不這樣做的話，你也可以在編譯客戶代碼的時候使用source 1.4這個標記來保證不
會產(chǎn)生警告。但是這樣的話你就不能使用所有JDK 1.5引入的新的語言特性。
七、晦澀難懂的部分
七-1 泛型類為所有調(diào)用所共享
下面的代碼段會打印出什么呢？
List<String> l1 = new ArrayList<String>();
List<Integer> l2 = new ArrayList<Integer>();
System.out.println(l1.getClass() == l2.getClass());
你可能會說是false，但是你錯了，打印的是true，因為所有泛型類的實例它們
的運行時的類（run-time class）都是一樣的，不管它們實際類型參數(shù)如何。
泛型類之所以為泛型的，是因為它對所有可能的類型參數(shù)都有相同的行為，相同
的類可以看作是有很多不同的類型。
結(jié)果就是，一個類的靜態(tài)的變量和方法也共享于所有的實例中，這就是為什么不
允許在靜態(tài)方法或初始化部分、或者在靜態(tài)變量的聲明或初始化中引用類型參數(shù)。
七-2 強制類型轉(zhuǎn)換和instanceof
泛型類在它所有的實例中共享，就意味著判斷一個實例是否是一個特別調(diào)用的泛
型的實例是毫無意義的：
Collection cs = new ArrayList<String>();
if (cs instanceof Collection<String>) {...}//非法
類似地，像這樣的強制類型轉(zhuǎn)換：
Collection<String> cstr = (Collection<String>) cs;//未檢測警告
給出了一個未檢測的警告，因為這里系統(tǒng)在運行時并不會檢測。
對于類型變量也一樣：
<T> T BadCast(T t, Object o) {
return (T) o;//未檢測警告
}
類型變量不存在于運行時，這就是說它們對時間或空間的性能不會造成影響。
但也因此而不能通過強制類型轉(zhuǎn)換可靠地使用它們了。
七-3 數(shù)組
數(shù)組對象的組件類型可能不是一個類型變量或一個參數(shù)化類型，除非它是一個
（無界的）通配符類型。你可以聲明元素類型是類型變量和參數(shù)華類型的數(shù)組類型，
但元素類型不能是數(shù)組對象。
這自然有點郁悶，但這個限制對避免下面的情況是必要的：
List<Strign>[] lsa = new List<String>[10];//實際上是不允許的
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(8));
oa[1] = li;//不合理，但可以通過運行時的賦值檢測
String s = lsa[1].get(0);//運行時出錯：ClassCastException異常
如果參數(shù)化類型的數(shù)組允許的話，那么上面的例子編譯時就不會有未檢測的警告，
但在運行時出錯。對于泛型編程，我們的主要設(shè)計目標是類型安全，而特別的是這個
語言的設(shè)計保證了如果使用了javac -source 1.5來編譯整個程序而沒有未檢測的
警告的話，它是類型安全的。
但是你仍然會使用通配符數(shù)組，這與上面的代碼相比有兩個變化。首先是不使用
數(shù)組對象或元素類型被參數(shù)化的數(shù)組類型，這樣我們就需要在從數(shù)組中取出一個字符
串的時候進行強制類型轉(zhuǎn)換：
List<?>[] lsa = new List<?>[10];//沒問題，無界通配符類型數(shù)組
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[1] = li;//正確
String s = (String) lsa[1].get(0);//運行時錯誤，顯式強制類型轉(zhuǎn)換
第二個變化是，我們不創(chuàng)建元素類型被參數(shù)化的數(shù)組對象，但仍然使用參數(shù)化元素
類型的數(shù)組類型，這是允許的，但引起現(xiàn)未檢測警告。這樣的程序?qū)嶋H上是不安全的，
甚至最終會出錯。
List<String>[] lsa = new List<?>[10];//未檢測警告-這是不安全的！
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<integer>();
li.add(new Integer(3));
oa[1]=li;//正確
String s = lsa[1].get(0);//運行出錯，但之前已經(jīng)被警告
類似地，想創(chuàng)建一個元素類型是類型變量的數(shù)組對象的話，將會編譯出錯。
<T> T[] makeArray(T t){
return new T[100];//錯誤
}
因為類型變量并不存在于運行時，所以沒有辦法知道實際的數(shù)組類型是什么。
要突破這類限制，我們可以用第8部分說到的用類名作為運行時標記的方法。
八、 把類名作為運行時的類型標記
JDK1.5中的一個變化是java.lang.Class是泛化的，一個有趣的例子是對
容器外的東西使用泛型。
現(xiàn)在Class類有一個類型參數(shù)T，你可能會問，T代表什么啊？它就代表Class
對象所表示的類型。
比如，String.class的類型是Class<String>，Serializable.class的
類型是Class<Serializable>，這可以提高你的反射代碼中的類型安全性。
特別地，由于現(xiàn)在Class類中的newInstance()方法返回一個T對象，因此
在通過反射創(chuàng)建對象的時候可以得到更精確的類型。
其中一個方法就是顯式傳入一個factory對象，代碼如下：
interface Factory<T> {T make();}
public <T> Collection<T> select(Factory<T> factory, String statement){
Collection<T> result = new ArrayList<T>();
//用JDBC運行SQL查詢
for(/*遍歷JDBC結(jié)果*/){
T item = factory.make();
/*通過SQL結(jié)果用反射和設(shè)置數(shù)據(jù)項*/
result.add(item);
}
return result;
}
你可以這樣調(diào)用：
select(new Factory<EmpInfo>(){ public EmpInfo make() {
return new EmpInfo();
}}
, "selection string");
或者聲明一個EmpInfoFactory類來支持Factory接口：
class EmpInfoFactory implements Factory<EmpInfo>{
...
public EmpInfo make() { return new EmpInfo();}
}
然后這樣調(diào)用：
select(getMyEmpInfoFactory(), "selection string");
這種解決辦法需要下面的其中之一：
· 在調(diào)用的地方使用詳細的匿名工廠類(verbose anonymous factory classes)，或者
· 為每個使用的類型聲明一個工廠類，并把工廠實例傳遞給調(diào)用的地方，這樣有點不自然。
使用類名作為一個工廠對象是非常自然的事，這樣的話還可以為反射所用。現(xiàn)在
沒有泛型的代碼可能寫作如下：
Collection emps = sqlUtility.select(EmpInfo.class, "select * from emps");
...
public static Collection select(Class c, String sqlStatement) {
Collection result = new ArrayList();
/*用JDBC執(zhí)行SQL查詢*/
for(/*遍歷JDBC產(chǎn)生的結(jié)果*/){
Object item = c.newInstance();
/*通過SQL結(jié)果用反射和設(shè)置數(shù)據(jù)項*/
result.add(item);
}
return result;
}
但是，這樣并不能得到我們所希望的更精確的集合類型，現(xiàn)在Class是泛化的，
我們可以這樣寫：
Collection<EmpInfo> emps =
sqlUtility.select(EmpInfo.class, "select * from emps");
...
public static <T> Collection<T> select(Class<T> c, String sqlStatement) {
Collection<T> result = new ArrayList<T>();
/*用JDBC執(zhí)行SQL查詢*/
for(/*遍歷JDBC產(chǎn)生的結(jié)果*/){
T item = c.newInstance();
/*通過SQL結(jié)果用反射和設(shè)置數(shù)據(jù)項*/
result.add(item);
}
return result;
}
這樣就通過類型安全的方法來得到了精確的集合類型了。
這種使用類名作為運行時類型標記的技術(shù)是一個很有用的技巧，是需要知道的。
在處理注釋的新的API中也有很多類似的情況。
九 通配符的其他作用
（more fun with wildcards，不知道如何譯才比較妥當(dāng)，呵呵。）
在這部分，我們將會仔細看看通配符的幾個較為深入的用途。我們已經(jīng)從幾個
有界通配符的例子中看到，它對從某一數(shù)據(jù)結(jié)構(gòu)中讀取數(shù)據(jù)是很有用的。現(xiàn)在來看
看相反的情況，只對數(shù)據(jù)結(jié)構(gòu)進行寫操作。
下面的Sink接口就是這類情況的一個簡單的例子：
interface Sink<T> {
flush(T t);
}
我們可以想象在下面的示范的例子中使用它，writeAll()方法用于把coll集合
里的所有元素填充(flush)到Sink接口變量snk中，并返回最后一個填充的元素。
public static <T> T writeAll(Collection<T> coll, Sink<T> snk){
T last;
for (T t: coll){
last = t;
snk.flush(last);
}
return last;
}
...
Sink<Object> s;
Collection<String> cs;
String str = writeAll(cs, s);//非法調(diào)用
如注釋所注，這里對writeAll()方法的調(diào)用是非法的，因為無有效的類型參數(shù)
可以引用；String和Object都不適合作為T的類型，因為Collection和Sink的元素
必須是相同類型的。
我們可以通過使用通配符來改寫writeAll()的方法頭來處理，如下：
public static <T> T writeAll(Collection<? extends T>, Sink<T>) {...}
...
String str = writeAll(cs, s);//調(diào)用沒問題，但返回類型錯誤
現(xiàn)在調(diào)用是合法的了，但由于T的類型跟元素類型是Object的s一樣，因為返回的
類型也是Object，因此賦值是不正確的。
解決辦法是使用我們之前從未見過的一種有界通配符形式：帶下界的通配符。
語法 ? super T 表示了是未知的T的父類型，這與我們之前所使用的有界
（父類型：或者T類型本身，要記住的是，你類型關(guān)系是自反的）
通配符是對偶有界通配符，即用 ? extends T 表示未知的T的子類型。
public static<T> T writeAll(Collection<T> coll, Sink<? super T> snk) {...}
...
String str = writeAll(cs, s);//正確！
使用這個語法的調(diào)用是合法的，指向的類型是所期望的String類型。
現(xiàn)在我們來看一個比較現(xiàn)實一點的例子，java.util.TreeSet<E>表示元素類型
是E的樹形數(shù)據(jù)結(jié)構(gòu)里的元素是有序的，創(chuàng)建一個TreeSet對象的一個方法是使用參數(shù)
是Comparator對象的構(gòu)造函數(shù)，Comparator對象用于對TreeSet對象里的元素進行
所期望的排序進行分類。
TreeSet(Comparator<E> c)
Comparator接口是必要的：
interface Comparator<T> {
int compare(T fst, T snd);
}
假設(shè)我們想要創(chuàng)建一個TreeSet<String>對象，并傳入一下合適的Comparator
對象，我們傳遞的Comparator是能夠比較字符串的。我們可以用Comparator<String>，
但Comparator<Object>也是可以的。但是，我們不能對Comparator<Object>對象
調(diào)用上面所給的構(gòu)造函數(shù)，我們可以用一個下界通配符來得到我們想要的靈活性：
TreeSet(Comparator<? super E> c)
這樣就可以使用適合的Comparator對象啦。
最后一個下界通配符的例子，我們來看看Collections.max()方法，這個方法
返回作為參數(shù)傳遞的Collection對象中最大的元素。
現(xiàn)在，為了max()方法能正常運行，傳遞的Collection對象中的所有元素都必
須是實現(xiàn)了Comparable接口的，還有就是，它們之間必須是可比較的。
先試一下泛化方法頭的寫法：
public static <T extends Comparable<T>>
T max(Collection<T> coll)
那樣，方法就接受一個自身可比較的（comparable）某個T類型的Collection
對象，并返回T類型的一個元素。這樣顯得太束縛了。
來看看為什么，假設(shè)一個類型可以與合意的對象進行比較：
class Foo implements Comparable<Object> {...}
...
Collection<Foo> cf = ...;
Collectins.max(cf);//應(yīng)該可以正常運行
cf里的每個對象都可以和cf里的任意其他元素進行比較，因為每個元素都是Foo
的對象，而Foo對象可以與任意的對象進行比較，特別是同是Foo對象的。但是，使用
上面的方法頭，我們會發(fā)現(xiàn)這樣的調(diào)用是不被接受的，指向的類型必須是Foo，但Foo
并沒有實現(xiàn)Comparable<Foo>。
T對于自身的可比性不是必須的，需要的是T與其父類型是可比的，就像下面：
（實際的Collections.max()方法頭在后面的第10部分將會講得更多）
public static <T extends Comparable<? super T>>
T max(Collection<T> coll)
這樣推理出來的結(jié)果基本上適用于想用Comparable來用于任意類型的用法：
就是你想這樣用Comparable<? super T>。
總的來說，如果你有一個只能一個T類型參數(shù)作為實參的API的話，你就應(yīng)該用
下界通配符類型（? suer T）；相反，如果API只返回T對象，你就應(yīng)該用上界通
配符類型（? extends T），以使得你的客戶的代碼有更大的靈活性。
九-1 通配符捕捉（？wildcard capture）
現(xiàn)在應(yīng)該很清楚，給出下面的例子：
Set<?> unknownSet = new HashSet<String>();
...
/** 給Set對象s添加一個元素t*/
public static <T> void addToSet<Set<T> s, T t) {...}
下面的調(diào)用是非法的。
addToSet(unknownSet, "abc");//非法的
這無異于實際傳遞的Set對象是一個字符串類型的Set對象，問題是作為實參傳遞的
是一個未知類型的Set對象，這樣就不能保證它是一個字符串類型或其他類型的Set對象。
現(xiàn)在，來看下面：
class Collections{
...
<T> public static Set<T> unmodifiableSet<Set<T> set) {...}
}
...
Set<?> s = Collections.unmodifiableSet(unknownSet);//這是可以的，
//為什么呢？
看起來這應(yīng)該是不允許的，但是請看看這個特別的調(diào)用，這完全是安全的，因此
這是允許的。這里的unmodifiableSet()確實是對任何類型的Set都適合，不管它的
元素類型是什么。
因為這種情況出現(xiàn)得相對頻繁，因此就有一個特殊的規(guī)則，對代碼能夠被檢驗是
安全的任何特定的環(huán)境，那樣的代碼都是允許的。這個規(guī)則就是所謂的“通配符捕捉”，
允許編譯器對泛型方法引用未知類型的通配符作為類型實參。
十 把遺留代碼轉(zhuǎn)化為泛型代碼
早前，我們展示了如何使泛型代碼和遺留代碼交互，現(xiàn)在該是時候來看看更難的
問題：把老代碼改為泛型代碼。
如果決定了把老代碼轉(zhuǎn)換為泛型代碼，你必須慎重考慮如何修改你的API。
你不能對泛型API限制得太死，它得要繼續(xù)支持API的最初約定。再看幾個關(guān)于
java.util.Collection的例子。非泛型的API就像這樣：
interface Collection {
public boolean containsAll(Collection c);
public boolean addAll(Collection c);
}
先這樣簡單來嘗試一下泛化：
interface Collection<E> {
public boolean containsAll(Collection<E> c);
public boolean addAll(Collection<E> c);
}
這個當(dāng)然是類型安全的，它沒有做到API的最初約定，containsAll()方法接受
傳入的任何類型的Collection對象，只有當(dāng)Collection對象中只包括E類型的實例
的時候才正確。但是：
· 傳入的Collection對象的靜態(tài)類型可能不同，這樣的原因可能是調(diào)用者不知道
傳入的Collection對象的精確類型，又或者它是Collection<S>類型的，其中S是E的
子類型。
· 對不同類型的Collection對象調(diào)用方法containsAll()完全是合法的，程序
應(yīng)該能夠運行，返回的是false值。
對于addAll()方法這種情況，我們應(yīng)該能夠添加任何存在了E類型的子類型的Collection
對象，我們在第5部分中看過了如何正確處理這種情況。
還要保證改進的API能夠保留對老客戶的二進制支持（? binary compatibility）。
這就意味著API“擦除”后（erasure）必須與最初的非泛型API一致。在大多數(shù)的情
況的結(jié)果是自然而然的，但有些小地方卻不盡如此。我們將仔細去看看我們之前遇到
過的最小的Collections.max()方法，正如我們在第9部分所見，似乎正確的max()
的方法頭：
public static <T extends Comparable<? super T>>
T max(CollectionT> coll)
基本沒問題，除了方法頭被“擦除”后的情況：
public static Comparable max(Collection coll)
這與max()方法最初的方法頭不一樣：
public static Object max(Collection coll)
本來是想得到想要的max()方法頭，但是沒成功，所有老的二進制class文件
調(diào)用的Collections.max()都依賴于一個返回Object類型的方法頭。
我們可以在類型參數(shù)T的邊界中顯式指定一個父類型來強制改變“擦除”的結(jié)果。
public static <T extends Object & Comparable<? super T>>
T max(Collection<T> coll)
這是一個對類型參數(shù)給出多個邊界的例子，語法是這樣：T1 & T2 ... & Tn.
多邊界類型變量對邊界類型列表中的所有類型的子類型都是可知的，當(dāng)使用多邊界
類型的時候，邊界類型列表中的第一個類型將被作為類型變量“擦除”后的類型。
最后，我們應(yīng)該記住max()方法只是從傳入的Collection方法中讀取數(shù)據(jù)，
因此也就適用于類型是T的子類型的任何Collection對象。
這樣就有了我們JDK中實際的方法頭：
public static <T extends Object & Comparable<? super T>>
T max(Collection<? extends T> coll)
在實踐中很少會有涉及到這么多東西的情況，但專業(yè)類型設(shè)計者在轉(zhuǎn)換現(xiàn)有的API
的時候應(yīng)該有所準備的仔細思慮。
另一個問題就是要小心協(xié)變返回（covariant returns）的情況，那就是改進
子類中方法的返回類型。你不應(yīng)該在老API中使用這個特性。
假設(shè)你最初的API是這樣的：
public class Foo {
public Foo create {...}//工廠方法，應(yīng)該是創(chuàng)建聲明的類的一個實例
}
public class Bar extends Foo {
public Foo create() {...}//實際是創(chuàng)建一個Bar實例
}
用協(xié)變返回的話，是這樣改：
public class Foo {
public Foo create {...}//工廠方法，應(yīng)該是創(chuàng)建聲明的類的一個實例
}
public class Bar extends Foo {
public Bar create() {...}//實際是創(chuàng)建一個Bar實例
}
現(xiàn)在，假設(shè)有這樣的第三方客戶代碼：
public class Baz extends Bar {
public Foo create() {...} //實際是創(chuàng)建一個Baz實例
}
Java虛擬機不直接支持不同返回類型的方法的覆蓋，編譯器就是支持這樣的
特性。結(jié)果就是，除非重編譯Baz類，否則的話它不會正確覆蓋Bar中的create()
方法。此外，Baz類需要修改，因為上面寫的代碼不能通過編譯，Baz中create()
方法的返回類型不是Bar類中create()方法的返回類型的子類型。