[[339404]]

• 「MoreThanJava」 宣揚(yáng)的是 「學(xué)習(xí)，不止 CODE」，本系列 Java 基礎(chǔ)教程是自己在結(jié)合各方面的知識(shí)之后，對(duì) Java 基礎(chǔ)的一個(gè)總回顧，旨在 「幫助新朋友快速高質(zhì)量的學(xué)習(xí)」。
• 當(dāng)然 不論新老朋友 我相信您都可以 從中獲益。如果覺(jué)得 「不錯(cuò)」 的朋友，歡迎 「關(guān)注 + 留言 + 分享」，文末有完整的獲取鏈接，您的支持是我前進(jìn)的最大的動(dòng)力!

特性總覽

以下是 Java 10 中的引入的部分新特性。關(guān)于 Java 10 新特性更詳細(xì)的介紹可參考這里。

• 基于時(shí)間的發(fā)行版本控制(JEP 322)
• 局部變量類型推斷(JEP 286)
• 試驗(yàn)性 JIT 編譯器(JEP 317)
• 應(yīng)用程序類數(shù)據(jù)共享(JEP 310)
• 用于 G1 的并行 Full GC(JEP 307)
• 清理垃圾收集器接口(JEP 304)
• 其他 Unicode 語(yǔ)言標(biāo)簽擴(kuò)展(JEP 314)
• 根證書(shū)(JEP 319)
• 線程本地握手(JEP 312)
• 備用存儲(chǔ)設(shè)備上的堆分配(JEP 316)
• 刪除本機(jī)頭生成工具——javah(JEP 313)
• 將JDK森林合并到單個(gè)存儲(chǔ)庫(kù)中(JEP 296)
• API 變更

一. 基于時(shí)間的發(fā)行版本控制(JEP 322)

發(fā)行版本號(hào)的前世今生

自 Java 江山易主，JDK 發(fā)行版本的字符串命名方式一直是一個(gè)耐人尋味的話題。

單就下載 JDK 時(shí)，所看到的簡(jiǎn)短版本字符串形式來(lái)說(shuō)，在 7u40 版本之前，u 之后的數(shù)字，代表了 JDK 發(fā)布以來(lái)的第幾個(gè)修正版本，然而 Oracle 改變規(guī)則，為了彰顯出安全之類的重大 修補(bǔ)(Cirtical Patch Updates)版本，采用 奇數(shù) 命名，而 Bug 修復(fù)、API 修改之類的 維護(hù)版本，則采用 偶數(shù)。(另有版本號(hào) $MAJOR.$MINOR.$SECURITY 的格式來(lái)區(qū)分 Bug 修正和 API 修改)

為此，之前既有的 JDK 6/7 發(fā)布版本，還被重新命名。(下方演示)

   Actual                    Hypothetical 
Release Type           long               short 
------------           ------------------------  
Security 2013/06       1.7.0_25-b15       7u25 
Minor    2013/09       1.7.0_40-b43       7u40 
Security 2013/10       1.7.0_45-b18       7u45 
Security 2014/01       1.7.0_51-b13       7u51 
Minor    2014/05       1.7.0_60-b19       7u60 

就結(jié)論而言，重新命名之后，從 7u9、6u37 開(kāi)始，就可以從奇偶數(shù)來(lái)判別是否為重大修補(bǔ)版本;至于 7u40 之后的版本，重大修補(bǔ)版本 是基于 5 的倍數(shù)，遇偶數(shù)加一，而 維護(hù)版本則會(huì)是 20 的倍數(shù)。如此(不直觀)的命名方式，被規(guī)范在了 JEP223 中。(隨著 JDK 9 一起發(fā)布的)

