Java15來了!!!一文詳解JDK15新特性

2020年9月15號，Oracle正式發布了JDK15, 筆者第一時間了解了相關特性，在進行深入學習之后，值此元旦佳節前夕，特給大家獻上此文。此次Java15的新特性有哪些？Java自JDK8開始，你了解了哪些特性呢？對于JDK的發布，我們應該怎么去學習？讓我們一起來看看。

一、Java歷史簡談

1995 年 5 月，Sun Microsystems 公司發布了Java，一轉眼，今年是Java的25歲誕辰了。這25年間，Java已經發布和預期發布的版本如下圖：

可以看到，在Java8之前，Java的版本更新基本都是兩年一個新版本，而在Java9之后，也就是2017年9月，Java平臺的主架構師 Mark Reinhold 發出提議，要求將Java的功能更新周期從之前的每兩年一個新版本縮減到每六個月一個新版本。

Java 8 與 Java 11 為目前提供支持的LTS（長期支持）版本，2021年9月，Java17將會成為最新的LTS版；Oracle 官方表示，會在 2019 年 1 月前為商業用途中的 Java 8 長期支持，而針對非商用的更新將繼續提供，直至 2020 年 12 月；此外，AdoptOpenJDK 也為 Java 8 提供免費更新。針對 Java 11 的長期支持將不再由 Oracle 提供，而是改由?OpenJDK?社區的 AdoptOpenJDK 提供。

二、我們該如何學習Java新特性

在過去的這些年中，Java 在過去增強功能的推動下為用戶提供了超過二十年的創新。例如：

JDK 5:enum、泛型、自動裝箱與拆箱、可變參數、增強循環等

JDK 6:支持腳本語言、JDBC4.0API

JDK 7:支持try-with-resources、switch語句塊增加String支持、NIO2.0包

JDK 8:lambda表達式、Stream API、新的日期時間的API、方法引用、構造器引用

JDK 9:模塊化系統、jshell

JDK 10:局部變量的類型推斷

JDK 11:ZGC的引入、Epsilon GC

JDK 12:switch表達式、Shenandoah GC、增強G1

JDK 13:switch表達式引入yield、文本塊

JDK 14:instanceof模式識別、Records、棄用Parallel Scavenge+Serial GC組合、刪除CMS GC

Java8之后的新特性，估計很多人都沒怎么用過。那這些新特性有哪些可以應用的場景？Java新特性我們應該應該關注哪些點呢？筆者認為有以下三點比較重要：

角度一：語法層面

例如lambda表達式，switch，自動裝箱和拆箱、enum、接口中的靜態方法、默認方法、私有方法

角度二：API層面

例如Stream API、新的日期時間的API、Optional、String、集合框架

角度三：底層優化

例如JVM的優化、元空間、GC、GC的組合、GC的參數、js的執行引擎、集合底層的實現

這次發布的主要功能有：

對應中文特性：(JEP：JDK Enhancement Proposals，JDK 增強建議，也就是 JDK 的特性新增和改進提案。)

JEP 339：EdDSA 數字簽名算法

JEP 360：密封類（預覽）

JEP 371：隱藏類

JEP 372：移除 Nashorn JavaScript 引擎

JEP 373：重新實現 Legacy DatagramSocket API

JEP 374：禁用偏向鎖定

JEP 375：instanceof 模式匹配（第二次預覽）

JEP 377：ZGC：一個可擴展的低延遲垃圾收集器

JEP 378：文本塊

JEP 379：Shenandoah:低暫停時間垃圾收集器

JEP 381：移除 Solaris 和 SPARC 端口

JEP 383：外部存儲器訪問 API（第二次孵化版）

JEP 384：Records（第二次預覽）

JEP 385：廢棄 RMI 激活機制

我們可以看到，Java 15為用戶提供了14項主要的增強/更改，主要是對之前版本預覽特性的功能做了確定，如文本塊、ZGC等，包括一個孵化器模塊，三個預覽功能，兩個不推薦使用的功能以及兩個刪除功能。相對于Java14的16個新特性，包含的 JEP（Java/JDK Enhancement Proposals，JDK 增強提案）比 Java 12和 13 加起來的還要多，Java15可以說是平平無奇，讓人內心毫無波瀾。

從上圖我們還可以看到，一些features后面帶有preview字樣，還有一些帶有incubator字樣，這些即預覽和孵化器模塊：

