Adam Messinger談Java 7與8

繼近日發布的Java 7之后，InfoQ有幸采訪到了Oracle Fusion中間件小組的開發副主席Adam Messinger以了解此次發布及Oracle對未來Java 8計劃的詳細信息。

InfoQ：能否向讀者介紹一下Oracle對于Java未來的整體規劃？

Oracle將會繼續與其他小組合作來發展Java，這包括一些大公司，如IBM，也包括一些個人；通過一些組織進行協作，從JCP（負責API及各種規范）到Oracle資助的各個開源小組，如GlassFish和OpenJDK以及其他一些參與者如Eclipse。總體說來，就是Java平臺將會繼續發展，成為面向各個層次開發者的高效、高可靠、高性能的技術。

你只需查看Oracle發布的關于Java產品的開發范圍就能了解到Oracle的承諾。Java SE 7已經發布，同時Java SE 8也在進行當中。GlassFish已經發布了3.1版，并且計劃今年底發布新的版本；JavaFX 2.0也快完成了、Java EE 7也呼之欲出、NetBeans 7也于近日發布，這都表明了我們現在的發展勢頭。當然了，Oracle Fusion Middleware和Oracle Exalogic Elastic Cloud等產品都是基于Java的。

InfoQ：你認為Java 7中最有意思或是最重要的特性有哪些呢？

我認為大多數開發者都會覺得Project Coin中的語言變化是最有用的。這些變化（諸如switch語句中可以使用字符串、菱形操作符、多catch異常以及帶有資源的try語法等）對開發者來說都是很有幫助的，因為所有這些特性的一個共同點就是他們都增強了現有源代碼的可讀性。這些變更的項目領導Joe Darcy還開發了一個注解處理器，這樣開發者就可以掃描現有的代碼以使用新的帶有資源的try語法來替換掉老式，有時很容易導致錯誤的代碼，而且新的語法更加緊湊。

我還要強調一下新的Filesystem API，它公開了現代文件系統的一些關鍵特性，如文件變化通知與符號鏈接，還支持更快速的塊操作，比如搜索目錄樹等。我認為這些特性是最為重要的。

我認為最有意思的特性當屬新的Fork/Join API，它有助于開發者們編寫出能夠并行運行的應用。過去，只有針對高端服務器編寫數據或算法密集型應用的開發者們才會在意應用是否是并行運行的，因此也會更加充分利用多核/多處理器架構的所有能力，但現在我們看到帶有四核芯片的臺式機也都是普通之物了，雙核的筆記本和智能手機也成為了標配。用不了多久，更多的開發者們將會考慮并行程序設計了。

InfoQ：NIO 2向Java引入了真正的異步I/O API。為何說這是很重要的呢？它的使用場景有哪些？

異步I/O是編寫高可伸縮的I/O密集型應用的一把利器。它與非阻塞I/O有幾分相似，后者屬于最初的NIO的一部分，在Java SE 1.4中被引入進來。非阻塞I/O非常適合于處理大量的開放網絡連接，但卻不適合于隨機訪問的I/O設備，如磁盤驅動等。異步I/O既適合于連續設備，也能勝任隨機訪問設備，它非常適合于某些應用架構。與非阻塞I/O一樣，我認為很多開發者并不會直接使用異步I/O API，但一旦使用就會發現它的價值所在。

InfoQ：NIO 2中新的Filesystem API似乎違背了Java一次編寫，到處運行的原則，因為Java開發者可以通過它訪問文件系統的文件特性。這是個好想法么？如果是，那為何不將其拓展到其他領域，比如可以從Java中執行通用的系統調用呢？

我不確定這么做是否違背了WORA原則，但即便如此，這也肯定不是第一次。Java在隔離開發者與底層架構和平臺的細節上做的很棒，但它無法掩蓋這樣一個事實：平臺與平臺之間是不同的。一個顯而易見的例子就是并非所有計算機都有顯示器，這樣他們就沒法以任何合理的方式運行Swing代碼了。是的，Filesystem API可以訪問到諸如符號鏈接等特性，并非所有平臺都有這個特性，但如果你非要抬杠，那我會說并非Java所運行的所有平臺都具備文件系統！

