摘要：的問題在于，版本號中編碼了它和它對之前版本的兼容性信息。但是在六個月節(jié)奏的情況下，這些信息都是未知的，在發(fā)布前任何事情都可能發(fā)生，由此規(guī)范下的版本號也會是未知的。程序會對文件的完整性做一個保護(hù)，因此修改既可能丟失。

本文是對底部參考資料的整理得到的，由于本人技術(shù)水平和英語水平都不是很高，有些詞如有翻譯錯誤或句子的理解錯誤還請指出。

傳統(tǒng)的 Java 代碼中，聲明一個變量是非常繁瑣的：

List list = new ArrayList();

現(xiàn)在則引入了 var，既保持 Java 對靜態(tài)類型安全的承諾，又能讓開發(fā)者省略不必要的局部變量類型的聲明。

比如像這樣：

var list = new ArrayList();

var 只能用在以下情況：

聲明的同時賦值，比如上面那個例子

增強(qiáng)的 for 循環(huán)中的索引 （這將在后面提到）

傳統(tǒng) for 循環(huán)中聲明的本地變量

它不能被用于方法簽名、構(gòu)造器聲明、方法返回類型、字段、異常捕獲或任何其他類型的變量聲明。

類型推斷在 Java 8 中已經(jīng)得到了顯著的擴(kuò)展，包括了對嵌套和鏈接的泛型方法的推導(dǎo)以及 lambda 表達(dá)式的推導(dǎo)，比如下面這樣：

int maxWeight = blocks.stream()
                    .filter(b -> b.getColor() == BLUE)
                    .mapToInt(Block::getWeight)
                    .max();

沒有必要去在意 blocks.stream*() 返回的是 Stream，也不用在意 filter 中 lambda 表達(dá)式的參數(shù)類型沒有被顯式聲明，因為它們都能通過類型推導(dǎo)得到。

對于局部類型變量，類型推導(dǎo)是非常有用的，因為通常情況下都可以寫成下面這種代碼：

var path = Paths.get(fileName);
var bytes = Files.readAllBytes(path);

但是要注意的是，var 并不是一個關(guān)鍵字，而是一個保留的類型名稱，這意味著你可以將一個變量、方法、包名寫成 var 。不過一般情況下不會有人這么寫的，因為這本身就違反了普遍的命名規(guī)范。

var 不能用來聲明沒有賦值的變量、不能用于聲明多個變量的情況、不能聲明具有額外緯度的數(shù)組或引用了正在初始化的其他變量的變量。

JEP 223 引入的版本號方案相比之前的方法都要好很多，但是對于現(xiàn)在 Java 所走的 六個月節(jié)奏 并不適合。

JEP 223 的問題在于，版本號中編碼了它和它對之前版本的兼容性信息。但是在 六個月節(jié)奏 的情況下，這些信息都是未知的，在發(fā)布前任何事情都可能發(fā)生，由此 JEP 223 規(guī)范下的版本號也會是未知的。

在 JEP 223 的語義中，每個基于 JDK 構(gòu)建或使用組件的開發(fā)者（包括 JDK 的發(fā)布者）都必須提前敲定版本號，然后切換過去。而庫、框架和工具的開發(fā)者則必須在代碼中修改檢查版本號的相關(guān)代碼，這造成了混亂。

更多關(guān)于 JEP 322 的詳細(xì)情況請訪問這里。

此次更新中為 Optional 類添加了一個新的方法，這個方法與 orElseThrow(exSupplier) 是不同的，它沒有參數(shù)。

Optional.get() 是一個容易誤導(dǎo)程序員的方法，它實際上有可能拋出 NoSuchElementException 運(yùn)行時異常，因此需要一個語義明確的方法來幫助程序員清楚的認(rèn)識到自己在做什么。

在之前的規(guī)劃中，Optional.getWhenPresent() 是一個備選方法，雖然這個名字強(qiáng)調(diào)了值一定會存在，但是其中的 when 似乎會讓人覺得這是個阻塞方法。因此最后委員會選擇了 Optional.orElseThrow()，但是 Optional.get() 并沒有被單純得棄用。

