在過去的 2017 年中，Java 世界中發(fā)生了許多前所未有的變化，其部分原因在于 Java 9 的推出，盡管它推后了近一年的時間。

然而，隨著時間的推移人們可能會發(fā)現(xiàn)，推出 Java 9 版本的意義，遠沒有隨該新版本一并推出的 Java 版本發(fā)布周期變更為每六個月一次的意義更為重大。Java 版本發(fā)布周期的變更，意味著在 2018 年將會推出兩個 Java 新版本，而非一個。

2018 年將推出的第一個新版本稱為 Java 10，第二個新版本是 Java 11。雖然這一命名方案與現(xiàn)有命名看上去毫無二致，但是新版本只有經過重大公開辯論并達成最終共識后，才能得以推出。

鑒于新版本的推出將切換到這樣一種嚴格按時間點的節(jié)奏，預計這將使每個新版本中發(fā)布的 Java 特性，比迄今為止所能看到的范圍更為縮減。就 Java 10 而言，這意味著新特征的數(shù)量將相當之少。

InfoQ 先前曾報道了 Java 10 中的主要特性，一會也會再說。此后，該版本中添加特性的僅是一些細微的（Additional Unicode Extensions）、清理性質的（移除了原生的頭部生成工具，提供默認的 CA 根證書）、實驗性質的（基于 Java 的 JIT 編譯器 Graal），或是當前為利基性質的 (對異構內存架構的支持)。

至于 Java 11 中考慮了哪些功能，目前更是云山霧罩。我們只能確認下列幾個功能在考慮范圍內：

·Epsilon。一種對 Null 垃圾回收算法的參考實現(xiàn)。

·Dynamic Class File Constants 。一種主要針對軟件庫編寫人員及使用動態(tài)特性 invokedynamic 高級開發(fā)人員的平臺特性。

·運行時追蹤 JIT 編譯事件。

一旦發(fā)布日期臨近，該特性列表肯定會被填滿。但是值得注意的是，列表中目前尚未提及 Java 值類型。這也許并不出乎意料，因為實現(xiàn)值類型需要對 Java 語言和運行時做重大更改，并對 Java 類型系統(tǒng)（包括泛型）做完全重構。

盡管當前原型已工作，但是距特性交付尚有很長的路要走。當前狀態(tài)只適用于低級別的平臺開發(fā)人員，以及那些習慣于使用基于反射（reflective）或 MethodHandle 工具的開發(fā)人員?？瓷先チ钊瞬豢伤甲h的是，盡管值類型將作為 Java 11 的一部分發(fā)布，但是 Oracle 依然尚未對該特性預期于何時發(fā)布公開發(fā)表任何評論。

但是，如果值類型并未作為 Java 11 的一部分提供，這將會產生連鎖反應。包含值類型的首個長期支持（LTS）版本將不會在 2021 年 9 月前發(fā)布。

在撰寫本文時，我們尚不清楚已在提案中的數(shù)據(jù)類（data classes）特性是否會出現(xiàn)在 Java 11 中。正如 Java 語言架構師 Brian Goetz 所介紹的：

數(shù)據(jù)類將用于解決類的表示與 API 合約間存在的復雜間接關系。通過使用數(shù)據(jù)類，編譯器可以填入一些常規(guī)類成員。

展開全文

數(shù)據(jù)類提案與 Scala 的 Case 類具有一些相似之處。但是 Goetz 明確指出，數(shù)據(jù)類的設計空間中還存在一些可能的變動，該特性的整體語義含義要比目前我們能看到的更為深入。目前的數(shù)據(jù)類概念是與同處于開發(fā)過程中的模式匹配特性深度關聯(lián)在一起的。但是，這兩個特性可能會在不同的版本中提供。

與上面兩個特性都相關的是，未來可能對 Switch 形式做改進。Switch 語句塊將可作為表達式或聲明使用。

該特性相對較小，有望在 Java 11 中交付，即便數(shù)據(jù)類或模式匹配特性尚未實現(xiàn)。但目前情況看，該特性仍然是一個 JEP 草案。