我們相信WORA原則是可靠的，這也正是Java變得如此成功的主要原因，我們將會繼續恪守這個原則。然而，我們也相信Java必須要能與特定于平臺、設備及實現的特性相結合才能繼續成長和成功。現在已經有了經過驗證的方式可以實現這種融合，比如通過一些抽象API再搭配上定義了特定于實現擴展的供應者。這正是Filesystem API和其他眾多的Java API所使用的架構，無論這些API是標準的抑或是第三方的都是如此。

至于最后一個問題，我覺得在Java中能夠更加輕松地進行系統調用是件很有意義的事情。我希望Java社區（如OpenJDK、JCP等）能夠就這個問題展開討論。

InfoQ：很多人認為需要向Java中添加lambdas支持的一個主要原因在于Fork/Join的需要。但你們為何首先發布了Fork/Join？這不是表明在將lambdas添加進來前這個API都是有問題的么？

這純粹是扯！我們通過多種發布途徑幫助開發者編寫并行應用。這起始于JDK 1.5，那時Doug Lea和他的JSR 166專家組添加了API層次支持以將應用分解為多個可以并行執行的任務。JDK 7中的Fork/Join框架是實現這個目標的另一種手段，但仍然提供了一套工具，當開發者了解該如何分解其編程任務時，他們就可以使用這些工具了。

我們要做的是盡可能將更多的設計與實現工作自動化以使應用能夠并行運行。Project Lambda包含了lambda表達式，用于實現更加簡潔的封裝函數行為以及并行算法的平臺實現，如過濾和映射等。他們可以通過現有的并行API實現，如Fork/Join，但這只不過是實現的細節問題而已。Lambda有助于我們將并行程序設計帶給大眾，但我敢肯定總會有一些“強力”開發者使用Fork/Join提供的一些更加手工的技術。

InfoQ：有人提議說Java 8可能會定義自動的并行塊數據操作，如過濾、映射和降級。能否談談呢？

這些塊數據操作非常重要，因為他們可以通過內部遍歷實現自動化的并行操作。這意味著現在不必再編寫傳統的循環來過濾集合（這是外部遍歷），你只需在lambda表達式中定義過濾器，然后將其傳遞給集合的filter方法即可，后者會在內部進行遍歷操作。因為filter方法可以控制遍歷實現的方式，因此在可能的情況下它會將工作分離到多個處理器核心上執行，但這一切對于開發者來說都是透明的。

InfoQ：Java 7通過invokeDynamic首次向JVM引入了新的字節碼指令。Project Coin中有一個相當不錯的提案，建議在Java語法中增加invokeDynamic，但卻被放棄了。能否介紹一下放棄它的背后原因么？它會在Java 8中重出江湖么？

在經過縝密透徹的分析后，我們認為通過一個只會被少數人所用的特性來擴展Java編程語言并沒有什么意義。我也懷疑Java 8會重新考慮它。

InfoQ：關于對JVM上其他語言的支持，你認為有哪些語言會從進一步的VM級的改變中獲益？

我們并沒有為了這種支持而選擇語言。我們所采取的方式是仔細觀察除了Java以外，開發者還對哪些語言感興趣。對VM進行額外的增強以改進JRuby、JavaScript、Scala及Clojure的性能是很有價值的，但他們只不過是大家能夠看到的而已。

InfoQ：你認為接下來還會對語言支持進行哪些調整——continuations、tail-calls還是interface injection？Java 8會支持他們么？

現在說這些為時尚早。目前John Rose正與很多語言設計者和實現者通力合作，他們采取了很務實的方法來對這些特性建立原型，然后評估哪些特性會帶來最大的價值。事實上，在上周舉辦的JVM語言峰會上有不少有意思的討論，你可以在 這里查看結果。

查看英文原文：Adam Messinger Talks to InfoQ About Java 7 and 8
      來自：http://www.infoq.com/cn/news/2011/08/messinger-vava7-qanda