前幾天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#一樣需要基於特定的“委托類型”，顯得更為靈活。
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的尴尬境地吧。
而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）：
try {
map(files, #(String f)(new File(f).getCanonicalPath())
catch (IOException ex) {
...
}
但是，如果我們要寫出之前那種“漂亮”的寫法，就不能使用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) f1 = f; // cast implicitly or explicitly
此外還有一些特性，例如與MethodHandle類型的轉化，我就沒有特別的看法了。
文章來源：http://blog.zhaojie.me/2010/06/first-version-of-lambda-and-closures-in-java- 7.html
