在Devoxx大會上，Java SE首席工程師Mark Reinhol，做了一個關(guān)于Java 7（2010年初發(fā)布）最新發(fā)展方向的演講。雖然，Mark稱這次演講的內(nèi)容只是暫時的計劃、不具約束力，但是仍然在社區(qū)中引起了很多反響，特別是針對閉包特性（Closures）的遺漏。
Java 7特性的重要變化：
模塊化——294和Jigsaw項目
292——JVM對動態(tài)語言的支持
JSR 203——更多新的I/O API已基本完成，包括真正異步的I/O（不僅僅是非阻塞I/O）和一個真正的文件系統(tǒng)API。
JSR TBD：小的語言變化（見下）
安全重拋出——允許一個廣泛的catch語句，編譯器可以更加智能的基于try語句塊中拋出的異常管理重新拋出。（我以前沒有見過，不過看起來不錯）
Nulll解引用（dereference）表達式——Null通過’?’語法檢查，類似于Groovy...使開發(fā)人員避免一連串null檢查。
更好的類型推斷（type inference）——與泛型實例化有關(guān)，但目前還不清楚這種推斷會達到什么程度（我覺得越多越好）。
多捕捉（Multi-catch）——（是的?。┰试S在catch語句中用逗號分割一系列異常類型。
Joe Darcy正在領(lǐng)導Open JDK開發(fā)，他的博客地址是http://blogs.sun.com/darcy
JSR 296——Swing應用框架——仍然需要更簡化以方便Swing應用開發(fā)。
6u10特性的向前兼容（Java Kernal、QUickstarter、新Plug-in等）。
Java 7中可能不會引入的特性：
閉包——圍繞提議沒有形成一致意見
具體化泛型（Reified generics）
第一類屬性（1st class properties）
操作符重載
BigDecimal語法
JSR 295——Bean綁定
Java.net開展了一次有關(guān)“哪些Java 7未采納的特性是你最感興趣的”的調(diào)查，其中閉包明顯處于其他特性之前：
閉包 47.4% (734 Votes)
具體化泛型 17.2% (266 Votes)
第一類屬性 10.4% (162 Votes)
操作符重載 4.3% (67 Votes)
BigDecimal語法 3.4% (54 Votes)
JSR-295 Bean綁定 7.3% (113 Votes)
我對任何特性都不感興趣 9.7% (150 Votes)
以下是社區(qū)中的部分反應：
Ricky Clarkson：沒有閉包Java將滅亡
果然被證實了。雖然James Gosling想要閉包，雖然已經(jīng)有了3個閉包原型編譯器，雖然其他JVM語言支持閉包，Java 7還是沒有閉包。
Martin Kneissl：Java 7中沒有閉包是個壞消息
應該增加閉包而不是Java 5中的“for”循環(huán)新形式。在Java 6中就應該有閉包?，F(xiàn)在似乎Java 7中也不會有了。
閉包并不難以理解。至少當你把它們與Java中的匿名內(nèi)部類作比較時是這樣的。有的人不贊同。他們覺得總有一些愚蠢的程序員，所以應該限制語言以防止他們引起太多破壞，我不認同這個理由。這是不可能的。不稱職的程序員在任何語言中都會搬起石頭砸自己的腳。
幸運的是，JVM上還有其他語言可以使用Java的優(yōu)點：庫、可移植性和工具（某種程度上）。
Dustin Marx則對閉包有一些矛盾的看法
就在我寫這篇帖子的時候，已經(jīng)有160票投完（不過很快就會出現(xiàn)新的投票），其中Java SE 7中最期待的落選特性是閉包。目前，閉包特性已經(jīng)得到了總票數(shù)的幾乎一半。從某種意義上說，這并不奇怪。閉包似乎主宰了Java SE 7的討論直到被宣布不會在Java SE 7中引入。但是討論是圍繞著閉包的概念和如何實現(xiàn)閉包進行的爭論。雖然閉包是Java SE 7最期待的落選特性之一，但是我個人對此非常矛盾。我有時會偶然的在工作中意識到閉包是多么有用，但是多數(shù)情況下沒有它我也可以應付。也就是說，我不介意它被引入，但是當我聽到?jīng)]有被包含在Java SE 7中時這并沒有困擾我。但是，如果我們相信目前的投票結(jié)果，那么接近一半的Java開發(fā)人員最想要這個特性。這與Java.net有關(guān)開發(fā)人員最想要Java SE 7引入閉包的問卷調(diào)查是一致的。
Osvaldo Doederlein對新特性感到興奮，不過仍然很期望閉包
Java 7是多年基礎(chǔ)設(shè)施智能化的版本：294/Jigsaw，并發(fā)類加載——我認為這會提高大應用程序的啟動時間，特別是類似于JavaEE服務器和IDE 等基于微內(nèi)核的應用，XRender——將最終使Java成為Linux桌面應用的一等公民，G1，全64位支持（將在6u12中首次亮相，獲取beta版），F(xiàn)orkJoin。
這么多的好特性，我?guī)缀醵伎焱耸ラ]包的悲傷了。我猜是時候轉(zhuǎn)移到Scala、JavaFX或者其他現(xiàn)代JVM語言上了（只要不是類似于Ruby 或者Python的動態(tài)類型語言）。我認為從現(xiàn)在開始五年，如果我編寫某種低層次的運行時，我會只寫“標準”Java代碼。多虧社區(qū)的保護，Java語言 正在慢慢轉(zhuǎn)為一種遺產(chǎn)和低層次的角色。
Matt Grommes關(guān)注于BigDecimal語法
Devoxx和JavaEdge的與會者對JDK7語言的可能變化進行投票
絕對的勝者是——null處理。Null處理獲得了50張先支持票，是排在第二位的字符串切換（string switch）特性票數(shù)的兩倍，幾乎是全部先支持票數(shù)的三分之一。而且，幾乎有三分之二的與會者把它放在了前四位優(yōu)先支持的特性里。
其他受歡迎的特性包括字符串切換、異常的多捕捉、考試,大提示對Map的增強型for-each循環(huán)（能夠刪除或者查找索引）和ARM風格的資源管理。
不受歡迎的特性（特別認為是糟糕建議的）是通過[]訪問List/Map和字符串插值（字符串中的${variable} ）。
泛型推斷和多行字符串處于相對較低優(yōu)先級但與會者不是特別反感。
值得一提的是，在Devoxx上對閉包特性的投票結(jié)果是50:50
Java 7特性的重要變化：
模塊化——294和Jigsaw項目
292——JVM對動態(tài)語言的支持
JSR 203——更多新的I/O API已基本完成，包括真正異步的I/O（不僅僅是非阻塞I/O）和一個真正的文件系統(tǒng)API。
JSR TBD：小的語言變化（見下）
安全重拋出——允許一個廣泛的catch語句，編譯器可以更加智能的基于try語句塊中拋出的異常管理重新拋出。（我以前沒有見過，不過看起來不錯）
Nulll解引用（dereference）表達式——Null通過’?’語法檢查，類似于Groovy...使開發(fā)人員避免一連串null檢查。
更好的類型推斷（type inference）——與泛型實例化有關(guān)，但目前還不清楚這種推斷會達到什么程度（我覺得越多越好）。
多捕捉（Multi-catch）——（是的?。┰试S在catch語句中用逗號分割一系列異常類型。
Joe Darcy正在領(lǐng)導Open JDK開發(fā)，他的博客地址是http://blogs.sun.com/darcy
JSR 296——Swing應用框架——仍然需要更簡化以方便Swing應用開發(fā)。
6u10特性的向前兼容（Java Kernal、QUickstarter、新Plug-in等）。
Java 7中可能不會引入的特性：
閉包——圍繞提議沒有形成一致意見
具體化泛型（Reified generics）
第一類屬性（1st class properties）
操作符重載
BigDecimal語法
JSR 295——Bean綁定
Java.net開展了一次有關(guān)“哪些Java 7未采納的特性是你最感興趣的”的調(diào)查，其中閉包明顯處于其他特性之前：
閉包 47.4% (734 Votes)
具體化泛型 17.2% (266 Votes)
第一類屬性 10.4% (162 Votes)
操作符重載 4.3% (67 Votes)
BigDecimal語法 3.4% (54 Votes)
JSR-295 Bean綁定 7.3% (113 Votes)
我對任何特性都不感興趣 9.7% (150 Votes)
以下是社區(qū)中的部分反應：
Ricky Clarkson：沒有閉包Java將滅亡
果然被證實了。雖然James Gosling想要閉包，雖然已經(jīng)有了3個閉包原型編譯器，雖然其他JVM語言支持閉包，Java 7還是沒有閉包。
Martin Kneissl：Java 7中沒有閉包是個壞消息
應該增加閉包而不是Java 5中的“for”循環(huán)新形式。在Java 6中就應該有閉包?，F(xiàn)在似乎Java 7中也不會有了。
閉包并不難以理解。至少當你把它們與Java中的匿名內(nèi)部類作比較時是這樣的。有的人不贊同。他們覺得總有一些愚蠢的程序員，所以應該限制語言以防止他們引起太多破壞，我不認同這個理由。這是不可能的。不稱職的程序員在任何語言中都會搬起石頭砸自己的腳。
幸運的是，JVM上還有其他語言可以使用Java的優(yōu)點：庫、可移植性和工具（某種程度上）。
Dustin Marx則對閉包有一些矛盾的看法
就在我寫這篇帖子的時候，已經(jīng)有160票投完（不過很快就會出現(xiàn)新的投票），其中Java SE 7中最期待的落選特性是閉包。目前，閉包特性已經(jīng)得到了總票數(shù)的幾乎一半。從某種意義上說，這并不奇怪。閉包似乎主宰了Java SE 7的討論直到被宣布不會在Java SE 7中引入。但是討論是圍繞著閉包的概念和如何實現(xiàn)閉包進行的爭論。雖然閉包是Java SE 7最期待的落選特性之一，但是我個人對此非常矛盾。我有時會偶然的在工作中意識到閉包是多么有用，但是多數(shù)情況下沒有它我也可以應付。也就是說，我不介意它被引入，但是當我聽到?jīng)]有被包含在Java SE 7中時這并沒有困擾我。但是，如果我們相信目前的投票結(jié)果，那么接近一半的Java開發(fā)人員最想要這個特性。這與Java.net有關(guān)開發(fā)人員最想要Java SE 7引入閉包的問卷調(diào)查是一致的。
Osvaldo Doederlein對新特性感到興奮，不過仍然很期望閉包
Java 7是多年基礎(chǔ)設(shè)施智能化的版本：294/Jigsaw，并發(fā)類加載——我認為這會提高大應用程序的啟動時間，特別是類似于JavaEE服務器和IDE 等基于微內(nèi)核的應用，XRender——將最終使Java成為Linux桌面應用的一等公民，G1，全64位支持（將在6u12中首次亮相，獲取beta版），F(xiàn)orkJoin。
這么多的好特性，我?guī)缀醵伎焱耸ラ]包的悲傷了。我猜是時候轉(zhuǎn)移到Scala、JavaFX或者其他現(xiàn)代JVM語言上了（只要不是類似于Ruby 或者Python的動態(tài)類型語言）。我認為從現(xiàn)在開始五年，如果我編寫某種低層次的運行時，我會只寫“標準”Java代碼。多虧社區(qū)的保護，Java語言 正在慢慢轉(zhuǎn)為一種遺產(chǎn)和低層次的角色。
Matt Grommes關(guān)注于BigDecimal語法
Devoxx和JavaEdge的與會者對JDK7語言的可能變化進行投票
絕對的勝者是——null處理。Null處理獲得了50張先支持票，是排在第二位的字符串切換（string switch）特性票數(shù)的兩倍，幾乎是全部先支持票數(shù)的三分之一。而且，幾乎有三分之二的與會者把它放在了前四位優(yōu)先支持的特性里。
其他受歡迎的特性包括字符串切換、異常的多捕捉、考試,大提示對Map的增強型for-each循環(huán)（能夠刪除或者查找索引）和ARM風格的資源管理。
不受歡迎的特性（特別認為是糟糕建議的）是通過[]訪問List/Map和字符串插值（字符串中的${variable} ）。
泛型推斷和多行字符串處于相對較低優(yōu)先級但與會者不是特別反感。
值得一提的是，在Devoxx上對閉包特性的投票結(jié)果是50:50