自JDK 8開始出現的跨版本代碼行合并機制將在JDK 9之后宣告中止

[[91577]]

就在開發人員們準備由Java開發工具包（簡稱JDK）8向JDK 9邁進之際，甲骨文公司***Java高管建議限制對這兩個版本的代碼行進行合并。

在本周一下午發往OpenJDK的一封郵件當中，甲骨文公司Java平臺部門***架構師Mark Reinhold指出針對JDK 8（將于2014年年初到期）的變動將快速縮減，而JDK 9的“forests”——也就是一種目錄樹或者目錄集機制——則將很快開放。現在開發人員必須應對相關管理變化、從而順利與這兩個版本進行對接，Reinhold表示。

一般來說，變動通常需要首先在開發版本中進行測試，而后才會回遷到較早版本當中。不過這一規則對于即將壽終正寢的版本來說并不太適用，因為籌備中的版本（也就是目前JDK 8的情況）在此期間將更多地接收全方位測試、而不再像繼任者那樣以新功能與新特性作為主要訴求。由于各類調整都會在繼任版本中體現，所以即將淘汰的上代版本在發布速度上也會比較緩慢。

在此之前，也就是JDK 7，甲骨文并不提供處理并行變動的政策。開發人員通常會在接到請求之后將變動納入當前版本中，來自Sun/甲骨文版本工程團隊的人員則以半自動方式將前代版本與繼任版本進行合并——某些不切實際的合并請求將不會被采納。其后，開發人員需要將變動推送至新舊兩個版本當中；漏洞數據庫查詢機制則被用于確保不同變動能夠作用一正確的對應版本。

“這套方案一直沒能取得理想的效果，”Reinhold告訴我們。“它要求數百位開發人員始終關注并調整前代版本，從而監控半自動合并流程是否正常進行；一旦合并中止，他們就需要馬上對集成工作流進行調整。”

為了簡化前代版本的發布流程，Reinhold建議將JDK 9的開發forests以JDK 8的特定build初始狀態作為起點。“在這套build之后，我們不再允許對兩個版本的代碼行進行合并。向JDK 8提交變動的開發人員還需要獨立將該變動交付至JDK 9——前提是這項變動適用于JDK 9。”

Reinhold希望此舉能夠讓整個流程更加簡潔明了。“我能想到的惟一缺點就是開發人員無法再通過JDK 9來創建JDK 8通用版了，這是因為前者將優先考慮與JDK 8的兼容性而非JDK 8通用版。如果能做到這一點當然很方便也很酷，但我認為它最多能帶來某種成就感、而不是實際層面的技術價值。大家無法通過JDK 8創建JDK 7更新版本；現在的情況與當時并沒有什么區別。”

以Java Standard Edition 8為基礎的JDK 8能夠支持Lambda項目，從而使其更易于編寫運行在多核心處理器中的代碼。目前已經有一套預覽版本可供使用。隨后的Java SE 9版本預計將于2016年年初面世，能夠通過Jigsaw項目為Java帶來模塊化功能機制。

原文鏈接：http://www.infoworld.com/t/java-programming/oracle-limit-backward-compatibility-java-9-java-8-231967