欢乐颂,有声读物

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

Java10新特性解密，引入類型推斷機制

隨著Java開發(fā)工具包(JDK)9的發(fā)布，大量的注意力都集中在Java的最新特性上，包括引入模塊(通過集成項目Jigsaw)。盡管最近的很多關(guān)注都集中在這些強大的新功能上，但下一個版本的Java:JDK 10已經(jīng)開始準備了。在本文中，我們將粗略地介紹一下JDK 10的主要特性，并探討JDK 10中可能包含的一些特性。

創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司一直秉承“誠信做人，踏實做事”的原則，不欺瞞客戶，是我們最起碼的底線！以服務(wù)為基礎(chǔ)，以質(zhì)量求生存，以技術(shù)求發(fā)展，成交一個客戶多一個朋友！專注中小微企業(yè)官網(wǎng)定制，網(wǎng)站建設(shè)、網(wǎng)站制作，塑造企業(yè)網(wǎng)絡(luò)形象打造互聯(lián)網(wǎng)企業(yè)效應(yīng)。

請注意，本文中所包含的信息在寫本文時是準確的。但是到發(fā)布時，JDK 10特性組預計將會增加。

新功能

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

目標發(fā)布

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

局部變量類型推斷,這將刪除大部分對象實例化所需的冗長的包含手動類型信息
整合源樹source tree的JDK庫,即不同的JDK庫將被合并成一個單一的存儲庫。

1. 局部變量類型推斷

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

 
 
 
 
  
  
  
  MyObject value = new MyObject();

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

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

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

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

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

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

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

考慮到所有的限制和細微差別，這個特性將有助于在開發(fā)人員創(chuàng)建的應(yī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存儲庫中。這種合并的一個次生效應(yīng)是，這個單一的Mercurial存儲庫比現(xiàn)有的8個存儲庫要更容易的被鏡像(作為一個Git存儲庫)。

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

建議發(fā)布

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

1 .清理垃圾收集接口

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

JEP 304被設(shè)計為解決此問題的方案，并建議整合并清理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ù)的初始化
設(shè)置MemoryService、相關(guān)的內(nèi)存池、內(nèi)存管理器等。

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

2. G1垃圾收集器并行化

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

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

3. 項目線程局部握手

當前，停止Java線程是一個“全部或沒有”的過程，需要一個Java虛擬機(JVM)的安全點，以使一個線程停止。為了讓單獨的線程停止，JEP 312提議將回調(diào)包含到線程中。這一更改受到了限制，因為它顯著地提高了現(xiàn)有JVM功能的性能開銷，并且改變了到達JVM全局安全點的現(xiàn)有時間語義。有關(guā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時間軸上的一個重要里程碑。

網(wǎng)站名稱：Java10新特性解密，引入類型推斷機制
網(wǎng)頁路徑：http://www.fisionsoft.com.cn/article/djhgpgo.html

新聞中心

其他資訊