增強(qiáng)了 java.util.Locale 和相關(guān) API 以實現(xiàn)關(guān)于 BCP 47 語言標(biāo)簽 的 Unicode 擴(kuò)展。

詳情請訪問這里

新的 API 中包括了一些用于創(chuàng)建不可見集合的方法：

List.copyOf、Set.copyOf 和 Map.copyOf() 可以用來從已有的集合中創(chuàng)建一個新的集合；

toUnmodifiableList、toUnmodifiableSet 和 toUnmodifiableMap 則存在于 Stream.Collectors 類中，通過它們可以將流的元素收集到一個不可變集合當(dāng)中。

copyOf 系列的方法簽名基本是下面這樣：

static  List  copyOf (Collection  coll)

Set 和 Map 也會有類似的方法。

值得注意的是，這個方法會檢測 coll 是不是一個 不可變 的集合，如果是，則會直接返回該引用，相當(dāng)于一個淺拷貝。

另外對于不可變集合而言，下面這種情況是被允許的：

List  list = List.of(...);
List  newList = List.copyOf(list);

這對于可變集合而言是不允許的，因為這可能會導(dǎo)致堆污染。

引入了新的 jdk.disableLastUsageTracking 屬性以禁用 JVM 的 JRE 上次使用情況追蹤 功能。

如果使用了此屬性，那么 com.oracle.usagetracker.track.last.usage 的設(shè)置將被忽略。

在以前，JMX 存儲的是明文密碼，當(dāng)時 (2014 年) 大家已經(jīng)開始手動生成散列密碼來替換明文密碼，因為這可以避免一些攻擊，同時鹽 (salt) 的存在可以讓散列密碼的強(qiáng)度更上一層。但是對于管理員而言，即使是使用諸如 Python 之類的腳本語言來生成散列密碼，這仍然是極容易出錯的。因此最好的辦法是用戶只需要提供明文密碼，讓 JMX 來處理散列之類的事情。

JMX 現(xiàn)在會使用密碼的 SHA3-512 散列結(jié)果來覆蓋存儲在 jmxremote.password 中的明文密碼。

其格式如下：

role_name W hashedPassword

其中:

role_name 是任何不含空格或制表符的字符串

W 是一個空格或制表符

散列密碼的格式如下：

hashedPassword = base64_encoded_64_byte_salt W base64_encoded_hash W hash_algorithm

其中:

base64_encoded_64_byte_salt 是 64字節(jié)的隨機(jī)值

base64_encoded_hash 是 Hash_algorithm(password + salt) 的結(jié)果

W 是一個空格或制表符

hash_algorithm 是列表 中指定的算法名稱。這是個可選項，默認(rèn)值為 SHA3-512

如果密碼是明文的，且滿足以下條件，那么將被散列值覆蓋

management.properties 文件中 com.sun.management.jmxremote.password.toHashes 屬性被設(shè)為 true

密碼文件是可寫的

安全管理器處于打開狀態(tài)的情況下系統(tǒng)安全策略允許對密碼文件進(jìn)行寫入

如果想更改角色的密碼，可以將舊的散列密碼替換為新的明文密碼或新的散列密碼。如果新的密碼是明文的，那么在新的登錄發(fā)生時系統(tǒng)會使用其散列值替換明文密碼。

文件中的角色應(yīng)該至少有一條記錄，否則該角色將無權(quán)訪問；如果同一個用戶下有多條記錄，那么會使用最后一條記錄。

用戶可以自行根據(jù)上述的格式來生成的散列值，以替換舊的密碼。

文件被擁有者以外的用戶訪問時將導(dǎo)致錯誤并退出程序。

為了防止在生產(chǎn)環(huán)境中對密碼文件進(jìn)行了無意的編輯，建議只部署可讀的散列密碼文件。明文密碼的散列密碼列表可以用 JMX 代理預(yù)先生成。

在 JMX 運(yùn)行期間，建議不要編輯密碼文件。程序會對文件的完整性做一個保護(hù)，因此修改既可能丟失。

G1 垃圾收集器就是為了避免 完全 GC (full collections) , 但是當(dāng)并行收集無法快速回收內(nèi)存時，會產(chǎn)生一次 完全回退 GC (fall back full GC) 。

