找出Java幕后發生的事情，以及新功能如何實現

在上一篇文章中，我們介紹了即將發布的Java 9版本的新功能和尚待解決的功能，并簡要提到了將新功能添加到下一個版本之前要經歷的過程。 由于此過程幾乎影響了所有Java開發人員，但大多數人對此知之甚少，因此本文將重點介紹內部人員對Java的看法（以及如何建議您一直想要的新功能）。 我們認為了解新功能如何生活的最佳方法是詢問負責將其實現的人。

我們與2位Java執行委員會成員Gil Tene和Werner Keil以及倫敦Java社區成員Richard Warburton進行了交談，并向他們詢問了Java的新功能以及他們希望將來看到什么樣的新功能。 這篇文章將涵蓋面試的第一部分。

但是在執行此操作之前，以下是參與創建新功能并對其進行投票的主要參與者：

組 –在廣泛的主題或特定代碼體系方面具有共同利益的個人和組織。 安全，網絡，Swing和HotSpot是一些示例。

項目 –產生大量代碼，文檔或其他努力的工作。 必須由至少一個團體贊助。 最近的示例是Lambda項目，Jigsaw項目和Sumatra項目。

JDK增強建議 （ JEP ）–允許在需要進一步探索時在JCP之前或與之并行地非正式地推廣新規范。 與JSR不同，它可能還包含沒有規范級可見性的功能（例如，新的垃圾收集器或JIT實現）。 接受的JEP成為JDK路線圖的一部分，并分配一個版本號。

Java Specification Request （ JSR ）–該功能的實際規范在此階段發生，可以通過組/項目，JEP或來自單個JCP（Java Community Process）成員來進行。 通常會為每個Java版本打開一個傘式JSR（也稱為平臺JSR），Java 9尚未實現。社區的每個成員也可以提出新的Java規范請求。

新功能如何進入Java？

Warburton： “真正的答案是有人想要該功能。 該人可以是大型供應商的內部工程師或項目經理，也可以是社區的外部成員。 無論哪種方式，都需要滿足嚴格的標準：

• 嚴重的用戶需求：它必須是對整個社區的共識。 示例：Java SE 8添加了lambdas-這項功能已經爭論了很多年，并且已經被人們要求。
• 經過試驗和測試：標準必須持續很長時間，并且修改已經建立的標準是非常困難且昂貴的過程。 結果是JCP（Java社區流程）并不是最前沿。 一旦技術為企業所采用，它就成為了一個去處。
• 并非每個供應商都獨有：標準必須適合所有供應商。 例如：弱/軟/幻像引用與垃圾收集器交互，因此以一種試圖最小化它們對GC設計的限制的方式指定了它們。

“一旦確定您的功能是一個好主意，就需要開始標準化過程。 這涉及到提出一個JSR（Java規范請求），它是更改Java的基本單元。 JSR需要多次投票。 首先，批準在此主題上啟動JSR是一個好主意。 每當進行公共審核時，都要反復進行迭代，以確保JSR朝著正確的方向前進。 最終是時候批準標準了。

Tene： “ Java長期以來一直在進行仔細和有意的增強。 在歷史上，仍然使Java比幾乎所有其他編程語言和環境更成功的事情之一是，它在避免Swift采用“最新的有趣事物”方面取得了相對的成功，以及它作為平臺的相對一致性。 在整個平臺（Java SE，EE等）整個平臺上都是如此，但在Java SE平臺（我將大部分精力集中在Java SE平臺上）中，可能最清楚地遵循了這一點。 集合，NIO，泛型，平臺優化的并發實用程序，MethodHandles，以及最新的Lambda表達式和流庫支持都是很好的示例，這些功能隨著時間的流逝而被添加并被廣泛采用，顯示了它們對平臺的真正價值及其重要性。不只是短暫的時尚。”

“ JCP（Java社區流程）負責通過JSR捕獲新功能。 成功的獨立JSR可以標準化一組特定功能或行為的語義。 但是，當功能成為平臺JSR的必需部分并由此成為Java SE或Java EE平臺的組成部分時，通常會證明該功能的最終成功和采用。 自從創建OpenJDK以來，我們已經看到Java SE的許多早期功能工作都從在JSR中開發到在JEP中開發（JDK增強建議）。 它們最終仍然像以前一樣經過規范和完成，并且也成為Platform JSR的一部分，但是我們看到了更多的開放開發，以及更多的試驗（不一定要成為JSR）。”

Keil： “ 3個競爭的JSON庫，一個用于Java EE，另一個Oracle專有與Java ME 8捆綁在一起，而另一個針對Java SE 9的基于JEP的獨立方法可能是最好的例子之一，這可能會出錯并且與用戶的使用相反。開發人員的需求或為Java設置一個標準的目標。 另一個可能是Java SE 8（JavaFX + JSR 310）引入的重疊和很大程度上不兼容的日期/時間API，而“ java.util”下以前存在另外兩個庫。 Java架構師提供了輸入和建議，但是從日期/時間API的角度來看，只有他們或其他人（包括一些執行委員會成員）指出的最糟糕的問題得以解決，而其他問題則被消除了。”

您能否分享您在Java社區流程中的個人經歷？

Keil： “前一段時間，我本人和共同規范負責人Antoine Sabot-Durand提出了一種JSR，用于基于標準化CDI的社交媒體連接器，以及類似的基于JSON，REST或OAuth等安全標準的類似API。 JSR被8：5的絕大多數拒絕。 鑒于Seam Social和Red Hat的整個Seam生態系統都被新項目取代，就像整個JBoss服務器在那個時候獲得了一個新的名稱和品牌（WildFly）一樣，由此產生的開源項目Agorava很自然地替代了Seam我們為JSR 357提出的社交和許多想法。”

社交媒體API執行委員會投票結果

Tene： “作為JCP執行委員會的一部分，我不得不考慮批準新的JSR。 在不止一個案例中，我投票拒絕了我認為不屬于平臺的JSR（并主張其他人也這樣做），但是大多數自然適合Java生態系統的JSR的門檻并不高。只要JSR負責人簽署就可以完成所涉及的詳細工作和流程。

Warburton： “我對日期和時間庫有所幫助。 我認為這使我對需要完善功能或方法簽名的每個單元的詳細程度有了更多的了解。 人們花費大量時間盡最大努力使這些API正確無誤。”

翻譯自: https://www.javacodegeeks.com/2014/10/java-9-behind-the-scenes-where-do-new-features-come-from.html

總結

以上是生活随笔為你收集整理的Java 9幕后花絮：新功能从何而来？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。