隨著Java開發工具包(JDK)9的發布，大量的注意力都集中在Java的最新特性上，包括引入模塊(通過集成項目Jigsaw)。盡管最近的很多關注都集中在這些強大的新功能上，但下一個版本的Java:JDK 10已經開始準備了。在本文中，我們將粗略地介紹一下JDK 10的主要特性，并探討JDK 10中可能包含的一些特性。

請注意，本文中所包含的信息在寫本文時是準確的。但是到發布時，JDK 10特性組預計將會增加。

新功能

與之前的JDK版本一樣，對于即將到來的JDK 10也有一些主要特性。這些特性可以分為兩個主要類別:(1)目標發布，(2)建議發布。前者表示某些特性已計劃在JDK 10中發布，后一種類型表示這些特性還需要增加支持和成熟度。一旦條件允許，它就可以升級為一個目標發布狀態。

目標發布

目前有兩個主要功能針對JDK 10:

• 局部變量類型推斷,這將刪除大部分對象實例化所需的冗長的包含手動類型信息
• 整合源樹source tree的JDK庫,即不同的JDK庫將被合并成一個單一的存儲庫。

1. 局部變量類型推斷

強類型編程語言有很多優點，包括在編譯時發現類型錯誤，但是它們也引入了大量的樣板代碼，特別是在定義局部變量時。例如，當我們希望實例化一個對象時，我們被迫在賦值的左側提供顯式類型，并在賦值的右邊提供實現類型，如下面的片段所示:

MyObject value = new MyObject(); 

但是，當這個過程重復出現大量任務時，對象實例化可能變得令人沮喪和乏味。許多最流行的強類型的編程語言,比如C++, C#以及Go,在定義過程中，提供一種局部變量類型推斷的功能(例如C++提供了auto 關鍵字，C#提供var關鍵字)。但是，Java仍缺乏這樣的功能,它要求開發人員顯式聲明變量的預期清單類型。

為了解決這個問題,Java開發工具包(JDK)改進建議(JEP)286提出了一個上下文敏感的關鍵字var，允許局部變量被以下方式初始化：

var value = new MyObject();  
var list = new ArrayList(); 

由于var關鍵字是上下文敏感的，它的使用有下面的規則定義:

• 代碼使用var作為一個變量、方法或包名稱時將不受影響;而使用var作為類或接口名稱的代碼將受到影響。

同樣，類型推斷將受到以下方式的約束：

• 推斷類型將被限制在局部變量的初始化,增強的for循環索引,以及傳統的for循環中聲明;它(將)不用于方法形式、構造函數形式、方法返回類型、字段、捕獲形式，或任何其他類型的變量聲明。

考慮到所有的限制和細微差別，這個特性將有助于在開發人員創建的應用程序Java代碼中減輕大量的單調無聊的動作，并簡化JDK代碼庫。更多信息可以在官方的JEP 286規范中找到。

2. 整合的JDK庫

目前，有8個不同的Mercurial存儲庫用于存儲包含JDK的大量源代碼:

• root
• corba
• hotspot
• jaxp
• jaxws
• JDK
• langtools
• nashorn

雖然過多的存儲庫提供了對組成JDK的各種組件并清晰分離，但管理多個存儲庫存在一些主要的缺點。

其中最重要的一點是，在JDK的兩個不同部分，單個錯誤修復程序不能被原子跟蹤。例如，如果一個bug修復需要對獨立存儲庫中包含的系統的兩個部分進行更改，那么必須提交兩個提交:每個存儲庫中一個。這種不連續性很容易地降低項目和源代碼管理工具的可跟蹤性和復雜性。

為了解決這個問題，JEP 296建議將所有現有存儲庫合并到一個Mercurial存儲庫中。這種合并的一個次生效應是，這個單一的Mercurial存儲庫比現有的8個存儲庫要更容易的被鏡像(作為一個Git存儲庫)。

雖然在這個整合過程中，外部開發人員有一些阻力，但是JDK開發團隊似乎已經致力于使這一更改成為JDK 10的一部分。有關更多信息，請參見JEP 296，并提議整合由Michael Redlich發布的JDK 10 OpenJDK Mercurial存儲庫聲明。

建議發布

除了兩個目標特性之外，JDK 10目前還有三個建議，其中兩個主要是對JDK的垃圾收集器部分進行升級，另一個側重于對JDK的本地線程功能進行升級。

1 .清理垃圾收集接口

在當前的JDK結構中，組成垃圾收集器(GC)實現的組件分散在代碼庫的各個部分。盡管這些慣例對于使用GC計劃的JDK開發者比較熟悉，但對新的開發人員來說，對于特定GC的源代碼，或者創建一個新的GC常常會感到困惑。更重要的是，隨著Java modules的出現，我們希望在構建過程中排除不需要的GC，但是GC接口的當前橫切結構排除了這種增強。

JEP 304被設計為解決此問題的方案，并建議整合并清理GC接口，以便更容易地實現新的GC，并更好地維護現有的GC。本建議完成后，GC執行將負責提供以下內容:

• heap，CollectedHeap的子類
• barrier set，BarrierSet的子類，它實現了運行時的各種障礙
• 一個CollectorPolicy的實現
• GCInterpreterSupport的實現，它實現了解釋器的GC的各種障礙(使用匯編指令)
• GCC1Support的實現，它為C1編譯器實現了GC的各種障礙
• GCC2Support的實現，它為C2編譯器實現了GC的各種障礙
• 最終GC特定參數的初始化
• 設置MemoryService、相關的內存池、內存管理器等。

有關這些更改的更多信息，請參見JEP 304規范;有關Java GC的更多信息，請參閱Oracle提供的垃圾收集器基礎指南。

2. G1垃圾收集器并行化

隨著JDK 9的發布，Garbage-First(G1)GC取代了Parallel Collector作為默認GC。為了減少JDK 9之外的JDK版本中垃圾收集的影響，G1收集器將被并行化(以匹配并行收集器的特征)。雖然目前還沒有關于這個并行化的實現細節的信息，但是可以在JEP 307規范中找到關于此更改的更多細節。

有關GC實現的更多信息，請參閱Oracle的G1指南和并行收集器指南。

3. 項目線程局部握手

當前，停止Java線程是一個“全部或沒有”的過程，需要一個Java虛擬機(JVM)的安全點，以使一個線程停止。為了讓單獨的線程停止，JEP 312提議將回調包含到線程中。這一更改受到了限制，因為它顯著地提高了現有JVM功能的性能開銷，并且改變了到達JVM全局安全點的現有時間語義。有關這個建議的更多信息，請參閱JEP 312的Thread-Local Handshake OpenJDK討論。

結論

盡管JDK 9對于許多Java開發人員非常新鮮，但它的發展并沒有停止。特別是，JDK 10承諾為局部變量實例化引入類型推斷機制，并將現有的JDK存儲庫合并到一個Mercurial存儲庫中。

此外，在更成熟和更支持的情況下，JDK 10還可能包括一些重要的升級到GC接口和默認的GC實現，以及升級到JVM中單個線程的可尋址能力。雖然JDK 10的發布在未來仍然相對較遠，而且包含的特性很可能會成為Java時間軸上的一個重要里程碑。