然而，自 JDK 8 發(fā)布之后，Oracle 的 Java 架構(gòu)師 Mark Reinhold 就希望，未來(lái) Java 發(fā)布可以基于時(shí)間，以半年為周期，持續(xù)發(fā)布新版本，讓一些有用的小特性，也能被開(kāi)發(fā)者使用，因此，JEP 223 的規(guī)范就不再適用了，而在 JDK 9 發(fā)布后，他們針對(duì)新版本曾經(jīng)提出過(guò)基于$YEAR.$MONTH 格式，然而收到了社區(qū)極大的反對(duì)，為此，還提出了三個(gè)替代方案，收集各方的意見(jiàn)。(https://goo.gl/7CA8B3)

那么，Java 下一個(gè)特性版本是 8.3?1803?還是 10?調(diào)查結(jié)果顯示，社群大多數(shù)都支持10，Stephen Colebourne 也發(fā)出請(qǐng)求(https://goo.gl/i5J44T)，并表示 Java 不像 Ubuntu 這類操作系統(tǒng)，基于 $YEAR.$MONTH 并不合適。

最終，Oracle 采用了 $FEATURE.$INTERIM.$UPDATE.$PATCH 這樣的方案，并規(guī)定在了 JEP 322 中。

JEP 322 新模式解讀

通過(guò)采用基于時(shí)間的發(fā)行周期，Oracle 更改了 Java SE 平臺(tái)和 JDK 的版本字符串方案以及相關(guān)的版本信息，以適用于當(dāng)前和將來(lái)的基于時(shí)間的發(fā)行模型。

版本號(hào)的新模式是：

$FEATURE.$INTERIM.$UPDATE.$PATCH

• $ FEATURE：計(jì)數(shù)器將每 6 個(gè)月遞增一次，并基于功能發(fā)布版本，例如：JDK 10，JDK 11。
• $ INTERIM：對(duì)于包含兼容錯(cuò)誤修復(fù)和增強(qiáng)功能但沒(méi)有不兼容更改的非功能版本，計(jì)數(shù)器將增加。通常，這將是零，因?yàn)榱鶄€(gè)月內(nèi)不會(huì)有任何臨時(shí)發(fā)布。這保留了對(duì)發(fā)布模型的將來(lái)修訂。
• $ UPDATE：計(jì)數(shù)器將增加，用于解決安全問(wèn)題，回歸和較新功能中的錯(cuò)誤的兼容更新版本。此功能會(huì)在功能發(fā)布后一個(gè)月更新，此后每三個(gè)月更新一次。2018 年 4 月版本是 JDK 10.0.1，7 月版本是 JDK 10.0.2，依此類推
• $ PATCH：計(jì)數(shù)器將增加以用于緊急釋放以解決嚴(yán)重問(wèn)題。

并添加了新的 API 以通過(guò)編程的方式獲取這些計(jì)數(shù)器：

Version version = Runtime.version(); 
version.feature(); 
version.interim(); 
version.update(); 
version.patch(); 

現(xiàn)在，讓我們來(lái)看一下返回版本信息的 Java 啟動(dòng)器：

$ java -version 
java version "10" 2018-03-20 
Java(TM) SE Runtime Environment 18.3 (build 10+46) 
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode) 

版本號(hào)格式為 10，因?yàn)闆](méi)有其他計(jì)數(shù)器為零。發(fā)布日期已添加?？梢詫?18.3 理解為 Year 2018&3rd Month，版本 10 + 46 是版本 10 的 46 版本。對(duì)于 JDK 10.0.1 的假設(shè)版本93，版本將為 10.0.1 + 93。

因此，對(duì)于 Java 9 來(lái)說(shuō)，目前可以看到的版本，會(huì)是 9.0.4 這樣的格式，至于 2018 年 3 月發(fā)布的特性版本為 10，到了 9 月提供的新版本，就是 11，JDK 11 預(yù)計(jì)會(huì)是長(zhǎng)期支援版本，所以，在版本字串上，也會(huì)特別顯示 LTS(long-term support)。

二. 局部變量類型推斷(JEP 286)

概述

JDK 10 中最明顯的增強(qiáng)功能之一是使用初始化程序?qū)植孔兞窟M(jìn)行類型推斷。

在 Java 9 之前，我們必須明確寫(xiě)出局部變量的類型，并確保它與用于初始化它的初始化程序兼容：

String message = "Good bye, Java 9"; 

在 Java 10 中，這是我們可以聲明局部變量的方式：

@Test 
public void whenVarInitWithString_thenGetStringTypeVar() { 
    var message = "Hello, Java 10"; 
    assertTrue(message instanceof String); 
} 

我們沒(méi)有提供 message 的具體類型，相反，我們把 message 標(biāo)記為了 var，編譯器將從右側(cè)的初始化程序的類型推斷出 message 的類型。(上面的例子中 message 為 String 類型)

請(qǐng)注意，此功能僅適用于帶有初始化程序的局部變量。它不能用于成員變量、方法參數(shù)、返回類型等——初始化程序是必須的，否則，編譯器無(wú)法推斷出其類型。