最終將于 9 月發(fā)布的版本，其特性完成日期是 2018 年 6 月。因此，在 Java 11 的整體形態(tài)浮出水面之前，我們必須再等待數(shù)月時間。

說回到 Java 10，它的新特性還在確認當中，所以從現(xiàn)在到 GA 版中間還是有可能加入重大的變更。不管怎樣，在這四個月里，開發(fā)者還是可以期待一些新的特性能夠被添加到 Java 10 中。

新的特性和增強一般通過 Java Enhancement Process（JEP）或 Java Community Process 標準請求（JSR）進行跟蹤。因為 Java 10 的時間線較短，范圍也相對較小，所以 Java 10 的變更將通過 JEP 進行跟蹤。

有望被包含在 Java 10 中的特性是那些已經處于 Targeted 或 Proposed 狀態(tài)的 JEP，它們包括：

·286：本地變量類型推斷

·296：統(tǒng)一 JDK 倉庫

·304：垃圾回收器接口

·307：G1 的并行 Full GC

·310：應用程序類數(shù)據(jù)共享

·312：ThreadLocal 握手機制

JEP 296 是一次純粹的清理工作，而 JEP 304 加強了不同垃圾回收器的代碼隔離，并為垃圾回收器引入更簡潔的接口。

JEP 304 意味著廠商可以更自由地選擇特定的 GC 算法來構建 JDK，因為現(xiàn)在有多種處于開發(fā)當中的 GC，如 Shenandoah、ZGC 和 Epsilon，在未來可以使用這些 GC 算法。社區(qū)也在努力棄用甚至移除 Concurrent Mark Sweep（CMS）垃圾回收器，只是目前還沒有可用的替代品。

比較有意思的變更或許是 JEP 286，增強的本地變量類型推斷可以讓開發(fā)者免去很多變量申明模板代碼。也就是說，在下一個版本中，下面的變量聲明是合法的：

var list = new ArrayListString(); // infers ArrayListString

var stream = list.stream(); // infers StreamString

這種語法只限于初始化過的本地變量和 for 循環(huán)中的本地變量。

它其實是個語法糖，在語義上并沒有任何變化。不過，該特性有可能在 Java 開發(fā)者當中引起熱議。其他三個變更都將在性能方面帶來一些影響。

JEP 307 解決了 G1 垃圾回收器的一個問題——截止到 Java 9，G1 的 Full GC 采用的是單線程算法。也就是說，G1 在發(fā)生 Full GC 時會嚴重影響性能。JEP 307 的目的就是要采用并行 GC 算法，在發(fā)生 Full GC 時可以使用多個線程進行并行回收。

JEP 310 對類數(shù)據(jù)共享（CDS）進行了擴展，JVM 可以將一些類記錄到一個共享的壓縮文件里，在 JVM 下一次啟動時可以將這個文件映射到 JVM 進程，以此來減少啟動時間。該文件也可以在多個 JVM 間共享，在同一個機器上運行多個 JVM 時，這樣做可以減少內存占用。

該功能在 Java 5 中就已存在，但截止到 Java 9，該功能只允許 bootstrap 類加載器加載壓縮的類。JEP 310 的目的是擴展該功能，讓應用程序和自定義類加載器也能加載壓縮的類。該特性目前僅在 Oracle JDK 中可用，OpenJDK 并不包含該特性。

JEP 計劃將該特性從 Oracle 私有倉庫中遷移到公共倉庫，從 Java 10 往后，常規(guī)版本（非 LTS）將會使用 OpenJDK 的二進制包。此舉表明有用戶正在使用該特性，所以需要在 OpenJDK 中也支持該特性。

JEP 312 旨在改進虛擬機性能，在應用程序線程上調用回調不再需要執(zhí)行全局虛擬機安全點操作，這意味著 JVM 可以停止單個線程。一些底層小改進包括：

·降低堆棧跟蹤取樣所帶來的影響（如進行 profiling）。

·減少信號依賴以獲得更好的堆棧取樣。

·通過停止單獨線程改進偏向鎖。

·從 JVM 移除了一些內存屏障。

從整體來看，Java 10 似乎并沒有包含重大新特性或性能改進。這是可以理解的，畢竟這是新發(fā)布周期下的第一個版本。