蘇州2018年JAVA發(fā)展前景?

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

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

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

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

InfoQ 先前曾報(bào)道了 Java 10 中的主要特性，一會(huì)也會(huì)再說。此后，該版本中添加特性的僅是一些細(xì)微的（Additional Unicode Extensions）、清理性質(zhì)的（移除了原生的頭部生成工具，提供默認(rèn)的 CA 根證書）、實(shí)驗(yàn)性質(zhì)的（基于 Java 的 JIT 編譯器 Graal），或是當(dāng)前為利基性質(zhì)的 (對(duì)異構(gòu)內(nèi)存架構(gòu)的支持)。

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

• Epsilon。一種對(duì) Null 垃圾回收算法的參考實(shí)現(xiàn)。

• Dynamic Class File Constants 。一種主要針對(duì)軟件庫(kù)編寫人員及使用動(dòng)態(tài)特性 invokedynamic 高級(jí)開發(fā)人員的平臺(tái)特性。

• 運(yùn)行時(shí)追蹤 JIT 編譯事件。

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

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

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

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

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

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

與上面兩個(gè)特性都相關(guān)的是，未來可能對(duì) Switch 形式做改進(jìn)。Switch 語句塊將可作為表達(dá)式或聲明使用。

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

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

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

新的特性和增強(qiáng)一般** Java Enhancement Process（JEP）或 Java Community Process 標(biāo)準(zhǔn)請(qǐng)求（JSR）進(jìn)行跟蹤。因?yàn)?Java 10 的時(shí)間線較短，范圍也相對(duì)較小，所以 Java 10 的變更將** JEP 進(jìn)行跟蹤。

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

• 286：本地變量類型推斷

• 296：統(tǒng)一 JDK 倉(cāng)庫(kù)

• 304：垃圾回收器接口

• 307：G1 的并行 Full GC

• 310：應(yīng)用程序類數(shù)據(jù)共享

• 312：ThreadLocal 握手機(jī)制

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

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

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

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

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

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

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

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

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

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

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

• 降低堆棧跟蹤取樣所帶來的影響（如進(jìn)行 profiling）。

• 減少信號(hào)依賴以獲得更好的堆棧取樣。

• **停止單獨(dú)線程改進(jìn)偏向鎖。

• 從 JVM 移除了一些內(nèi)存屏障。

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