這個(gè)功能有助于我們減少樣板式的代碼，例如：

Map<Integer, String> map = new HashMap<>(); 

現(xiàn)在可以改寫(xiě)為：

var idToNameMap = new HashMap<Integer, String>(); 

這也有助于我們把重點(diǎn)放在變量名，而不是變量類型上。

要注意的另一件事是 var 不是關(guān)鍵字——這確保了使用 var 作為函數(shù)或變量名的程序的向后兼容性。var 是一個(gè)保留類型名，就像 int 一樣。

最后，使用 var 不會(huì)增加運(yùn)行時(shí)的開(kāi)銷，也不會(huì)使 Java 稱為動(dòng)態(tài)類型的語(yǔ)言。變量的類型仍然是在編譯時(shí)進(jìn)行判斷，以后也無(wú)法更改。

非法使用 var 的情況解析

1、如果沒(méi)有初始化程序，var 將無(wú)法工作：

var n; // error: cannot use 'var' on variable without initializer 

2、如果將其初始化為 null，也不會(huì)起作用：

var emptyList = null; // error: variable initializer is 'null' 

3、不適用于非局部變量：

public var word = "hello"; // error: 'var' is not allowed here 

4、Lambda 表達(dá)式需要顯式的類型，因此無(wú)法使用 var：

var p = (String s) -> s.length() > 10; // error: lambda expression needs an explicit target-type 

5、數(shù)組初始化程序也不支持：

var arr = { 1, 2, 3 }; // error: array initializer needs an explicit target-type 

使用 var 的準(zhǔn)則

在某些情況下，我們可以合法使用 var，但這樣做并不是一個(gè)好主意。

例如，在代碼的可讀性降低的情況下：

var result = obj.prcoess(); 

在這里，盡管可以合法使用 var，但很難理解 process() 返回的類型，從而讓代碼的可讀性降低。

java.net(OpenJDK 官網(wǎng))上專門(mén)有一篇文章介紹了 Java 中的局部變量類型推斷的書(shū)寫(xiě)準(zhǔn)則，該文章討論了在使用此功能時(shí)應(yīng)該注意的姿勢(shì)和如何使用的一些良好建議。

另外，最好避免使用 var 的另一種情況是在流水線較長(zhǎng)的流中：

var x = emp.getProjects.stream() 
  .findFirst() 
  .map(String::length) 
  .orElse(0); 

另外，將 var 與不可引用類型一起使用可能會(huì)導(dǎo)致意外錯(cuò)誤。

比如，如果我們將 var 與匿名類實(shí)例一起使用：

@Test 
public void whenVarInitWithAnonymous_thenGetAnonymousType() { 
    var obj = new Object() {}; 
    assertFalse(obj.getClass().equals(Object.class)); 
} 

現(xiàn)在，如果我們嘗試將另一個(gè) Object 分配給 obj，則會(huì)出現(xiàn)編譯錯(cuò)誤：

obj = new Object(); // error: Object cannot be converted to <anonymous Object> 

這是因?yàn)?obj 的推斷類型不是 Object。

三. 試驗(yàn)性 JIT 編譯器(JEP 317)

Graal 是用Java編寫(xiě)的，與 HotSpot JVM 集成的動(dòng)態(tài)編譯器。它專注于高性能和可擴(kuò)展性。它也是 JDK 9 中引入的實(shí)驗(yàn)性 Ahead-of-Time(AOT)編譯器的基礎(chǔ)。

JDK 10 使 Graal 編譯器可以用作 Linux / x64 平臺(tái)上的實(shí)驗(yàn)性 JIT 編譯器。

要將 Graal 用作 JIT 編譯器，請(qǐng)?jiān)?Java 命令行上使用以下選項(xiàng)：

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler 

請(qǐng)注意，這是一個(gè)實(shí)驗(yàn)性功能，我們不一定會(huì)獲得比現(xiàn)有JIT編譯器更好的性能。

想要了解更多內(nèi)容的童鞋請(qǐng)參考 Chris Seaton 的演講：https://chrisseaton.com/truffleruby/jokerconf17/

(ps：長(zhǎng)文 + 特別底層警告..)

四. 應(yīng)用程序類數(shù)據(jù)共享(JEP 310)

