前幾天Oracle推出了Java 7官方的閉包與Lambda表達(dá)式的第一個(gè)實(shí)現(xiàn)，這基本上也是最終在正式版中的樣式了?？戳诉@個(gè)實(shí)現(xiàn)之后，我的第一感覺(jué)便是“丑”，當(dāng)然不排除這是因?yàn)榭磻T了其他語(yǔ)言中實(shí)現(xiàn)的緣故。后來(lái)再仔細(xì)看了看又想了想，發(fā)現(xiàn)Java 7的實(shí)現(xiàn)也并非毫無(wú)可取之處，但似乎又感到某些做法上有一些問(wèn)題?？傊麄€(gè)過(guò)程頗為有趣，決定將我的想法記錄下來(lái)，希望可以吸引人來(lái)一起討論一下。
為響水等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及響水網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、響水網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！
Java 7中的Lambda表達(dá)式
Java 7中的Lambda表達(dá)式有兩種形式，首先是第一種：
- #int() func1 = #()(3); // "func1.()" returns 3
- #int(int) func2 = #(int x)(x + 1); // "func2.(3)" returns 4
- #int(int, int) func3 = #(int x, int y)(x - y); // "func3.(5, 3)" returns 2
然后是第二種，含義與上面等價(jià)：
- #int() func1 = #(){ return 3; };
- #int(int) func2 = #(int x){ return x + 1; };
- #int(int, int) func3 = #(int x, int y){ return x – y; };
如果Lambda的body是“單個(gè)表達(dá)式”的話，便可以使用“小括號(hào)”，并省去最后的return關(guān)鍵字；如果body中需要包含多條語(yǔ)句的話，則必須使用“大括號(hào)”，而大括號(hào)內(nèi)部可以包含多條語(yǔ)句，就像一個(gè)普通的方法體一樣。這兩種寫(xiě)法在C#中也有對(duì)應(yīng)物，如在“單個(gè)表達(dá)式”的情況下：
- // C#
- Func func1 = () => 3; // "func1()" returns 3
- Func func2 = x => x + 1; // "func2(3)" returns 4
- Func func3 = (x, y) => x - y; // "func3(5, 3)" returns 2
第二種，即多條語(yǔ)句：
- // C#
- Func func1 = () => { return 3; };
- Func func2 = x => { return x + 1; };
- Func func3 = (x, y) => { return x – y; };
-
Java和C#的Lambda表達(dá)式都由兩部分組成：“參數(shù)列表”和“表達(dá)式體”，但是它們有如下區(qū)別：
◆在Java中參數(shù)列表和表達(dá)式體之間沒(méi)有分隔符號(hào)，而C#使用“=>”分隔。
◆對(duì)于“單個(gè)表達(dá)式”的Lambda來(lái)說(shuō)，C#可以無(wú)需使用括號(hào)包含表達(dá)式體，而Java必須使用小括號(hào)。
◆如果只有單個(gè)參數(shù)，那么C#的參數(shù)列表可以省去小括號(hào)，而Java必須保留。
◆C#對(duì)參數(shù)列表會(huì)進(jìn)行“類型推斷”，而Java必須寫(xiě)清參數(shù)類型。
這些區(qū)別說(shuō)大可大，說(shuō)小可小，但是Java語(yǔ)言的設(shè)計(jì)的確讓我感覺(jué)較C#為“丑”，這可能是個(gè)人主觀因素，但我認(rèn)為也不盡然。例如，如果我們需要對(duì)一個(gè)用戶對(duì)象數(shù)組按照“年齡”進(jìn)行排序，在C#里可以寫(xiě)作：
- // C#
- users.Sort(u => u.Age);
-
而在Java中則必須寫(xiě)為：
- Arrays.sort(users, #(User u)(u.Age));
-
-
這句C#代碼語(yǔ)義清晰：按照“u的Age進(jìn)行排序”，而在Java代碼中便顯得比較累贅，語(yǔ)義似乎也不夠清晰。Anders在設(shè)計(jì)C#語(yǔ)法的時(shí)候非常注重“聲明式”代碼，由此可見(jiàn)一斑。此外，我不明白為什么Java選擇不對(duì)參數(shù)進(jìn)行類型推斷，在我看來(lái)這對(duì)于寫(xiě)出優(yōu)雅代碼十分重要（關(guān)于這點(diǎn)，在“Why Java Sucks and C# Rocks”系列中會(huì)有更詳細(xì)的討論）。不過(guò)Java也不是沒(méi)有“推斷”，例如從上面的代碼片斷中可以得知，Java對(duì)于Lambda表達(dá)式的返回值還是進(jìn)行了類型推斷。事實(shí)上，Java還推斷了“異常類型”，這點(diǎn)稍后會(huì)有更多討論。
當(dāng)然，Java中可以“無(wú)中生有”地定義“匿名函數(shù)類型”（這點(diǎn)和VB.NET相對(duì)更為接近），而不需要像C#一樣需要基于特定的“委托類型”，顯得更為靈活。
#p#
SAM類型支持及閉包
SAM的全稱是Single Abstract Method，如果一個(gè)類型為SAM類型，則意味著它 1) 是抽象類型（即接口或抽象類），且 2) 只有一個(gè)未實(shí)現(xiàn)的方法。例如這樣一個(gè)Java接口便是個(gè)SAM類型：
- public interface Func {
- R invoke(T arg);
- }
-
-
-
于是我們便可以：
- Func[] array = new Func[10];
- for (int i = 0; i < array.length; i++) {
- final int temp = i;
- array[i] = #(int x)(x + temp);
- }
-
-
-
可見(jiàn)，我們使用Lambda表達(dá)式創(chuàng)建了Func接口的實(shí)例，這點(diǎn)是C#所不具備的。這點(diǎn)十分關(guān)鍵，因?yàn)樵贘ava類庫(kù)中已經(jīng)有相當(dāng)多的代碼使用了SAM類型。不過(guò)我發(fā)現(xiàn)，在某些使用SAM的方式下似乎會(huì)產(chǎn)生一些“歧義”，例如這段代碼：
- public class MyClass {
- @Override
- public int hashCode() {
- throw new RuntimeException();
- }
-
- public void MyMethod() {
- Func func = #(int x)(x * hashCode());
- int r = func.invoke(5); // throw or not?
- }
- }
-
-
在這里我們覆蓋（override）了MyClass的hashCode方法，使它拋出RuntimeException，那么在調(diào)用MyMethod中定義的func1對(duì)象時(shí)會(huì)不會(huì)拋出異常？答案是否定的，因?yàn)樵谶@個(gè)Lambda表達(dá)式中，隱藏的“this引用”代表了func對(duì)象，調(diào)用它的hashCode不會(huì)拋出RuntimeException。那么，假如我們要調(diào)用MyClass的hashCode怎么辦？那就稍微有些麻煩了：
- Func func = #(int x)(x * MyClass.this.hashCode());
-
-
-
不過(guò)從另一段示例代碼上看：
- public class MyClass {
-
- public int n = 3;
-
- public void MyMethod() {
- Func func = #(int x)(x + n);
- int r = func.invoke(5); // 8
- }
- }
由于Func對(duì)象上沒(méi)有n，因此這里的n便是MyClass類里定義的n成員了。因此，Java的閉包并非不會(huì)捕獲字面上下文里的成員，只是在SAM類型的情況下，字面范圍內(nèi)（lexical scope）成員的優(yōu)先級(jí)會(huì)低于目標(biāo)抽象類型的成員。
總體來(lái)說(shuō)，對(duì)于SAM類型的支持上，我認(rèn)為Java是有可取之處的，只是我始終認(rèn)為這個(gè)做法會(huì)產(chǎn)生歧義，因?yàn)槲矣∠笾衅渌Z(yǔ)言里的Lambda表達(dá)式似乎都是捕獲字面上下文的（當(dāng)然它們可能也沒(méi)有SAM支持）。但是，如何在“歧義”和“優(yōu)雅”之間做出平衡，我一時(shí)也找不到令人滿意的答案。
硬傷：Checked Exception
Java相當(dāng)于其他常見(jiàn)語(yǔ)言有一個(gè)特別之處，那就是Checked Exception。Checked Exception意味著每個(gè)方法要標(biāo)明自己會(huì)拋出哪些異常類型（RuntimeException及其子類除外），這也是方法契約的一部分，編譯器會(huì)強(qiáng)制程序員寫(xiě)出滿足異常契約的代碼。例如某個(gè)類庫(kù)中定義了這樣一個(gè)方法：
- public void myMethod() throws AException, BException
-
-
其中throws后面標(biāo)注的便是myMethod可能會(huì)拋出的異常。于是如果我們要寫(xiě)一個(gè)方法去調(diào)用myMethod，則可能是：
- public void myMethodCaller() throws AException {
- try {
- myMethod();
- } catch (BException ex) {
- throw new AException(ex);
- }
- }
-
-
當(dāng)我們寫(xiě)一個(gè)方法A去調(diào)用方法B時(shí)，我們要么在方法A中使用try...catch捕獲B拋出的方法，要么在方法A的簽名中標(biāo)記“會(huì)拋出同樣的異?！?。如上面的myMethodCaller方法，便在內(nèi)部處理了BException異常，而只會(huì)對(duì)外拋出AException。Java便使用這種方法嚴(yán)格限制了類庫(kù)的異常信息。
Checked Exception是一個(gè)有爭(zhēng)議的特性。它對(duì)于編寫(xiě)出高質(zhì)量的代碼非常重要，因?yàn)樵谀男┣闆r拋出異常其實(shí)都是方法契約的一部分（不僅僅是簽名或返回值的問(wèn)題），應(yīng)該嚴(yán)格遵守，在類庫(kù)升級(jí)時(shí)也不能破壞，否則便會(huì)產(chǎn)生兼容性的問(wèn)題。例如，您關(guān)注MSDN里的文檔時(shí)，就會(huì)看到異常的描述信息，只不過(guò)這是靠“文檔”記錄的，而Java則是強(qiáng)制在代碼中的；但是，從另一個(gè)角度說(shuō)，Checked Exception讓代碼編寫(xiě)變得非常麻煩，這導(dǎo)致的一個(gè)情況便是許多人在寫(xiě)代碼時(shí)，自定義的異常全都是RuntimeException（因?yàn)椴恍枰獦?biāo)記），每個(gè)方法也都是throws Exception的（這樣代碼中就不需要try...catch了），此時(shí)Checked Exception特性也基本形同虛設(shè)，除了造成麻煩以外幾乎沒(méi)有帶來(lái)任何好處。
我之前常說(shuō)：一個(gè)特性如果要被人廣泛接受，那它一定要足夠好用?，F(xiàn)在如Scala和Grovvy等為Java設(shè)計(jì)的語(yǔ)言中都放棄了Checked Exception，這也算是從側(cè)面印證了Checked Exception的尷尬境地吧。
#p#
而Checked Exception對(duì)于如今Lambda或閉包來(lái)說(shuō)，在我看來(lái)更像是一種硬傷。為什么這么說(shuō)？舉個(gè)例子吧，假如有這么一個(gè)map方法，可以把一個(gè)數(shù)組映射成另一個(gè)類型數(shù)組：
- public R[] map(T[] array, Func mapper) { ... }
-
-
好，那么比如這樣一個(gè)需求：給定一個(gè)字符串?dāng)?shù)組，保存著文件名，要求獲得它的標(biāo)準(zhǔn)路徑。從表面上看來(lái)，我們可以這樣寫(xiě)：
- map(files, #(String f)(new File(f).getCanonicalPath())
-
-
但事實(shí)上，這么做無(wú)法編譯通過(guò)。為什么？因?yàn)間etCanonicalPath方法會(huì)拋出IOException，我們?cè)谡{(diào)用時(shí)必須顯式地使用try...catch進(jìn)行處理。那么這段代碼該怎么寫(xiě)？還真沒(méi)法寫(xiě)。如果沒(méi)有Checked Exception的話（如C#），我們還可以這么做（處理第一個(gè)拋出的IOException）：
- public interface FuncThrowsIOException {
- R invoke(T arg) throws IOException;
- }
-
但是，如果我們要寫(xiě)出之前那種“漂亮”的寫(xiě)法，就不能使用Func而必須是這樣的接口類型：
- public interface FuncThrowsIOException {
- R invoke(T arg) throws IOException;
- }
-
或者是這樣的“匿名函數(shù)類型”：
#String(String)(throws IOException) // toCanonicalPath = #(String f)(new File(f).getCanonicalPath())
但是，作為L(zhǎng)ambda和閉包的常用場(chǎng)景，如map，filter，fold等“函數(shù)式”元素，是不可能為某種特定的“異常類型”而設(shè)計(jì)的——異常類型千變?nèi)f化，難道這也要用throws Exception來(lái)進(jìn)行“統(tǒng)一處理”嗎？Java雖然已經(jīng)支持對(duì)異常類型的“推斷”，但Checked Exception還是對(duì)Lambda和閉包的適用性造成了很大影響。
因此，我認(rèn)為Checked Exception是一個(gè)“硬傷”。
其他
Java的Lambda和閉包還有一些特性，例如參數(shù)的“泛化”：
- #boolean(Integer) f = #(Number n)(n.intValue() > 0);
-
由于Number是Integer的基類，因此我們可以使用Number來(lái)構(gòu)造一個(gè)接受Integer參數(shù)的匿名函數(shù)類型。由于示例較少，我還不清楚這個(gè)特性的具體使用場(chǎng)景和意義所在——不過(guò)我猜想，在Java中可能允許這樣做吧：
- #boolean(Number) f = #(Number n)(n.intValue() > 0);
- #boolean(Integer) ff1 = f; // cast implicitly or explicitly
-
此外還有一些特性，例如與MethodHandle類型的轉(zhuǎn)化，我就沒(méi)有特別的看法了。
趙劼，網(wǎng)名老趙，洋名Jeffrey Zhao，目前就職于盛大創(chuàng)新院產(chǎn)品開(kāi)發(fā)部，研究員。InfoQ中文站編輯，多次受邀于微軟TechED，MSDN WebCast及各微軟官方或社區(qū)會(huì)議中擔(dān)任技術(shù)議題講師。
原文地址：http://blog.zhaojie.me/2010/06/first-version-of-lambda-and-closures-in-java-7.html
當(dāng)前名稱：淺談Java7的閉包與Lambda表達(dá)式之優(yōu)劣
文章分享：
http://uogjgqi.cn/article/ccdjcjc.html
