摘要：目標發(fā)布目前有兩個主要功能針對局部變量類型推斷這將刪除大部分對象實例化所需的冗長的包含手動類型信息整合源樹的庫即不同的庫將被合并成一個單一的存儲庫。特別是，承諾為局部變量實例化引入類型推斷機制，并將現(xiàn)有的存儲庫合并到一個存儲庫中。

JDK 10 是 Java 10 標準版的部分實現(xiàn)，將于 2018 年 3 月 20 日發(fā)布，改進的關鍵點包括一個本地類型推斷、一個垃圾回收的“干凈”接口。
Oracle 已經(jīng)為 Java 設定了六個月的發(fā)行計劃。之前本打算根據(jù)發(fā)行的年份和月份命名升級版和后續(xù)版，這樣的話第一個版本就會被稱為 Java 18.3， 但這個計劃后來被中止了。
如何下載 JDK 10？
用戶要先加入早期使用者計劃，然后才可以下載 JDK 10 測試版

用戶要先加入早期使用者計劃，然后才可以下載 JDK 10 測試版

http://jdk.java.net/10/

OpenJDK https://download.java.net/java/jdk10/archive/45/GPL/openjdk-10+45_linux-x64_bin.tar.gz

Oracle JDK https://download.java.net/java/jdk10/archive/45/BCL/jdk-10+45_linux-x64_bin.tar.gz

一個局部變量類型推斷，通過增強語言特性將類型推斷擴展到局部變量，目的是減少與編碼相關的“儀式”，同時保持對靜態(tài)類型的安全承諾。

一個干凈的垃圾收集器接口，用來改善垃圾收集器源代碼之間的隔離效果，這樣可以為HotSpot 虛擬機中的內(nèi)部垃圾收集代碼提供更好的模塊化功能，也可以更容易向 HotSpot 添加新的垃圾收集器。

并行、完整的 G1 垃圾收集器，通過實現(xiàn)并行性來改善最壞情況下的延遲問題。

啟用 HotSpot 將對象堆分配給用戶指定的備用內(nèi)存設備（如 NVDIMM 內(nèi)存模塊），這個特性也側(cè)面預示了未來的系統(tǒng)可能會采用異構的內(nèi)存架構。

在 Linux / x64 平臺上以實驗性方式啟用基于 Java 的即時編譯器（https://www.infoworld.com/art...）。

將 JDK 的多個存儲庫合并成一個，簡化開發(fā)。目前的代碼庫被分解成了多個庫，容易出現(xiàn)源代碼的管理問題。

應用程序數(shù)據(jù)共享，通過跨進程共享通用類的元數(shù)據(jù)，減少空間占用及啟動時長。

線程本地握手，不執(zhí)行全局 VM 安全點也能對線程執(zhí)行回調(diào)，同時實現(xiàn)單線程停止回調(diào)。

JDK 提供了一組默認證書，開源 Java SE 的 CA程序，對開發(fā)人員更具吸引力。

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

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

局部變量類型推斷,這將刪除大部分對象實例化所需的冗長的包含手動類型信息

整合源樹source tree的JDK庫,即不同的JDK庫將被合并成一個單一的存儲庫。

1. 局部變量類型推斷

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

MyObject value = new MyObject();

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

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

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

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

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

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

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

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

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

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

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

2. 整合的JDK庫

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

root
corba
hotspot
jaxp
jaxws
JDK
langtools
nashorn

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

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

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

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

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

1 .清理垃圾收集接口

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

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

heap，CollectedHeap的子類

barrier set，BarrierSet的子類，它實現(xiàn)了運行時的各種障礙

一個CollectorPolicy的實現(xiàn)

GCInterpreterSupport的實現(xiàn)，它實現(xiàn)了解釋器的GC的各種障礙(使用匯編指令)

GCC1Support的實現(xiàn)，它為C1編譯器實現(xiàn)了GC的各種障礙

GCC2Support的實現(xiàn)，它為C2編譯器實現(xiàn)了GC的各種障礙

最終GC特定參數(shù)的初始化

設置MemoryService、相關的內(nèi)存池、內(nèi)存管理器等。

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

2. G1垃圾收集器并行化

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

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

3. 項目線程局部握手

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

結(jié)論

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

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

來源：CodeBay :http://codebay.cn/post/6349.html

作者：鵬磊

出處：http://www.ymq.io

版權歸作者所有，轉(zhuǎn)載請注明出處

Wechat：關注公眾號，搜云庫，專注于開發(fā)技術的研究與知識分享