JDK 5 中引入的類數(shù)據(jù)共享允許將一組類預(yù)處理成共享的歸檔文件，然后在運(yùn)行時(shí)對(duì)其進(jìn)行內(nèi)存映射，以減少啟動(dòng)時(shí)間，這還可以在多個(gè) JVM 共享相同的歸檔文件時(shí)減少動(dòng)態(tài)內(nèi)存占用。

CDS 只允許引導(dǎo)類裝入器，將該特性限制為系統(tǒng)類。應(yīng)用程序 CDS (AppCDS)擴(kuò)展了 CDS 以允許內(nèi)置的系統(tǒng)類裝入器。內(nèi)置的平臺(tái)類裝入器和用于裝入歸檔類的自定義類裝入器。這使得對(duì)應(yīng)用程序類使用該特性成為可能。

我們可以使用以下步驟來(lái)使用這個(gè)功能：

1、獲取要存檔的類列表

以下命令會(huì)將HelloWorld 應(yīng)用程序加載的類轉(zhuǎn)儲(chǔ)到hello.lst中：

$ java -Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=hello.lst \  
    -cp hello.jar HelloWorld 

2、創(chuàng)建 AppCDS 存檔

以下命令使用hello.lst 作為輸入創(chuàng)建hello.js a ：

$ java -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=hello.lst \ 
    -XX:SharedArchiveFile=hello.jsa -cp hello.jar 

3、使用 AppCDS 存檔

以下命令以hello.jsa 作為輸入啟動(dòng)HelloWorld 應(yīng)用程序：

$ java -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=hello.jsa \ 
    -cp hello.jar HelloWorld 

AppCDS 是用于 JDK 8 和 JDK 9 的 Oracle JDK 中的一項(xiàng)商業(yè)功能?，F(xiàn)在它是開(kāi)源的，并且可以公開(kāi)使用。

五. 用于 G1 的并行 Full GC(JEP 307)

G1 垃圾收集器是自 JDK 9 以來(lái)的默認(rèn)垃圾收集器。但是，G1 的 Full GC 使用了單線程的 mark-sweep-compact 算法。

它已 更改為 Java 10 中 的并行mark-sweep-compact算法 ，有效地減少了 Full GC 期間的停滯時(shí)間。

六. 清理垃圾收集器接口(JEP 304)

這個(gè) JEP 是未來(lái)的變化。通過(guò)引入公共垃圾收集器接口，它改善了不同垃圾收集器的代碼隔離。

次更改為內(nèi)部 GC 代碼提供了更好的模塊化。將來(lái)將有助于在不更改現(xiàn)有代碼庫(kù)的情況下添加新 GC，還有助于刪除或保留以前的 GC。

官方的動(dòng)機(jī)解釋： (傳送門(mén))

當(dāng)前，每個(gè)垃圾收集器實(shí)現(xiàn)都由其 src/hotspot/share/gc/$NAME 目錄內(nèi)的源文件組成，例如 G1 在中 src/hotspot/share/gc/g1，CMS 在 src/hotspot/share/gc/cms 等中。但是，在 HotSpot 中散布著一些零散的信息。例如，大多數(shù) GC 需要某些障礙，這些障礙需要在運(yùn)行時(shí)，解釋器 C1 和 C2 中實(shí)現(xiàn)。這些障礙并不包含在 GC 的具體目錄，但在共享解釋器，而不是實(shí)施，C1 和 C2 的源代碼(通常由長(zhǎng)守衛(wèi)if- else-chains)。同樣的問(wèn)題也適用于診斷代碼，例如 MemoryMXBeans。此源代碼布局有幾個(gè)缺點(diǎn)：

對(duì)于GC開(kāi)發(fā)人員，實(shí)施新的垃圾收集器需要有關(guān)所有這些地方的知識(shí)，以及如何擴(kuò)展它們以滿足其特定需求的知識(shí)。

對(duì)于不是 GC 開(kāi)發(fā)人員的 HotSpot 開(kāi)發(fā)人員，在哪里為給定 GC 找到特定的代碼段會(huì)造成混亂。

在構(gòu)建時(shí)很難排除特定的垃圾收集器。該#define INCLUD E_ALL_GCS長(zhǎng)期以來(lái)建立與唯一內(nèi)置串行收集JVM的一種方式，但這種機(jī)制變得過(guò)于呆板。

較干凈的 GC 接口將使實(shí)現(xiàn)新的收集器更加容易，使代碼更加清潔，并且在構(gòu)建時(shí)排除一個(gè)或多個(gè)收集器也更加容易。添加一個(gè)新的垃圾收集器應(yīng)該是實(shí)現(xiàn)一組有據(jù)可查的接口，而不是弄清 HotSpot 中所有需要更改的地方。