之前 G1 的 完全GC 使用的是單線程標(biāo)記掃描壓縮算法（mark-sweep-compact），現(xiàn)在通過 JEP 307，完全GC 得以并行化，同時現(xiàn)在會使用與 年輕代 、混合收集 相同的并行工作線程數(shù)量。

OpenJDK 中的 cacerts 密鑰庫在相當(dāng)長一段時間內(nèi)是空的，這將導(dǎo)致未指定 javax.net.ssl.trustStore 屬性的情況下 TLS 連接 的創(chuàng)建會被阻止?，F(xiàn)在Oracle 的 Java SE 根證書 被填充至 OpenJDK 的 cacerts 中。

在是一個對 RFC 7627 的支持。

如果出現(xiàn)兼容問題，可以將 jdk.tls.useExtendedMasterSecret 設(shè)置為 false 來禁用此擴(kuò)展的協(xié)商。

如果 jdk.tls.allowLegacyResumption 值為 false，當(dāng)會話散列和主密鑰擴(kuò)展未協(xié)商的情況下，程序可以拒絕簡短握手。

如果 jdk.tls.allowLegacyMasterSecret 值為 false，應(yīng)用將拒絕不支持此擴(kuò)展的連接。

之前的 for 循環(huán)在遍歷一個大的列表/數(shù)組時，它會隱式得持有一個臨時引用，而且這個臨時引用不會被釋放以至于可能產(chǎn)生 OutOfMemoryError 異常，詳細(xì)的情況可以查看這里。

對于下面的 Java 代碼：

List data = new ArrayList<>();
for (String b : data);

將會被編譯為：

{
    /*synthetic*/
    Iterator i$ = data.iterator();
    for (; i$.hasNext(); ) {
        String b = (String) i$.next();
    }
    b = null;
    i$ = null;
}

這意味著 GC 可以發(fā)現(xiàn)不再被使用的 i$ 所占用的內(nèi)存并回收它，這對于數(shù)組也是適用的。

新的 javadoc 命令行選項 --add-stylesheet ，它支持在生產(chǎn)的文檔中使用多個樣式表。

而現(xiàn)有的選項 -stylesheetfile 有了一個別名 stylesheetfile --main-stylesheet，用以區(qū)分主樣式表和其他樣式表，更多信息可以查看 javadoc 文檔。

默認(rèn)情況下，如果有方法覆寫了超類中的方法，那么 javadoc 會為它生成文檔。

但是如果一個方法只是被覆寫但是沒有改變語義行為時，javadoc 只會在原方法摘要中用 @inheritdoc 標(biāo)記它。

現(xiàn)在新的選項 --overridden-methods=value 可以將許多 不改變規(guī)范的覆寫方法 與其他繼承而來的方法分組，而不是在類的聲明中與其他方法一起被記錄在文檔中。

{@summary ...} 是一個新的行內(nèi)標(biāo)記。默認(rèn)情況下，會通過簡單算法或 java.text.BreakIterator 對描述中的第一句話進(jìn)行判斷以確定 API 描述內(nèi)容的摘要，但是這種方法可能會對第一句話結(jié)尾有錯誤的判斷，因此新的標(biāo)簽可以顯式得指定 API 的描述摘要。

參考資料

JDK 10 Release Notes
Java SE 10 (18.3) (?JSR 383) Final Release Specification
JEP 286 Local-Variable Type Inference
JEP 322: Time-Based Release Versioning
JEP 314: Additional Unicode Language-Tag Extensions
JDK-8140281 : (opt) add no-arg orElseThrow() as preferred alternative to get()
JDK-8177290 : add copy factory methods for unmodifiable List, Set, Map
JDK-5016517 : Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent
JDK-8172890 : JEP 307: Parallel Full GC for G1
JDK-8189131 : Open-source the Oracle JDK Root Certificates
JDK-8148421 : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
JDK-8175883 : bytecode generated for the enhanced for loop may block memory garbage collecting
JDK-8185371 : Support for multiple stylesheets in javadoc
JDK-8157000 : Do not generate javadoc for overridden method with no spec change
JDK-8173425 : Javadoc needs a new tag to specify the summary.