在過去的 2017 年中，Java 世界中發生了許多前所未有的變化，其部分原因在於 Java 9 的推出，儘管它推後了近一年的時間。

然而，隨著時間的推移人們可能會發現，推出 Java 9 版本的意義，遠沒有隨該新版本一併推出的 Java 版本釋出週期變更為每六個月一次的意義更為重大。Java 版本釋出週期的變更，意味著在 2018 年將會推出兩個 Java 新版本，而非一個。

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

鑑於新版本的推出將切換到這樣一種嚴格按時間點的節奏，預計這將使每個新版本中釋出的 Java 特性，比迄今為止所能看到的範圍更為縮減。就 Java 10 而言，這意味著新特徵的數量將相當之少。

InfoQ 先前曾報道了 Java 10 中的主要特性，一會也會再說。此後，該版本中新增特性的僅是一些細微的（Additional Unicode Extensions）、清理性質的（移除了原生的頭部生成工具，提供預設的 CA 根證書）、實驗性質的（基於 Java 的 JIT 編譯器 Graal），或是當前為利基性質的 (對異構記憶體架構的支援)。

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

• Epsilon。一種對 Null 垃圾回收演算法的參考實現。

• Dynamic Class File Constants 。一種主要針對軟體庫編寫人員及使用動態特性 invokedynamic 高階開發人員的平臺特性。

• 執行時追蹤 JIT 編譯事件。

一旦釋出日期臨近，該特性列表肯定會被填滿。但是值得注意的是，列表中目前尚未提及 Java 值型別。這也許並不出乎意料，因為實現值型別需要對 Java 語言和執行時做重大更改，並對 Java 型別系統（包括泛型）做完全重構。

儘管當前原型已工作，但是距特性交付尚有很長的路要走。當前狀態只適用於低級別的平臺開發人員，以及那些習慣於使用基於反射（reflective）或 MethodHandle 工具的開發人員。看上去令人不可思議的是，儘管值型別將作為 Java 11 的一部分發布，但是 Oracle 依然尚未對該特性預期於何時釋出公開發表任何評論。

但是，如果值型別並未作為 Java 11 的一部分提供，這將會產生連鎖反應。包含值型別的首個長期支援（LTS）版本將不會在 2021 年 9 月前釋出。

在撰寫本文時，我們尚不清楚已在提案中的資料類（data classes）特性是否會出現在 Java 11 中。正如 Java 語言架構師 Brian Goetz 所介紹的：

資料類將用於解決類的表示與 API 合約間存在的複雜間接關係。通過使用資料類，編譯器可以填入一些常規類成員。

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

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

該特性相對較小，有望在 Java 11 中交付，即便資料類或模式匹配特性尚未實現。但目前情況看，該特性仍然是一個 JEP 草案。

最終將於 9 月釋出的版本，其特性完成日期是 2018 年 6 月。因此，在 Java 11 的整體形態浮出水面之前，我們必須再等待數月時間。

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

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

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

• 286：本地變數型別推斷

• 296：統一 JDK 倉庫

• 304：垃圾回收器介面

• 307：G1 的並行 Full GC

• 310：應用程式類資料共享

• 312：ThreadLocal 握手機制

JEP 296 是一次純粹的清理工作，而 JEP 304 加強了不同垃圾回收器的程式碼隔離，併為垃圾回收器引入更簡潔的介面。

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

比較有意思的變更或許是 JEP 286，增強的本地變數型別推斷可以讓開發者免去很多變數申明模板程式碼。也就是說，在下一個版本中，下面的變數宣告是合法的：

var list = new ArrayList<String>();  // infers ArrayList<String>
var stream = list.stream();          // infers Stream<String>

這種語法只限於初始化過的本地變數和 for 迴圈中的本地變數。

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

JEP 307 解決了 G1 垃圾回收器的一個問題——截止到 Java 9，G1 的 Full GC 採用的是單執行緒演算法。也就是說，G1 在發生 Full GC 時會嚴重影響效能。JEP 307 的目的就是要採用並行 GC 演算法，在發生 Full GC 時可以使用多個執行緒進行並行回收。

JEP 310 對類資料共享（CDS）進行了擴充套件，JVM 可以將一些類記錄到一個共享的壓縮檔案裡，在 JVM 下一次啟動時可以將這個檔案對映到 JVM 程序，以此來減少啟動時間。該檔案也可以在多個 JVM 間共享，在同一個機器上執行多個 JVM 時，這樣做可以減少記憶體佔用。

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

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

JEP 312 旨在改進虛擬機器效能，在應用程式執行緒上呼叫回撥不再需要執行全域性虛擬機器安全點操作，這意味著 JVM 可以停止單個執行緒。一些底層小改進包括：

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

• 減少訊號依賴以獲得更好的堆疊取樣。

• 通過停止單獨執行緒改進偏向鎖。

• 從 JVM 移除了一些記憶體屏障。

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