七. 其他Unicode語(yǔ)言標(biāo)簽擴(kuò)展(JEP 314)

此功能增強(qiáng)了 java.util.Locale 和相關(guān) API，以實(shí)現(xiàn) BCP 47 語(yǔ)言標(biāo)簽的其他 Unicode 擴(kuò)展。從 Java SE 9 開(kāi)始，受支持的 BCP 47 U 語(yǔ)言擴(kuò)展名是 "ca" 和 "nu"。該 JEP 將增加對(duì)以下附加擴(kuò)展的支持：

• cu(貨幣類型)
• fw(一周的第一天)
• rg(區(qū)域覆蓋)
• tz(時(shí)區(qū))

為了支持這些附加擴(kuò)展，對(duì)以下各種 API 進(jìn)行了更改以提供基于 U 或附加擴(kuò)展的信息：

java.text.DateFormat::get*Instance 
java.text.DateFormatSymbols::getInstance 
java.text.DecimalFormatSymbols::getInstance 
java.text.NumberFormat::get*Instance 
java.time.format.DateTimeFormatter::localizedBy 
java.time.format.DateTimeFormatterBuilder::getLocalizedDateTimePattern 
java.time.format.DecimalStyle::of 
java.time.temporal.WeekFields::of 
java.util.Calendar::{getFirstDayOfWeek,getMinimalDaysInWeek} 
java.util.Currency::getInstance 
java.util.Locale::getDisplayName 
java.util.spi.LocaleNameProvider 

八. 根證書(shū)(JEP 319)

cacerts 密鑰庫(kù)(迄今為止到目前為止是空的)旨在包含一組根證書(shū)，這些根證書(shū)可用于建立對(duì)各種安全協(xié)議所使用的證書(shū)鏈的信任。

結(jié)果，在 OpenJDK 構(gòu)建中，諸如 TLS 之類的關(guān)鍵安全組件默認(rèn)情況下不起作用。

借助 Java 10，Oracle 將 Oracle Java SE Root CA 程序中 的根證書(shū)開(kāi)源了 ，以使 OpenJDK 構(gòu)建對(duì)開(kāi)發(fā)人員更具吸引力，并減少了這些構(gòu)建與 Oracle JDK 構(gòu)建之間的差異。

九. 線程本地握手(JEP 312)

這是用于提高 JVM 性能的內(nèi)部特性。

