淺談Java 7的閉包與Lambda表達(dá)式之優(yōu)劣
前幾天Oracle推出了Java 7官方的閉包與Lambda表達(dá)式的第一個(gè)實(shí)現(xiàn)，這基本上也是最終在正式版中的樣式了?？戳诉@個(gè)實(shí)現(xiàn)之后，我的第一感覺便是“丑”，當(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)一起討論一下。
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è)普通的方法體一樣。這兩種寫法在C#中也有對(duì)應(yīng)物，如在“單個(gè)表達(dá)式”的情況下：
- // C#
- Func<int> func1 = () => 3; // "func1()" returns 3
- Func<int, int> func2 = x => x + 1; // "func2(3)" returns 4
- Func<int, int, int> func3 = (x, y) => x - y; // "func3(5, 3)" returns 2
第二種，即多條語(yǔ)句：
- // C#
- Func<int> func1 = () => { return 3; };
- Func<int, int> func2 = x => { return x + 1; };
- Func<int, int, int> func3 = (x, y) => { return x – y; };
Java和C#的Lambda表達(dá)式都由兩部分組成：“參數(shù)列表”和“表達(dá)式體”，但是它們有如下區(qū)別：
◆在Java中參數(shù)列表和表達(dá)式體之間沒有分隔符號(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必須寫清參數(shù)類型。
這些區(qū)別說(shuō)大可大，說(shuō)小可小，但是Java語(yǔ)言的設(shè)計(jì)的確讓我感覺較C#為“丑”，這可能是個(gè)人主觀因素，但我認(rèn)為也不盡然。例如，如果我們需要對(duì)一個(gè)用戶對(duì)象數(shù)組按照“年齡”進(jìn)行排序，在C#里可以寫作：
- // C#
- users.Sort(u => u.Age);
而在Java中則必須寫為：
- Arrays.sort(users, #(User u)(u.Age));
這句C#代碼語(yǔ)義清晰：按照“u的Age進(jìn)行排序”，而在Java代碼中便顯得比較累贅，語(yǔ)義似乎也不夠清晰。Anders在設(shè)計(jì)C#語(yǔ)法的時(shí)候非常注重“聲明式”代碼，由此可見一斑。此外，我不明白為什么Java選擇不對(duì)參數(shù)進(jìn)行類型推斷，在我看來(lái)這對(duì)于寫出優(yōu)雅代碼十分重要（關(guān)于這點(diǎn)，在“Why Java Sucks and C# Rocks”系列中會(huì)有更詳細(xì)的討論）。不過(guò)Java也不是沒有“推斷”，例如從上面的代碼片斷中可以得知，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<T, R> {
- R invoke(T arg);
- }
于是我們便可以：
- Func<int, int>[] array = new Func<int, int>[10];
- for (int i = 0; i < array.length; i++) {
- final int temp = i;
- array[i] = #(int x)(x + temp);
- }
可見，我們使用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<int, int> 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<int, int> func = #(int x)(x * MyClass.this.hashCode());
不過(guò)從另一段示例代碼上看：
- public class MyClass {
- public int n = 3;
- public void MyMethod() {
- Func<int, int> func = #(int x)(x + n);
- int r = func.invoke(5); // 8
- }
- }
由于Func對(duì)象上沒有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)然它們可能也沒有SAM支持）。但是，如何在“歧義”和“優(yōu)雅”之間做出平衡，我一時(shí)也找不到令人滿意的答案。
硬傷：Checked Exception
Java相當(dāng)于其他常見語(yǔ)言有一個(gè)特別之處，那就是Checked Exception。Checked Exception意味著每個(gè)方法要標(biāo)明自己會(huì)拋出哪些異常類型（RuntimeException及其子類除外），這也是方法契約的一部分，編譯器會(huì)強(qiáng)制程序員寫出滿足異常契約的代碼。例如某個(gè)類庫(kù)中定義了這樣一個(gè)方法：
- public void myMethod() throws AException, BException
其中throws后面標(biāo)注的便是myMethod可能會(huì)拋出的異常。于是如果我們要寫一個(gè)方法去調(diào)用myMethod，則可能是：
- public void myMethodCaller() throws AException {
- try {
- myMethod();
- } catch (BException ex) {
- throw new AException(ex);
- }
- }
當(dāng)我們寫一個(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ì)于編寫出高質(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讓代碼編寫變得非常麻煩，這導(dǎo)致的一個(gè)情況便是許多人在寫代碼時(shí)，自定義的異常全都是RuntimeException（因?yàn)椴恍枰獦?biāo)記），每個(gè)方法也都是throws Exception的（這樣代碼中就不需要try...catch了），此時(shí)Checked Exception特性也基本形同虛設(shè)，除了造成麻煩以外幾乎沒有帶來(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<T, R> mapper) { ... }
好，那么比如這樣一個(gè)需求：給定一個(gè)字符串?dāng)?shù)組，保存著文件名，要求獲得它的標(biāo)準(zhǔn)路徑。從表面上看來(lái)，我們可以這樣寫：
- map(files, #(String f)(new File(f).getCanonicalPath())
但事實(shí)上，這么做無(wú)法編譯通過(guò)。為什么？因?yàn)間etCanonicalPath方法會(huì)拋出IOException，我們?cè)谡{(diào)用時(shí)必須顯式地使用try...catch進(jìn)行處理。那么這段代碼該怎么寫？還真沒法寫。如果沒有Checked Exception的話（如C#），我們還可以這么做（處理第一個(gè)拋出的IOException）：
- public interface FuncThrowsIOException<T, R> {
- R invoke(T arg) throws IOException;
- }
但是，如果我們要寫出之前那種“漂亮”的寫法，就不能使用Func<T, R>而必須是這樣的接口類型：
- public interface FuncThrowsIOException<T, R> {
- 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)化，我就沒有特別的看法了。
趙劼，網(wǎng)名老趙，洋名Jeffrey Zhao，目前就職于盛大創(chuàng)新院產(chǎn)品開發(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
【編輯推薦】
