淺談Java 7的閉包與Lambda表達式之優劣
前幾天Oracle推出了Java 7官方的閉包與Lambda表達式的第一個實現，這基本上也是最終在正式版中的樣式了。看了這個實現之后，我的第一感覺便是“丑”，當然不排除這是因為看慣了其他語言中實現的緣故。后來再仔細看了看又想了想，發現Java 7的實現也并非毫無可取之處，但似乎又感到某些做法上有一些問題。總之整個過程頗為有趣，決定將我的想法記錄下來，希望可以吸引人來一起討論一下。
Java 7中的Lambda表達式
Java 7中的Lambda表達式有兩種形式，首先是第一種：
- #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
然后是第二種，含義與上面等價：
- #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是“單個表達式”的話，便可以使用“小括號”，并省去最后的return關鍵字；如果body中需要包含多條語句的話，則必須使用“大括號”，而大括號內部可以包含多條語句，就像一個普通的方法體一樣。這兩種寫法在C#中也有對應物，如在“單個表達式”的情況下：
- // 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
第二種，即多條語句：
- // 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表達式都由兩部分組成：“參數列表”和“表達式體”，但是它們有如下區別：
◆在Java中參數列表和表達式體之間沒有分隔符號，而C#使用“=>”分隔。
◆對于“單個表達式”的Lambda來說，C#可以無需使用括號包含表達式體，而Java必須使用小括號。
◆如果只有單個參數，那么C#的參數列表可以省去小括號，而Java必須保留。
◆C#對參數列表會進行“類型推斷”，而Java必須寫清參數類型。
這些區別說大可大，說小可小，但是Java語言的設計的確讓我感覺較C#為“丑”，這可能是個人主觀因素，但我認為也不盡然。例如，如果我們需要對一個用戶對象數組按照“年齡”進行排序，在C#里可以寫作：
- // C#
- users.Sort(u => u.Age);
而在Java中則必須寫為：
- Arrays.sort(users, #(User u)(u.Age));
這句C#代碼語義清晰：按照“u的Age進行排序”，而在Java代碼中便顯得比較累贅，語義似乎也不夠清晰。Anders在設計C#語法的時候非常注重“聲明式”代碼，由此可見一斑。此外，我不明白為什么Java選擇不對參數進行類型推斷，在我看來這對于寫出優雅代碼十分重要（關于這點，在“Why Java Sucks and C# Rocks”系列中會有更詳細的討論）。不過Java也不是沒有“推斷”，例如從上面的代碼片斷中可以得知，Java對于Lambda表達式的返回值還是進行了類型推斷。事實上，Java還推斷了“異常類型”，這點稍后會有更多討論。
當然，Java中可以“無中生有”地定義“匿名函數類型”（這點和VB.NET相對更為接近），而不需要像C#一樣需要基于特定的“委托類型”，顯得更為靈活。
#p#
SAM類型支持及閉包
SAM的全稱是Single Abstract Method，如果一個類型為SAM類型，則意味著它 1) 是抽象類型（即接口或抽象類），且 2) 只有一個未實現的方法。例如這樣一個Java接口便是個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表達式創建了Func接口的實例，這點是C#所不具備的。這點十分關鍵，因為在Java類庫中已經有相當多的代碼使用了SAM類型。不過我發現，在某些使用SAM的方式下似乎會產生一些“歧義”，例如這段代碼：
- 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，那么在調用MyMethod中定義的func1對象時會不會拋出異常？答案是否定的，因為在這個Lambda表達式中，隱藏的“this引用”代表了func對象，調用它的hashCode不會拋出RuntimeException。那么，假如我們要調用MyClass的hashCode怎么辦？那就稍微有些麻煩了：
- Func<int, int> func = #(int x)(x * MyClass.this.hashCode());
不過從另一段示例代碼上看：
- 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對象上沒有n，因此這里的n便是MyClass類里定義的n成員了。因此，Java的閉包并非不會捕獲字面上下文里的成員，只是在SAM類型的情況下，字面范圍內（lexical scope）成員的優先級會低于目標抽象類型的成員。
總體來說，對于SAM類型的支持上，我認為Java是有可取之處的，只是我始終認為這個做法會產生歧義，因為我印象中其他語言里的Lambda表達式似乎都是捕獲字面上下文的（當然它們可能也沒有SAM支持）。但是，如何在“歧義”和“優雅”之間做出平衡，我一時也找不到令人滿意的答案。
硬傷：Checked Exception
Java相當于其他常見語言有一個特別之處，那就是Checked Exception。Checked Exception意味著每個方法要標明自己會拋出哪些異常類型（RuntimeException及其子類除外），這也是方法契約的一部分，編譯器會強制程序員寫出滿足異常契約的代碼。例如某個類庫中定義了這樣一個方法：
- public void myMethod() throws AException, BException
其中throws后面標注的便是myMethod可能會拋出的異常。于是如果我們要寫一個方法去調用myMethod，則可能是：
- public void myMethodCaller() throws AException {
- try {
- myMethod();
- } catch (BException ex) {
- throw new AException(ex);
- }
- }
當我們寫一個方法A去調用方法B時，我們要么在方法A中使用try...catch捕獲B拋出的方法，要么在方法A的簽名中標記“會拋出同樣的異常”。如上面的myMethodCaller方法，便在內部處理了BException異常，而只會對外拋出AException。Java便使用這種方法嚴格限制了類庫的異常信息。
Checked Exception是一個有爭議的特性。它對于編寫出高質量的代碼非常重要，因為在哪些情況拋出異常其實都是方法契約的一部分（不僅僅是簽名或返回值的問題），應該嚴格遵守，在類庫升級時也不能破壞，否則便會產生兼容性的問題。例如，您關注MSDN里的文檔時，就會看到異常的描述信息，只不過這是靠“文檔”記錄的，而Java則是強制在代碼中的；但是，從另一個角度說，Checked Exception讓代碼編寫變得非常麻煩，這導致的一個情況便是許多人在寫代碼時，自定義的異常全都是RuntimeException（因為不需要標記），每個方法也都是throws Exception的（這樣代碼中就不需要try...catch了），此時Checked Exception特性也基本形同虛設，除了造成麻煩以外幾乎沒有帶來任何好處。
我之前常說：一個特性如果要被人廣泛接受，那它一定要足夠好用。現在如Scala和Grovvy等為Java設計的語言中都放棄了Checked Exception，這也算是從側面印證了Checked Exception的尷尬境地吧。
#p#
而Checked Exception對于如今Lambda或閉包來說，在我看來更像是一種硬傷。為什么這么說？舉個例子吧，假如有這么一個map方法，可以把一個數組映射成另一個類型數組：
- public R[] map(T[] array, Func<T, R> mapper) { ... }
好，那么比如這樣一個需求：給定一個字符串數組，保存著文件名，要求獲得它的標準路徑。從表面上看來，我們可以這樣寫：
- map(files, #(String f)(new File(f).getCanonicalPath())
但事實上，這么做無法編譯通過。為什么？因為getCanonicalPath方法會拋出IOException，我們在調用時必須顯式地使用try...catch進行處理。那么這段代碼該怎么寫？還真沒法寫。如果沒有Checked Exception的話（如C#），我們還可以這么做（處理第一個拋出的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;
- }
或者是這樣的“匿名函數類型”：
#String(String)(throws IOException) // toCanonicalPath = #(String f)(new File(f).getCanonicalPath())
但是，作為Lambda和閉包的常用場景，如map，filter，fold等“函數式”元素，是不可能為某種特定的“異常類型”而設計的——異常類型千變萬化，難道這也要用throws Exception來進行“統一處理”嗎？Java雖然已經支持對異常類型的“推斷”，但Checked Exception還是對Lambda和閉包的適用性造成了很大影響。
因此，我認為Checked Exception是一個“硬傷”。
其他
Java的Lambda和閉包還有一些特性，例如參數的“泛化”：
- #boolean(Integer) f = #(Number n)(n.intValue() > 0);
由于Number是Integer的基類，因此我們可以使用Number來構造一個接受Integer參數的匿名函數類型。由于示例較少，我還不清楚這個特性的具體使用場景和意義所在——不過我猜想，在Java中可能允許這樣做吧：
- #boolean(Number) f = #(Number n)(n.intValue() > 0);
- #boolean(Integer) ff1 = f; // cast implicitly or explicitly
此外還有一些特性，例如與MethodHandle類型的轉化，我就沒有特別的看法了。
趙劼，網名老趙，洋名Jeffrey Zhao，目前就職于盛大創新院產品開發部，研究員。InfoQ中文站編輯，多次受邀于微軟TechED，MSDN WebCast及各微軟官方或社區會議中擔任技術議題講師。
原文地址：http://blog.zhaojie.me/2010/06/first-version-of-lambda-and-closures-in-java-7.html
【編輯推薦】