握手操作是在線程處于安全點(diǎn)狀態(tài)時(shí)為每個(gè) JavaThread 執(zhí)行的回調(diào)?；卣{(diào)由線程本身或 VM 線程執(zhí)行，同時(shí)保持線程處于阻塞狀態(tài)。

這個(gè)特性提供了一種無(wú)需執(zhí)行全局 VM 安全點(diǎn)即可在線程上執(zhí)行回調(diào)的方法。使停止單個(gè)線程，而不是停止所有線程或不停止線程成為可能，而且代價(jià)低廉。

十. 備用存儲(chǔ)設(shè)備上的堆分配(JEP 316)

應(yīng)用程序的內(nèi)存消耗越來(lái)越大，本地云應(yīng)用程序、內(nèi)存中的數(shù)據(jù)庫(kù)、流應(yīng)用程序都在增加。為了滿足這些服務(wù)，有各種可用的內(nèi)存架構(gòu)。這個(gè)特性增強(qiáng)了 HotSpot VM 在用戶指定的備用內(nèi)存設(shè)備(比如NV-DIMM)上分配 Java 對(duì)象堆的能力。

這個(gè) JEP 的目標(biāo)是具有與 DRAM 相同語(yǔ)義(包括原子操作的語(yǔ)義)的可選內(nèi)存設(shè)備，因此，可以在不更改現(xiàn)有應(yīng)用程序代碼的情況下，將其用于對(duì)象堆，而不是用于 DRAM。

十一. 刪除本機(jī)頭生成工具—javah (JEP 313)

這是一個(gè)從 JDK 中刪除 javah 工具的常規(guī)更改。工具功能是作為 JDK 8 的一部分在 javac中添加的，它提供了在編譯時(shí)編寫(xiě)使 javah 無(wú)用的本機(jī)頭文件的能力。

十二. 將JDK森林合并到單個(gè)存儲(chǔ)庫(kù)中(JEP 296)

多年來(lái)，有各種各樣的 Mercurial 存儲(chǔ)庫(kù)用于 JDK 代碼基。不同的存儲(chǔ)庫(kù)確實(shí)提供了一些優(yōu)勢(shì)，但它們也有各種操作上的缺點(diǎn)。作為這個(gè)變化的一部分，JDK 森林的許多存儲(chǔ)庫(kù)被合并到一個(gè)存儲(chǔ)庫(kù)中，以簡(jiǎn)化和簡(jiǎn)化開(kāi)發(fā)。

十三. API 變更

Java 10 添加和刪除了 API。Java 9 引入了增強(qiáng)的棄用，其中某些 API 被標(biāo)記為將在未來(lái)的版本中刪除。

于是這些 API 被刪除了：你可以在 這里 找到被刪除的 API。

新增API: Java 10 中新增 73 個(gè)API。您可以在 這里 找到添加的 API 并進(jìn)行比較。

讓我們來(lái)看看對(duì)我們直接有用的部分。

不可修改集合的改進(jìn)

Java 10 中有一些與不可修改集合相關(guān)的更改

copyOf()

java.util.List、java.util.Map 和 java.util.Set 都有了一個(gè)新的靜態(tài)方法 copyOf(Collection)。

它返回給定 Collection 的不可修改的副本：

jshell> var originList = new ArrayList<String>(); 
originList ==> [] 
 
jshell> originList.add("歡迎關(guān)注公眾號(hào)："); 
$2 ==> true 
 
jshell> originList.add("我沒(méi)有三顆心臟"); 
$3 ==> true 
 
jshell> var copyList = List.copyOf(originList) 
copyList ==> [歡迎關(guān)注公眾號(hào)：, 我沒(méi)有三顆心臟] 
 
jshell> originList.add("獲取更多精彩內(nèi)容") 
$5 ==> true 
 
jshell> System.out.println(copyList) 
[歡迎關(guān)注公眾號(hào)：, 我沒(méi)有三顆心臟] 
 
jshell> copyList.add("獲取更多精彩內(nèi)容") 
|  異常錯(cuò)誤 java.lang.UnsupportedOperationException 
|        at ImmutableCollections.uoe (ImmutableCollections.java:73) 
|        at ImmutableCollections$AbstractImmutableCollection.add (ImmutableCollections.java:77) 
|        at (#7:1) 
 
jshell> 

toUnmodifiable()

java.util.Collectors 獲得其他方法來(lái)將 Stream 收集到不可修改的 List、Map 或 Set 中：

@Test(expected = UnsupportedOperationException.class) 
public void whenModifyToUnmodifiableList_thenThrowsException() { 
    List<Integer> evenList = someIntList.stream() 
      .filter(i -> i % 2 == 0) 
      .collect(Collectors.toUnmodifiableList()); 
    evenList.add(4); 
} 

任何嘗試修改此類集合的嘗試都會(huì)導(dǎo)致 java.lang.UnsupportedOperationException 運(yùn)行時(shí)異常。

Optinal 新增方法 orElseThrow()

java.util.Optional，java.util.OptionalDouble，java.util.OptionalInt 和 java.util.OptionalLong 都有一個(gè)新方法 orElseThrow()，它不接受任何參數(shù)，如果不存在任何值，則拋出 NoSuchElementException：

@Test 
public void whenListContainsInteger_OrElseThrowReturnsInteger() { 
    Integer firstEven = someIntList.stream() 
      .filter(i -> i % 2 == 0) 
      .findFirst() 
      .orElseThrow(); 
    is(firstEven).equals(Integer.valueOf(2)); 
} 

它與現(xiàn)有的 get() 方法同義，并且現(xiàn)在是它的首選替代方法。

參考資料

• OpenJDK 官方說(shuō)明 - http://openjdk.java.net/projects/jdk/10/
• Java 10 Features | JournalDev - https://www.journaldev.com/20395/java-10-features
• 想跳舞的 Java | 林信良 - https://www.ithome.com.tw/voice/122249
• Java 10 Performance Improvements | Baeldung - https://www.baeldung.com/java-10-performance-improvements

本文轉(zhuǎn)載自微信公眾號(hào)「 我沒(méi)有三顆心臟」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 我沒(méi)有三顆心臟公眾號(hào)。