無版本代號(hào)， 2020-03-17 發(fā)布。
特性：(還未來得及研究每個(gè)新特性，無法確認(rèn)是功能的屬性)
無版本代號(hào)， 2019-09-17 發(fā)布。
特性：
無版本代號(hào)， 2019-03-19 發(fā)布。
特性：
無版本代號(hào)， 2018-09-25 發(fā)布。
特性：
無版本代號(hào)， 2018-03-20 發(fā)布。
特性：
無版本代號(hào)， 2017-09-21 發(fā)布。
特性：
版本代號(hào)為 Spider(蜘蛛)， 2014-03-18 發(fā)布, major.minor 版本為 52
特性：
版本代號(hào)為 Dolphin(海豚)， 2011-07-28 發(fā)布, major.minor 版本為 51
特性：
reference-jdk7
版本代號(hào)為 Mustang(野馬)， 2006-12-11 發(fā)布, major.minor 版本為 50
特性：
版本代號(hào)為 Tiger(老虎)， 2004-09-30 發(fā)布, major.minor 版本為 49。從 JDK5 開始， JDK 的版本不再以 1.x 的方式來命名了， 而是直接用 x 來命名。
特性：
版本代號(hào)為 Merlin(隼)， 2004-02-06 發(fā)布(首次在 JCP 下發(fā)行), major.minor 版本為 48
特性：
版本代號(hào)為 Kestrel(紅隼)， 2000-05-08 發(fā)布, major.minor 版本為 47
特性：
版本代號(hào)為 Playground(操場(chǎng))， 1998-12-08 發(fā)布, major.minor 版本為 46
特性：
無版本代號(hào), 1997-02-19 發(fā)布, major.minor 版本為 45
特性：
版本代號(hào)為 Oak(橡樹)， 1996-01-23 發(fā)布
主要特性：
以下是 Java 10 中的引入的部分新特性。關(guān)于 Java 10 新特性更詳細(xì)的介紹可參考這里。
自 Java 江山易主，JDK 發(fā)行版本的字符串命名方式一直是一個(gè)耐人尋味的話題。
單就下載 JDK 時(shí)，所看到的簡短版本字符串形式來說，在7u40 版本之前，u 之后的數(shù)字，代表了 JDK 發(fā)布以來的第幾個(gè)修正版本，然而 Oracle 改變規(guī)則，為了彰顯出安全之類的重大 修補(bǔ)（Cirtical Patch Updates）版本，采用 奇數(shù)命名，而 Bug 修復(fù)、API 修改之類的 維護(hù)版本，則采用 偶數(shù)。（另有版本號(hào) $MAJOR.$MINOR.$SECURITY 的格式來區(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 開始，就可以從奇偶數(shù)來判別是否為重大修補(bǔ)版本；至于 7u40 之后的版本，重大修補(bǔ)版本 是基于 5 的倍數(shù)，遇偶數(shù)加一，而 維護(hù)版本 則會(huì)是 20 的倍數(shù)。如此（不直觀）的命名方式，被規(guī)范在了 JEP223 中。（隨著 JDK 9 一起發(fā)布的）
然而，自 JDK 8 發(fā)布之后，Oracle 的 Java 架構(gòu)師 Mark Reinhold 就希望，未來 Java 發(fā)布可以基于時(shí)間，以半年為周期，持續(xù)發(fā)布新版本，讓一些有用的小特性，也能被開發(fā)者使用，因此，JEP 223 的規(guī)范就不再適用了，而在 JDK 9 發(fā)布后，他們針對(duì)新版本曾經(jīng)提出過基于 $YEAR.$MONTH 格式，然而收到了社區(qū)極大的反對(duì)，為此，還提出了三個(gè)替代方案，收集各方的意見。（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 中。
通過采用基于時(shí)間的發(fā)行周期，Oracle 更改了 Java SE 平臺(tái)和 JDK 的版本字符串方案以及相關(guān)的版本信息，以適用于當(dāng)前和將來的基于時(shí)間的發(fā)行模型。
版本號(hào)的新模式是：
$FEATURE.$INTERIM.$UPDATE.$PATCH
并添加了新的 API 以通過編程的方式獲取這些計(jì)數(shù)器：
Version version=Runtime.version();
version.feature();
version.interim();
version.update();
version.patch();
現(xiàn)在，讓我們來看一下返回版本信息的 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)闆]有其他計(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 來說，目前可以看到的版本，會(huì)是 9.0.4 這樣的格式，至于 2018 年 3 月發(fā)布的特性版本為 10，到了 9 月提供的新版本，就是 11，JDK 11 預(yù)計(jì)會(huì)是長期支援版本，所以，在版本字串上，也會(huì)特別顯示 LTS（long-term support）。
JDK 10 中最明顯的增強(qiáng)功能之一是使用初始化程序?qū)植孔兞窟M(jìn)行類型推斷。
在 Java 9 之前，我們必須明確寫出局部變量的類型，并確保它與用于初始化它的初始化程序兼容：
String message="Good bye, Java 9";
在 Java 10 中，這是我們可以聲明局部變量的方式：
@Test
public void whenVarInitWithString_thenGetStringTypeVar() {
var message="Hello, Java 10";
assertTrue(message instanceof String);
}
我們沒有提供 message 的具體類型，相反，我們把 message 標(biāo)記為了 var，編譯器將從右側(cè)的初始化程序的類型推斷出 message 的類型。（上面的例子中 message 為 String 類型）
請(qǐng)注意，此功能僅適用于帶有初始化程序的局部變量。它不能用于成員變量、方法參數(shù)、返回類型等——初始化程序是必須的，否則，編譯器無法推斷出其類型。
這個(gè)功能有助于我們減少樣板式的代碼，例如：
Map<Integer, String> map=new HashMap<>();
現(xiàn)在可以改寫為：
var idToNameMap=new HashMap<Integer, String>();
這也有助于我們把重點(diǎn)放在變量名，而不是變量類型上。
要注意的另一件事是 var 不是關(guān)鍵字——這確保了使用 var 作為函數(shù)或變量名的程序的向后兼容性。var 是一個(gè)保留類型名，就像 int 一樣。
最后，使用 var 不會(huì)增加運(yùn)行時(shí)的開銷，也不會(huì)使 Java 稱為動(dòng)態(tài)類型的語言。變量的類型仍然是在編譯時(shí)進(jìn)行判斷，以后也無法更改。
1、如果沒有初始化程序，var 將無法工作：
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á)式需要顯式的類型，因此無法使用 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，但這樣做并不是一個(gè)好主意。
例如，在代碼的可讀性降低的情況下：
var result=obj.prcoess();
在這里，盡管可以合法使用 var，但很難理解 process() 返回的類型，從而讓代碼的可讀性降低。
java.net(OpenJDK 官網(wǎng))上專門有一篇文章介紹了 Java 中的局部變量類型推斷的書寫準(zhǔn)則，該文章討論了在使用此功能時(shí)應(yīng)該注意的姿勢(shì)和如何使用的一些良好建議。
另外，最好避免使用 var 的另一種情況是在流水線較長的流中：
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。
Graal 是用Java編寫的，與 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：長文 + 特別底層警告..）
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)用程序類使用該特性成為可能。
我們可以使用以下步驟來使用這個(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è)功能。現(xiàn)在它是開源的，并且可以公開使用。
G1 垃圾收集器是自 JDK 9 以來的默認(rèn)垃圾收集器。但是，G1 的 Full GC 使用了單線程的 mark-sweep-compact 算法。
它已 更改為 Java 10 中 的并行mark-sweep-compact算法 ，有效地減少了 Full GC 期間的停滯時(shí)間。
這個(gè) JEP 是未來的變化。通過引入公共垃圾收集器接口，它改善了不同垃圾收集器的代碼隔離。
次更改為內(nèi)部 GC 代碼提供了更好的模塊化。將來將有助于在不更改現(xiàn)有代碼庫的情況下添加新 GC，還有助于刪除或保留以前的 GC。
官方的動(dòng)機(jī)解釋： （傳送門）
當(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 的源代碼（通常由長守衛(wèi)if- else-chains）。同樣的問題也適用于診斷代碼，例如 MemoryMXBeans。此源代碼布局有幾個(gè)缺點(diǎn)：
對(duì)于GC開發(fā)人員，實(shí)施新的垃圾收集器需要有關(guān)所有這些地方的知識(shí)，以及如何擴(kuò)展它們以滿足其特定需求的知識(shí)。對(duì)于不是 GC 開發(fā)人員的 HotSpot 開發(fā)人員，在哪里為給定 GC 找到特定的代碼段會(huì)造成混亂。在構(gòu)建時(shí)很難排除特定的垃圾收集器。該#define INCLUD E_ALL_GCS長期以來建立與唯一內(nèi)置串行收集JVM的一種方式，但這種機(jī)制變得過于呆板。
較干凈的 GC 接口將使實(shí)現(xiàn)新的收集器更加容易，使代碼更加清潔，并且在構(gòu)建時(shí)排除一個(gè)或多個(gè)收集器也更加容易。添加一個(gè)新的垃圾收集器應(yīng)該是實(shí)現(xiàn)一組有據(jù)可查的接口，而不是弄清 HotSpot 中所有需要更改的地方。
此功能增強(qiáng)了 java.util.Locale 和相關(guān) API，以實(shí)現(xiàn) BCP 47 語言標(biāo)簽的其他 Unicode 擴(kuò)展。從 Java SE 9 開始，受支持的 BCP 47 U 語言擴(kuò)展名是 "ca" 和 "nu"。該 JEP 將增加對(duì)以下附加擴(kuò)展的支持：
為了支持這些附加擴(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
cacerts 密鑰庫（迄今為止到目前為止是空的）旨在包含一組根證書，這些根證書可用于建立對(duì)各種安全協(xié)議所使用的證書鏈的信任。
結(jié)果，在 OpenJDK 構(gòu)建中，諸如 TLS 之類的關(guān)鍵安全組件默認(rèn)情況下不起作用。
借助 Java 10，Oracle 將 Oracle Java SE Root CA 程序中 的根證書開源了 ，以使 OpenJDK 構(gòu)建對(duì)開發(fā)人員更具吸引力，并減少了這些構(gòu)建與 Oracle JDK 構(gòu)建之間的差異。
這是用于提高 JVM 性能的內(nèi)部特性。
握手操作是在線程處于安全點(diǎn)狀態(tài)時(shí)為每個(gè) JavaThread 執(zhí)行的回調(diào)。回調(diào)由線程本身或 VM 線程執(zhí)行，同時(shí)保持線程處于阻塞狀態(tài)。
這個(gè)特性提供了一種無需執(zhí)行全局 VM 安全點(diǎn)即可在線程上執(zhí)行回調(diào)的方法。使停止單個(gè)線程，而不是停止所有線程或不停止線程成為可能，而且代價(jià)低廉。
應(yīng)用程序的內(nèi)存消耗越來越大，本地云應(yīng)用程序、內(nèi)存中的數(shù)據(jù)庫、流應(yīng)用程序都在增加。為了滿足這些服務(wù)，有各種可用的內(nèi)存架構(gòu)。這個(gè)特性增強(qiáng)了 HotSpot VM 在用戶指定的備用內(nèi)存設(shè)備(比如NV-DIMM)上分配 Java 對(duì)象堆的能力。
這個(gè) JEP 的目標(biāo)是具有與 DRAM 相同語義(包括原子操作的語義)的可選內(nèi)存設(shè)備，因此，可以在不更改現(xiàn)有應(yīng)用程序代碼的情況下，將其用于對(duì)象堆，而不是用于 DRAM。
這是一個(gè)從 JDK 中刪除 javah 工具的常規(guī)更改。工具功能是作為 JDK 8 的一部分在 javac 中添加的，它提供了在編譯時(shí)編寫使 javah 無用的本機(jī)頭文件的能力。
多年來，有各種各樣的 Mercurial 存儲(chǔ)庫用于 JDK 代碼基。不同的存儲(chǔ)庫確實(shí)提供了一些優(yōu)勢(shì)，但它們也有各種操作上的缺點(diǎn)。作為這個(gè)變化的一部分，JDK 森林的許多存儲(chǔ)庫被合并到一個(gè)存儲(chǔ)庫中，以簡化和簡化開發(fā)。
Java 10 添加和刪除了 API。Java 9 引入了增強(qiáng)的棄用，其中某些 API 被標(biāo)記為將在未來的版本中刪除。
于是這些 API 被刪除了：你可以在 這里 找到被刪除的 API。
新增API: Java 10 中新增 73 個(gè)API。您可以在 這里 找到添加的 API 并進(jìn)行比較。
讓我們來看看對(duì)我們直接有用的部分。
Java 10 中有一些與不可修改集合相關(guān)的更改
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("我沒有三顆心臟");
$3==> true
jshell> var copyList=List.copyOf(originList)
copyList==> [歡迎關(guān)注公眾號(hào)：, 我沒有三顆心臟]
jshell> originList.add("獲取更多精彩內(nèi)容")
$5==> true
jshell> System.out.println(copyList)
[歡迎關(guān)注公眾號(hào)：, 我沒有三顆心臟]
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>
java.util.Collectors 獲得其他方法來將 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í)異常。
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)在是它的首選替代方法。