? “孵化器模塊”：將尚未定稿的API和工具先交給開發者使用，以獲得反饋，并用這些反饋進一步改進Java平臺的質量。

? “預覽特性”：是規格已經成型、實現已經確定，但還未最終定稿的功能。它們出現在Java中的目的是收集在真實世界中使用后的反饋信息，促進這些功能的最終定

稿。這些特性可能會隨時改變，根據反饋結果，這些特性甚至可能會被移除，但通常所有預覽特性最后都會在Java中固定下來。

下面，就讓我們一起來學習一下此次Java15的超實用新特性吧！

三、Java15新特性詳解

在開始使用Java15新特性之前，我們應該先安裝好對應的JDK和開發工具，支持Java15的開發工具官網稱有以下三款：

? JetBrains IDEA

? Apache NetBeans

? Eclipse Marketplace

筆者常用的是idea，系統是win10，運行jdk15需要idea2020.02及以上版本才能支持，-如下：

JDK15下載路徑：

https://www.oracle.com/java/technologies/javase-jdk15-downloads.html

IDEA 2020.02版本-：

https://www.jetbrains.com/idea/download/#section=windows

考慮到大多數人電腦中還有使用Java8的必要，以及開發過程中jdk切換的便利性，安裝過程可以參考這篇文章：win10 64位系統中安裝多個jdk版本的切換問題

安裝完成之后，就讓我們一起來看看Java15新特性的使用吧。

1、主要的6個新特性：

特性一：密封類（語法層面）

JEP 360: Sealed Classes (Preview)

通過密封的類和接口來增強 Java 編程語言，這是新的預覽特性。

用于限制超類的使用，密封的類和接口限制其它可能繼承或實現它們的其它類或接口。

這個特性的目標包括——允許類或接口的開發者來控制哪些代碼負責實現，提供了比限制使用超類的訪問修飾符聲明方式更多選擇,并通過支持對模式的詳盡分析而支持模式匹配的未來發展。

在Java中，類層次結構通過繼承實現代碼的重用，父類的方法可以被許多子類繼承。

但是，類層次結構的目的并不總是重用代碼。有時，其目的是對域中存在的各種可能性進行建模，例如圖形庫支持的形狀類型或金融應用程序支持的貸款類型。當以這種方式使用類層次結構時，我們可能需要限制子類集從而來簡化建模。

具體使用：

因為我們引入了sealed class或interfaces，這些class或者interfaces只允許被指定的類或者interface進行擴展和實現。

使用修飾符sealed，您可以將一個類聲明為密封類。密封的類使用reserved關鍵字permits列出可以直接擴展它的類。子類可以是最終的，非密封的或密封的。

示例：

package com.example.geometry; abstract sealed class Shape permits Circle,Rectangle,Square{} final class Circle extends Shape {} non-sealed class Rectangle extends Shape {} sealed class Square extends Shape {} final class TransparentRectangle extends Square{};

可以看到：

① 在聲明為sealed的類Shape即為密封類，密封類必須有subclass，即子類;

② 密封類的子類可以為finall、non-sealed、sealed所修飾，如果子類也為sealed，則其也必須有子類。例如Shape的子類Square必須有子類TransparentRectangle；

③ permits修飾符是為了限制可以繼承該類的所有子類，例如上述Shape類，就只能被Circle,Rectangle,Square所繼承，而其他繼承它的類，IDE就會直接報錯；如果沒有permits修飾符，例如Square類，就可以被任意類所繼承。

特性二：instanceof 自動匹配模式（語法層面）

JEP 375：Pattern Matching for instanceof (Second Preview)

在Java 14中作為預覽語言功能引入的instanceof模式匹配，在Java 15中處于第二次預覽，而沒有任何更改。

模式匹配允許程序中的通用邏輯（主要是從對象中的條件提取組件）可以更簡潔地表達。Haskell 和 C# 等語言已采用模式匹配來實現簡潔和安全性。

例如，我們之前對比兩個對象是否同一類型，一般的寫法如下：

// 新特性之前 @Test public void test1() { Object o = new String("hello, java 15"); o = new School(); if (o instanceof String) { String str = (String) o; // 必須顯式的聲明強制類型轉換 System.out.println(str.contains("java")); } else { System.out.println("it is not string"); } }

而有了新特性之后，我們可以這么寫：

