JDK 10 是 Java 10 標準版的部分實現,將於 2018 年 3 月 20 日發佈,改進的關鍵點包括一個本地類型推斷、一個垃圾回收的「乾淨」接口。
Oracle 已經爲 Java 設定了六個月的發行計劃。以前本打算根據發行的年份和月份命名升級版和後續版,這樣的話第一個版本就會被稱爲 Java 18.3, 但這個計劃後來被停止了。
如何下載 JDK 10?
用戶要先加入早期使用者計劃,而後才能夠下載 JDK 10 測試版html
用戶要先加入早期使用者計劃,而後才能夠下載 JDK 10 測試版java
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安全
一個局部變量類型推斷,經過加強語言特性將類型推斷擴展到局部變量,目的是減小與編碼相關的「儀式」,同時保持對靜態類型的安全承諾。架構
一個乾淨的垃圾收集器接口,用來改善垃圾收集器源代碼之間的隔離效果,這樣能夠爲HotSpot 虛擬機中的內部垃圾收集代碼提供更好的模塊化功能,也能夠更容易向 HotSpot 添加新的垃圾收集器。oracle
並行、完整的 G1 垃圾收集器,經過實現並行性來改善最壞狀況下的延遲問題。app
啓用 HotSpot 將對象堆分配給用戶指定的備用內存設備(如 NVDIMM 內存模塊),這個特性也側面預示了將來的系統可能會採用異構的內存架構。編程語言
在 Linux / x64 平臺上以實驗性方式啓用基於 Java 的即時編譯器(https://www.infoworld.com/art...)。模塊化
將 JDK 的多個存儲庫合併成一個,簡化開發。目前的代碼庫被分解成了多個庫,容易出現源代碼的管理問題。
應用程序數據共享,經過跨進程共享通用類的元數據,減小空間佔用及啓動時長。
線程本地握手,不執行全局 VM 安全點也能對線程執行回調,同時實現單線程中止回調。
JDK 提供了一組默認證書,開源 Java SE 的 CA程序,對開發人員更具吸引力。
與以前的JDK版本同樣,對於即將到來的JDK 10也有一些主要特性。這些特性能夠分爲兩個主要類別:(1)目標發佈,(2)建議發佈。前者表示某些特性已計劃在JDK 10中發佈,後一種類型表示這些特性還須要增長支持和成熟度。一旦條件容許,它就能夠升級爲一個目標發佈狀態。
目前有兩個主要功能針對JDK 10:
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<MyObject>();
可是,當這個過程重複出現大量任務時,對象實例化可能變得使人沮喪和乏味。許多最流行的強類型的編程語言,好比C++, C#以及Go,在定義過程當中,提供一種局部變量類型推斷的功能(例如C++提供了auto 關鍵字,C#提供var關鍵字)。可是,Java仍缺少這樣的功能,它要求開發人員顯式聲明變量的預期清單類型。
爲了解決這個問題,Java開發工具包(JDK)改進建議(JEP)286提出了一個上下文敏感的關鍵字var,容許局部變量被如下方式初始化:
var value = new MyObject(); var list = new ArrayList<MyObject>();
因爲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執行將負責提供如下內容:
有關這些更改的更多信息,請參見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時間軸上的一個重要里程碑。
來源:CodeBay :http://codebay.cn/post/6349.html