@Test public void test2() { Object o = new String("hello, java 15"); o = new School(); if (o instanceof String str) { // you do not need to convert type System.out.println(str.contains("java")); } else { System.out.println("it is not string"); } }

再比如，我們之前寫equals方法，對比兩個對象是否完全相同，現在可以這么寫：

class School { private String student; private String teacher; //新特性之前 @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof School)) return false; School school = (School) o; return student.equals(school.student) && teacher.equals(school.teacher); } //新特新之后 public boolean equal(Object o) { if (this == o) return true; return o instanceof School school && student.equals(school.student) && teacher.equals(school.teacher); } }

特性三：文本塊功能（語法層面）

JEP 378：Text Blocks

Text Blocks首次是在JDK 13中以預覽功能出現的，然后在JDK 14中又預覽了一次，終于在JDK 15中被確定下來，可放心使用了。

文本塊是一種多行字符串文字，它避免了大多數轉義序列的需要，以一種可預測的方式自動設置字符串的格式，并在需要時使開發人員可以控制格式，簡化編寫 Java 程序的任務。

文本塊建議的目標是提高 Java 程序中的字符串的可讀性，這些字符串表示以非 Java 語言編寫的代碼。

另一個目標是支持從字符串文本遷移，規定任何新構造都可以表達與字符串文本相同的字符串集，解釋相同的轉義序列，并且以與字符串文本相同的方式進行操作。OpenJDK 開發人員希望添加轉義序列來管理顯式空白和換行控件。

舉個栗子：

package com.shenzhi.belina.entity; import org.junit.jupiter.api.Test; public class TextBlocksTest { @Test public void test1() { String text1 = "The Sound of silence\n" + "Hello darkness , my old friend\n" + "I 've come to talk with you again\n"; System.out.println(text1); System.out.println(); // jdk13 String text = """ The Sound of silence Hello darkness , my old friend I 've come to talk with you again """; System.out.println(text); System.out.println(text1.length()); System.out.println(text.length()); } //html @Test public void test2(){ String html1 = "\n" + "\n" + " \n" + " \n" + "\n" + "\n" + "

hello,java

\n" + "\n" + ""; //jdk13中的新特性： String html2 = """

hello,java

"""; System.out.println(html1+html2); } //json @Test public void test3() { //jdk13之前的寫法 String myJson = "{\n" + " \"name\":\"Lee Hongbin\",\n" + " \"address\":\"lihongbin.io\",\n" + " \"email\":\"zooadmin@126.com\"\n" + "}"; StringBuilder filePath = new StringBuilder(); //jdk13的新特性 String myJson1 = """ { "name":"Lee Hongbin", "address":"lihongbin.io", "email":"zooadmin@126.com" }"""; System.out.println(myJson1); } //sql @Test public void test4(){ String sql = "SELECT id,NAME,email\n" + "FROM customers\n" + "WHERE id > 4\n" + "ORDER BY email DESC"; System.out.println(sql); //jdk13新特性： String sql1 = """ SELECT id,NAME,email FROM customers WHERE id > 4 ORDER BY email DESC """; System.out.println(); System.out.println(sql1); } //jdk14新特性 @Test public void test5(){ String sql1 = """ SELECT id,NAME,email FROM customers WHERE id > 4 ORDER BY email DESC """; System.out.println(sql1); // \:取消換行操作 // \s:表示一個空格 String sql2 = """ SELECT id,NAME,email \ FROM customers\s\ WHERE id > 4 \ ORDER BY email DESC\ """; String sql3 = """ select id,name,email \ from customers\s\ where id > 4\ order by emial \s desc """; System.out.println(sql2); System.out.println(sql3); System.out.println(sql2.length()); } }

具體的區別，各位讀者可以在運行代碼后細品，不再贅述。

特性四：Records（語法層面）

JEP 384：Records Class(Second Preview)

早在2019年2月份，Java 語言架構師 Brian Goetz，曾經寫過一篇文章，詳盡的說明了并吐槽了Java語言，他和很多程序員一樣抱怨“Java太啰嗦”或有太多的“繁文縟節”，他提到：開發人員想要創建純數據載體類（plain data carriers）通常都必須編寫大量低價值、重復的、容易出錯的代碼。如：構造函數、getter/setter、equals()、hashCode()以及toString()等。以至于很多人選擇使用IDE的功能來自動生成這些代碼。還有一些開發會選擇使用一些第三方類庫，如Lombok等來生成這些方法，從而會導致了令人吃驚的表現（surprisingbehavior）和糟糕的可調試性（poor debuggability）。

使用record來減少類聲明語法，效果類似 lombok 的 @Data 注解，Kotlin中的dataclass。它們的共同點是類的部分或全部狀態可以直接在類頭中描述，并且這個類中只包含了純數據而已。該預覽特性提供了一種更為緊湊的語法來聲明類。值得一提的是，該特性可以大幅減少定義類似數據類型時所需的樣板代碼。

Records Class 也是第二次出現的預覽功能，它在 JDK 14 中也出現過一次了，使用 Record 可以更方便的創建一個常量類，使用的前后代碼對比如下：

//使用record后 public record Customer(String name, Customer partner) {} //使用record前 class Customer { private final String name; private final Customer partner; public Customer(String name, Customer partner) { this.name = name; this.partner = partner; } public String getName() { return name; } public Customer getPartner() { return partner; } @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof Customer)) return false; Customer customer = (Customer) o; return Objects.equals(name, customer.name) && Objects.equals(partner, customer.partner); } @Override public int hashCode() { return Objects.hash(name, partner); } @Override public String toString() { return "Customer1{" + "name='" + name + '\'' + ", partner=" + partner + '}'; } }

當你用record 聲明一個類時，該類將自動擁有以下功能：

? 獲取成員變量的簡單方法。以上面代碼為例 name() 和 partner() ，我們可以通過運行下面的測試類來看看，注意區別于我們平常getter的寫法。

? 一個 equals 方法的實現，執行比較時會比較該類的所有成員屬性

? 重寫 equals 也重寫了 hashCode

? 一個可以打印該類所有成員屬性的 toString 方法。

? 請注意只會有一個構造方法。

測試類如下：

package com.shenzhi.belina.lambda; import ch.qos.logback.core.net.SyslogOutputStream; import com.shenzhi.belina.entity.Customer; import java.util.HashSet; public class CustomerTest { public static void main(String[] args) { Customer customer = new Customer("conan", new Customer("chan", null)); System.out.println(customer.toString()); System.out.println(customer.name()); // 類似于原有的實例變量的get方法 HashSet set = new HashSet<>(); // 驗證是否重寫了equals方法 Customer customer1 = new Customer("conan", new Customer("chan", null)); set.add(customer); set.add(customer1); set.forEach(System.out::println); } }

通過運行上面的測試類，我們就可以看到上述總結的知識點了，不再贅述。

和枚舉類型一樣，record也是類的一種受限形式。作為回報，記錄對象在簡潔性方面提供了顯著的好處。

? 我們還可以在Record聲明的類中定義靜態字段、靜態方法、構造器或實例方法。

? 不能在Record聲明的類中定義實例字段；類不能聲明為abstract；不能聲明顯式的父類等。

package com.shenzhi.belina.entity; public record Customer(String name, Customer partner) { // 小括號內定義成員變量 // 還可以聲明構造器，靜態的變量、方法、實例方法 public Customer(String name){ this(name,null); } public static String info; public void show(){ System.out.println("i am a singer , my name is "+ name()); } public static void shown(){ System.out.println("my name is belina"); } //不可以在record中定義實例變量 // public int id; private static Person person; public static int id; } //record不可以聲明為abstract; //abstract record Employee(){} //不可以顯示的繼承于其他類，因為本身已經繼承于record //record Employee() extends Thread{}

特性五：隱藏類（底層優化）

JEP 371:Hidden Classes

該提案通過啟用標準 API 來定義無法發現且具有有限生命周期的隱藏類，從而提高 JVM 上所有語言的效率。JDK內部和外部的框架將能夠動態生成類，而這些類可以定義隱藏類。通常來說基于JVM的很多語言都有動態生成類的機制，這樣可以提高語言的靈活性和效率。

隱藏類天生為框架設計的，在運行時生成內部的class。

隱藏類只能通過反射訪問，不能直接被其他類的字節碼訪問。

隱藏類可以獨立于其他類加載、卸載，這可以減少框架的內存占用。

Hidden Classes是什么呢？

Hidden Classes就是不能直接被其他class的二進制代碼使用的class。Hidden Classes主要被一些框架用來生成運行時類，但是這些類不是被用來直接使用的，而是通過反射機制來調用。

比如在JDK8中引入的lambda表達式，JVM并不會在編譯的時候將lambda表達式轉換成為專門的類，而是在運行時將相應的字節碼動態生成相應的類對象。

另外使用動態代理也可以為某些類生成新的動態類。

那么我們希望這些動態生成的類需要具有什么特性呢？

不可發現性。因為我們是為某些靜態的類動態生成的動態類，所以我們希望把這個動態生成的類看做是靜態類的一部分。所以我們不希望除了該靜態類之外的其他機制發現。

訪問控制。我們希望在訪問控制靜態類的同時，也能控制到動態生成的類。

生命周期。動態生成類的生命周期一般都比較短，我們并不需要將其保存和靜態類的生命周期一致。

API的支持

所以我們需要一些API來定義無法發現的且具有有限生命周期的隱藏類。這將提高所有基于JVM的語言實現的效率。

比如：

java.lang.reflect.Proxy可以定義隱藏類作為實現代理接口的代理類。

java.lang.invoke.StringConcatFactory可以生成隱藏類來保存常量連接方法；

java.lang.invoke.LambdaMetaFactory可以生成隱藏的nestmate類，以容納訪問封閉變量的lambda主體；

普通類是通過調用ClassLoader::defineClass創建的，而隱藏類是通過調用Lookup::defineHiddenClass創建的。這使JVM從提供的字節中派生一個隱藏類，鏈接該隱藏類，并返回提供對隱藏類的反射訪問的查找對象。調用程序可以通過返回的查找對象來獲取隱藏類的Class對象。

特性六：ZGC（底層優化）

JEP 377:ZGC: A Scalable Low-Latency Garbage Collector (Production)

ZGC是Java 11引入的新的垃圾收集器（JDK9以后默認的垃圾回收器是G1），經過了多個實驗階段，自此終于成為正式特性。

自 2018 年以來，ZGC 已增加了許多改進，從并發類卸載、取消使用未使用的內存、對類數據共享的支持到改進的 NUMA 感知。此外，最大堆大小從 4 TB 增加到 16 TB。支持的平臺包括 Linux、Windows 和 MacOS。

ZGC是一個重新設計的并發的垃圾回收器，通過減少 GC 停頓時間來提高性能。

但是這并不是替換默認的GC，默認的GC仍然還是G1；之前需要通過-XX:+UnlockExperimentalVMOptions -XX:+UseZGC來啟用ZGC，現在只需要-XX:+UseZGC就可以。相信不久的將來它必將成為默認的垃圾回收器。

相關的參數有ZAllocationSpikeTolerance、ZCollectionInterval、ZFragmentationLimit、ZMarkStackSpaceLimit、ZProactive、ZUncommit、ZUncommitDelay ZGC-specific JFR events(ZAllocationStall、ZPageAllocation、ZPageCacheFlush、ZRelocationSet、ZRelocationSetGroup、ZUncommit)也從experimental變為product

2、次要新特性

特性一：EdDSA 數字簽名算法（API層面）

JEP 339：Edwards-Curve Digital Signature Algorithm（EdDSA 數字簽名算法)

這是一個新的功能。

新加入基于Edwards-Curve數字簽名算法(EdDSA-Edwards-Curve Digital Signature Algorithm)的加密簽名，即愛德華茲曲線數字簽名算法。

在許多其它加密庫（如 OpenSSL 和 BoringSSL）中得到支持。

與 JDK 中的現有簽名方案相比，EdDSA 具有更高的安全性和性能，因此備受關注。它已經在OpenSSL和BoringSSL等加密庫中得到支持，在區塊鏈領域用的比較多。

EdDSA是一種現代的橢圓曲線方案，具有JDK中現有簽名方案的優點。EdDSA將只在SunEC提供商中實現。

特性二：重新實現 DatagramSocket API（API層面）

JEP 373:Reimplement the Legacy DatagramSocket API(重新實現 DatagramSocket API)

新的計劃是JEP 353的后續，該方案重新實現了遺留的套接字API。

java.net.datagram.Socket和java.net.MulticastSocket的當前實現可以追溯到JDK 1.0，那時IPv6還在開發中。因此，當前的多播套接字實現嘗試調和IPv4和IPv6難以維護的方式。

通過替換 java.net.datagram 的基礎實現，重新實現舊版 DatagramSocket API。

更改java.net.DatagramSocket 和 java.net.MulticastSocket 為更加簡單、現代化的底層實現。提高了 JDK 的可維護性和穩定性。

通過將java.net.datagram.Socket和java.net.MulticastSocket API的底層實現替換為更簡單、更現代的實現來重新實現遺留的DatagramSocket API。

新的實現：1.易于調試和維護;2.與Project Loom中正在探索的虛擬線程協同。

特性三：禁用偏向鎖定（底層優化）

JEP 374: Disable and Deprecate Biased Locking 禁用偏向鎖定

在默認情況下禁用偏向鎖定，并棄用所有相關命令行選項。目標是確定是否需要繼續支持偏置鎖定的高維護成本的遺留同步優化，HotSpot虛擬機使用該優化來減少非競爭鎖定的開銷。盡管某些Java應用程序在禁用偏向鎖后可能會出現性能下降，但偏向鎖的性能提高通常不像以前那么明顯。

該特性默認禁用了biased locking(-XX:+UseBiasedLocking)，并且廢棄了所有相關的命令行選型(BiasedLockingStartupDelay, BiasedLockingBulkRebiasThreshold, BiasedLockingBulkRevokeThreshold, BiasedLockingDecayTime, UseOptoBiasInlining, PrintBiasedLockingStatistics and PrintPreciseBiasedLockingStatistics)

特性四：Shenandoah 垃圾回收算法（底層優化）

Shenandoah垃圾回收算法終于從實驗特性轉變為產品特性，這是一個從 JDK 12 引入的回收算法，該算法通過與正在運行的 Java 線程同時進行疏散工作來減少 GC 暫停時間。Shenandoah 的暫停時間與堆大小無關，無論堆棧是 200 MB 還是 200 GB，都具有相同的一致暫停時間。

怎么形容Shenandoah和ZGC的關系呢？異同點大概如下：

相同點：性能幾乎可認為是相同的

不同點：ZGC是Oracle JDK的，根正苗紅。而Shenandoah只存在于OpenJDK中，因此使用時需注意你的JDK版本

打開方式：使用-XX:+UseShenandoahGC命令行參數打開。

Shenandoah在JDK12被作為experimental引入，在JDK15變為Production；之前需要通過-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC來啟用，現在只需要-XX:+UseShenandoahGC即可啟用

特性五：外部存儲器訪問 API（API層面）

JEP 383:Foreign-Memory Access API (Second Incubator) 外部存儲器訪問 API（孵化器版）

目的是引入一個 API，以允許 Java 程序安全、有效地訪問 Java 堆之外的外部存儲器。如本機、持久和托管堆。

有許多Java程序是訪問外部內存的，比如Ignite和MapDB。該API將有助于避免與垃圾收集相關的成本以及與跨進程共享內存以及通過將文件映射到內存來序列化和反序列化內存內容相關的不可預測性。該Java API目前沒有為訪問外部內存提供令人滿意的解決方案。但是在新的提議中，API不應該破壞JVM的安全性。

Foreign-Memory Access API在JDK14被作為incubating API引入，在JDK15處于Second Incubator，提供了改進。

特性六：移除 Solaris 和 SPARC 端口

JEP 381：Remove the Solaris and SPARC Ports (移除 Solaris 和 SPARC 端口)

刪除對Solaris/SPARC、Solaris/x64和Linux/SPARC端口的源代碼和構建支持，在JDK 14中被標記為廢棄，在JDK15版本正式移除。

許多正在開發的項目和功能（如Valhalla、Loom和Panama）需要進行重大更改以適應CPU架構和操作系統特定代碼。

近年來，Solaris 和 SPARC 都已被 Linux 操作系統和英特爾處理器取代。放棄對 Solaris 和 SPARC 端口的支持將使 OpenJDK 社區的貢獻者能夠加速開發新功能，從而推動平臺向前發展。

特性七：移除the Nashorn JS引擎

JEP 372：Remove the Nashorn JavaScript Engine

Nashorn是在JDK提出的腳本執行引擎，該功能是 2014 年 3 月發布的 JDK 8 的新特性。在JDK11就已經把它標記為廢棄了，JDK15完全移除。

在JDK11中取以代之的是GraalVM。GraalVM是一個運行時平臺，它支持Java和其他基于Java字節碼的語言，但也支持其他語言，如JavaScript，Ruby，Python或LLVM。性能是Nashorn的2倍以上。

JDK15移除了Nashorn JavaScript Engine及jjs 命令行工具。具體就是jdk.scripting.nashorn及jdk.scripting.nashorn.shell這兩個模塊被移除了。

補充：

Graal VM在HotSpot VM基礎上增強而成的跨語言全棧虛擬機，可以作為“任何語言”的運行平臺使用。語言包括：Java、Scala、Groovy、Kotlin；C、C++、JavaScript、Ruby、Python、R等

特性八：廢棄RMI 激活機制

JEP 385:Deprecate RMI Activation for Removal

RMI Activation被標記為Deprecate,將會在未來的版本中刪除。RMI激活機制是RMI中一個過時的部分，自Java 8以來一直是可選的而非必選項。RMI激活機制增加了持續的維護負擔。RMI的其他部分暫時不會被棄用。

在RMI系統中，我們使用延遲激活。延遲激活將激活對象推遲到客戶第一次使用（即第一次方法調用）之前。

既然RMI Activation這么好用，為什么要廢棄呢？

因為對于現代應用程序來說，分布式系統大部分都是基于Web的，web服務器已經解決了穿越防火墻，過濾請求，身份驗證和安全性的問題，并且也提供了很多延遲加載的技術。

所以在現代應用程序中，RMI Activation已經很少被使用到了。并且在各種開源的代碼庫中，也基本上找不到RMI Activation的使用代碼了。

為了減少RMI Activation的維護成本，在JDK8中，RMI Activation被置為可選的。現在在JDK15中，終于可以廢棄了。

3、次次要新特性

一：添加項

添加項

Support for Unicode 13.0 (JDK-8239383)

升級了Unicode，支持Unicode 13.0

Added isEmpty Default Method to CharSequence (JDK-8215401)

給CharSequence新增了isEmpty方法 java.base/java/lang/CharSequence.java

Specialized Implementations of TreeMap Methods (JDK-8176894)

JDK15對TreeMap提供了putIfAbsent, computeIfAbsent, computeIfPresent, compute, merge方法提供了overriding實現

New Option Added to jcmd for Writing a gzipped Heap Dump (JDK-8237354)

jcmd的GC.heap_dump命令現在支持gz選型，以dump出gzip壓縮版的heap；compression level從1(fastest)到9(slowest, but best compression)，默認為1

Added Support for SO_INCOMING_NAPI_ID Support (JDK-8243099)

jdk.net.ExtendedSocketOptions新增了SO_INCOMING_NAPI_ID選型

New System Properties to Configure the TLS Signature Schemes (JDK-8242141)

新增了jdk.tls.client.SignatureSchemes及jdk.tls.server.SignatureSchemes用于配置TLS Signature Schemes

Support for certificate_authorities Extension (JDK-8206925)

支持certificate_authorities的擴展

二：移除項&廢棄項

移除項

Obsolete -XX:UseAdaptiveGCBoundary (JDK-8228991)

淘汰了-XX:UseAdaptiveGCBoundary

廢棄項

Deprecated -XX:ForceNUMA Option (JDK-8243628)

廢棄了ForceNUMA選項

Disable Native SunEC Implementation by Default (JDK-8237219)

默認禁用了Native SunEC Implementation

三：其他事項

已知問題

java.net.HttpClient Does Not Override Protocols Specified in SSLContext Default Parameters (JDK-8239594)

HttpClient現在沒有覆蓋在SSLContext Default Parameters中指定的Protocols

其他事項

DatagramPacket.getPort() Returns 0 When the Port Is Not Set (JDK-8237890)

當DatagramPacket沒有設置port的時候，其getPort方法返回0

Improved Ergonomics for G1 Heap Region Size (JDK-8241670)

優化了默認G1 Heap Region Size的計算

4、下期預告和參考文獻

這篇文章從動筆到結束整整花了兩個星期，絮絮叨叨給大家講了這么多，喜歡你們能喜歡；接下來預計會再用兩篇文章，來詳細講講Java8到Java14的新特性，歡迎、關注、轉發、、評論喲，下期再見，比心！！！

由于筆者才疏學淺，創刊伊始，思慮不足，又限于資料來源有限，如有紕漏之處，敬請指正、補充！

參考資料鏈接：

OpenJDK

Java15新特性教程

Java版本歷史

軟件開發 Oracle Java

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。