關(guān)于JDK15的一些事

點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”

優(yōu)質(zhì)文章，第一時(shí)間送達(dá)

? 作者?|? 學(xué)海無涯519

來源 |? urlify.cn/EfA7bm

76套java從入門到精通實(shí)戰(zhàn)課程分享

一、為什么要了解JDK15？

　　2020年9月15日，Oracle官方發(fā)布了JDK15版本，及時(shí)關(guān)注官方的更新動(dòng)態(tài)，可以讓我們?cè)谌粘ｉ_發(fā)中更合理的選擇更加優(yōu)秀的工具方法，避免使用一些過時(shí)的或一些即將被刪除類和方法，保障程序的健壯性、穩(wěn)定性、可移植性。

二、JDK15都為我們帶來了哪些東西？

• JEP 339：Edwards-Curve 數(shù)字簽名算法（EdDSA）

• JEP 360：密封類（預(yù)覽）

• JEP 371：隱藏類

• JEP 372：刪除Nashorn JavaScript引擎

• JEP 373：重新實(shí)現(xiàn)舊版DatagramSocket API

• JEP 374：禁用和棄用偏置鎖定

• JEP 375：instanceof的模式匹配（第二預(yù)覽）

• JEP 377：ZGC：可擴(kuò)展的低延遲垃圾收集器

• JEP 378：文字塊

• JEP 379：Shenandoah：低暫停時(shí)間的垃圾收集器

• JEP 381：刪除Solaris和SPARC端口

• JEP 383：外部存儲(chǔ)器訪問API（第二個(gè)孵化器）

• JEP 384：Records（第二預(yù)覽）

• JEP 385：棄用RMI激活以進(jìn)行刪除

JEP：JDK Enhancement Proposals ，JDK 特性的新增和修改建議。

三、具體說一說JDK15的特性。

1. JEP 339：Edwards-Curve 數(shù)字簽名算法（EdDSA）

官方描述：

　　EdDSA是一種現(xiàn)代的橢圓曲線簽名方案，與JDK中的現(xiàn)有簽名方案相比，具有多個(gè)優(yōu)點(diǎn)。

• 在相同的安全強(qiáng)度下，開發(fā)比現(xiàn)有的ECDSA實(shí)現(xiàn)（使用本機(jī)C代碼）更好的性能的EdDSA平臺(tái)無關(guān)的實(shí)現(xiàn)。例如，在安全性?126位時(shí)使用Curve25519的EdDSA應(yīng)該與在安全性?128位時(shí)使用曲線secp256r1的ECDSA一樣快。

• 假設(shè)平臺(tái)在恒定時(shí)間內(nèi)執(zhí)行64位整數(shù)加/乘，請(qǐng)確保時(shí)序與秘密無關(guān)。另外，該實(shí)現(xiàn)將不會(huì)基于秘密分支。這些屬性對(duì)于防止側(cè)通道攻擊非常有用。

簡(jiǎn)而言之：

　　Edwards-Curve 數(shù)字簽名算法（EdDSA）實(shí)現(xiàn)加密簽名功能。且比現(xiàn)有的JDK 中的簽名安全性和性能更高。

2. JEP 360：密封類（預(yù)覽）

官方描述：

　　通過密封的類和接口增強(qiáng)Java編程語(yǔ)言。密封的類和接口限制可以擴(kuò)展或?qū)崿F(xiàn)它們的其他類或接口。通過將sealed修飾符應(yīng)用于其聲明來密封類。然后，在anyextends和implements子句之后，該permits子句指定允許擴(kuò)展密封類的類。

簡(jiǎn)而言之：

　　?限定接口的實(shí)現(xiàn)或子類，不是所有的類都能繼承此類或?qū)崿F(xiàn)此類。

注意：

• sealed：隱含子類 permits : 許可證

• non-sealed：隱含非受限子類

• final：隱含無子類

• 每個(gè)允許的子類都只能使用修飾符 final ，sealed和non-sealed中的一個(gè)，且三者互斥。

代碼實(shí)現(xiàn)：

//?創(chuàng)建Person?密封類
public?abstract?sealed?class?Person?permits?Student,?Teacher,?Doctor{

}

//?學(xué)生類繼承人類
non-sealed?class?Student?extends?Person{?}

//?老師類繼承人類
final?class?Teacher?extends?Person{?}

//?醫(yī)生類繼承人類
sealed?class?Doctor?extends?Person?permits?OutpDoctor,?InpatDoctor{?}

//?門診醫(yī)生繼承人類
final?class?OutpDoctor?extends?Doctor{?}

//?住院醫(yī)生繼承人類
non-sealed?class?InpatDoctor?extends?Doctor{?}

//?方法類型描述
public?sealed?interface?MethodTypeDesc?permits?DynamicConstantDesc,?MethodTypeDescImpl?{}

//?方法類型描述實(shí)現(xiàn)
final?class?MethodTypeDescImpl?implements?MethodTypeDesc?{?}

//?動(dòng)態(tài)約束描述
non-sealed?class?DynamicConstantDesc?implements?MethodTypeDesc?{}

3. JEP 371：隱藏類

官方描述：

　　隱藏類是其他類的字節(jié)碼不能直接使用的類。隱藏類適用于在運(yùn)行時(shí)生成類并通過反射間接使用它們的框架。隱藏類可以定義為訪問控制嵌套的成員，并且可以獨(dú)立于其他類進(jìn)行卸載。

簡(jiǎn)而言之：

　　隱藏類的超類型是由類加載器創(chuàng)建的，但隱藏類本身的創(chuàng)建并不涉及任何類加載器。所以可以方便的進(jìn)行卸載且不用考慮安全問題，并且可以減少程序的內(nèi)存占用。

4. JEP 372：刪除Nashorn JavaScript引擎

官方描述：

　　隨著ECMAScript語(yǔ)言構(gòu)造以及API的快速適應(yīng)和修改，我們發(fā)現(xiàn)Nashorn難以維護(hù)。官方?jīng)Q定刪除Nashorn JavaScript腳本引擎和API，以及該jjs?工具。

　　兩個(gè)JDK模塊將被永久刪除：

• jdk.scripting.nashorn-包含jdk.nashorn.api.scripting和 jdk.nashorn.api.tree軟件包。

• jdk.scripting.nashorn.shell-包含jjs工具。

5. JEP 373：重新實(shí)現(xiàn)舊版DatagramSocket API（套接字）

官方描述：　

　　用更易于維護(hù)和調(diào)試的更簡(jiǎn)單，更現(xiàn)代的實(shí)現(xiàn)來替換java.net.DatagramSocket和java.net.MulticastSocketAPI的基礎(chǔ)實(shí)現(xiàn)。新的實(shí)現(xiàn)將很容易適應(yīng)虛擬線程的工作，當(dāng)前正在Project Loom中進(jìn)行探索。

改動(dòng)原因：

　　java.net.DatagramSocket和java.net.MulticastSocketAPI的代碼庫(kù)及其基礎(chǔ)實(shí)現(xiàn)很舊且脆弱：

• 實(shí)現(xiàn)可以追溯到JDK 1.0。它們是傳統(tǒng)Java和C代碼的混合，難以維護(hù)和調(diào)試。

• 的實(shí)現(xiàn)MulticastSocket尤其成問題，因?yàn)樗梢宰匪莸絀Pv6仍處于開發(fā)階段。許多基本的本機(jī)實(shí)現(xiàn)都嘗試以難以維護(hù)的方式協(xié)調(diào)IPv4和IPv6。

• 該實(shí)現(xiàn)還存在一些并發(fā)問題（例如，異步關(guān)閉），需要進(jìn)行大修才能正確解決。

此外，在駐留而不是阻塞系統(tǒng)調(diào)用中底層內(nèi)核線程的虛擬線程的情況下，當(dāng)前實(shí)現(xiàn)不適合此目的。隨著基于數(shù)據(jù)報(bào)的傳輸再次獲得牽引力（例如?QUIC），需要更簡(jiǎn)單，更可維護(hù)的實(shí)現(xiàn)。

6.JEP 374：禁用和棄用偏置鎖定

官方描述：

　　在JDK 15之前，始終啟用并提供偏置鎖定。使用此JEP，除非?-XX:+UseBiasedLocking?在命令行上設(shè)置，否則在啟動(dòng)HotSpot時(shí)將不再啟用偏置鎖定。

改動(dòng)原因：

　　確定是否需要繼續(xù)支持偏向鎖定的傳統(tǒng)同步優(yōu)化，這是維護(hù)成本很高的方法。有偏見的鎖定會(huì)帶來爭(zhēng)用時(shí)需要進(jìn)行昂貴的撤銷操作的代價(jià)。

7.JEP 375：instanceof的模式匹配（第二預(yù)覽）

官方描述：

　　通過為操作員提供模式匹配來增強(qiáng)Java編程語(yǔ)言instanceof。模式匹配使程序中的通用邏輯（即從對(duì)象中有條件地提取組件）得以更簡(jiǎn)潔，更安全地表示。

簡(jiǎn)而言之：

　　可以使我們的代碼更加簡(jiǎn)潔。

代碼示例：

public?static?void?main(String[]?args)?{
????????Object?str?=?"模式匹配";
????????//?模式匹配
????????//?綁定變量s的作用域在&&運(yùn)算符的右側(cè)以及true塊中、綁定變量s不在||右側(cè)的范圍內(nèi)
//????????if(str?instanceof?String?s?&&?s.length()?>?0?){
????????if(str?instanceof?String?s){
????????????System.out.println(s);
????????}else?{
????????????//?s不能作用于此處
????????//?System.out.printf(s);
????????}
????}

8. JEP 377：ZGC：可擴(kuò)展的低延遲垃圾收集器（轉(zhuǎn)正）

官方描述：

　　對(duì)ZGC的測(cè)試表明它是穩(wěn)定的，并且在撰寫本文時(shí)，我們已經(jīng)有幾個(gè)月沒有收到針對(duì)ZGC的新錯(cuò)誤了。借助ZGC如今擁有的穩(wěn)定性，功能集和平臺(tái)支持，是時(shí)候刪除其實(shí)驗(yàn)狀態(tài)并使其成為產(chǎn)品功能了。

　　今天，可以通過-XX:+UnlockExperimentalVMOptions -XX:+UseZGC命令行選項(xiàng)啟用ZGC 。使ZGC成為產(chǎn)品（非實(shí)驗(yàn)性）功能意味著-XX:+UnlockExperimentalVMOptions不再需要該選件。

　　該JEP不建議更改默認(rèn)GC，該默認(rèn)GC仍為G1。

簡(jiǎn)而言之：

　　ZGC垃圾收集器在JDK15成為正式版，我們可以通過-XX:+UseZGC命令行選項(xiàng)啟用ZGC，但是需要注意的是默認(rèn)的垃圾收集器仍然是G1。

9. JEP 378：文字塊（轉(zhuǎn)正）

官方描述：

　　將文本塊添加到Java語(yǔ)言。文本塊是多行字符串文字，它避免了大多數(shù)轉(zhuǎn)義序列的需要，以一種可預(yù)測(cè)的方式自動(dòng)設(shè)置字符串的格式，并在需要時(shí)使開發(fā)人員可以控制格式。

　　解決了在Java中，在字符串文字中嵌入HTML，XML，SQL或JSON片段"..."通常需要先進(jìn)行轉(zhuǎn)義和串聯(lián)的大量編輯，然后才能編譯包含該片段的代碼。該代碼段通常難以閱讀且難以維護(hù)的問題。

代碼示例：

public?static?void?main(String[]?args)?{
????????String?html?=?"\n"?+
????????????????"????\n"?+
????????????????"????????
Hello,?world
\n"?+
????????????????"????\n"?+
????????????????"\n";

????????String?htmlText?=?"""
???????????
???????????????
???????????????????
Hello,?world

???????????????
???????????
???????????""";

????????System.out.println("html長(zhǎng)度"?+?html.length());
????????System.out.println("htmlText長(zhǎng)度"?+?htmlText.length());

????????String?query?=?"SELECT?\"EMP_ID\",?\"LAST_NAME\"?FROM?\"EMPLOYEE_TB\"\n"?+
????????????????"WHERE?\"CITY\"?=?'INDIANAPOLIS'\n"?+
????????????????"ORDER?BY?\"EMP_ID\",?\"LAST_NAME\";\n";

????????String?queryText?=?"""
????????????SELECT?"EMP_ID",?"LAST_NAME"?FROM?"EMPLOYEE_TB"
????????????WHERE?"CITY"?=?'INDIANAPOLIS'
????????????ORDER?BY?"EMP_ID",?"LAST_NAME";
????????????""";

????????System.out.println("query長(zhǎng)度"?+?query.length());
????????System.out.println("queryText長(zhǎng)度"?+?queryText.length());

????????//?\:取消換行操作
????????//?\s:標(biāo)識(shí)一個(gè)空格
????????String?sql1?=?"""
????????????SELECT?id,?name,?age?\
????????????FROM?person\s\
????????????WHERE?id?>?4?\
????????????ORDER?BY?age?DESC
????????????""";

????????String?sql2?=?"SELECT?id,?name,?age?FROM?person?WHERE?id?>?4?ORDER?BY?age?DESC";

????}

錯(cuò)誤代碼示例：

String?a?=?"""""";???//?no?line?terminator?after?opening?delimiter

String?b?=?"""?""";??//?no?line?terminator?after?opening?delimiter

String?c?=?"""
???????????";????????//?no?closing?delimiter?(text?block?continues?to?EOF)

String?d?=?"""
???????????abc?\?def
???????????""";??????//?unescaped?backslash?(see?below?for?escape?processing)

注意：

文本塊：
"""
line?1
line?2
line?3
"""

等效于字符串文字：
"line?1\nline?2\nline?3\n"

或字符串文字的串聯(lián)：
"line?1\n"?+
"line?2\n"?+
"line?3\n"

---------------------------------------------------------
"""
line?1
line?2
line?3"""

等效于字符串文字：
"line?1\nline?2\nline?3"

10. JEP 379：Shenandoah：低暫停時(shí)間的垃圾收集器（轉(zhuǎn)正）

官方描述：

　　將Shenandoah垃圾收集器從實(shí)驗(yàn)功能更改為產(chǎn)品功能。

　　在JDK 12和更高版本中，通過-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC選項(xiàng)啟用了Shenandoah 。將Shenandoah成為產(chǎn)品功能意味著-XX:+UnlockExperimentalVMOptions不再需要。

簡(jiǎn)而言之：

　　Shenandoah垃圾收集器功能轉(zhuǎn)正，可以通過-XX:+UseShenandoahGC直接使用，Shenandoah 的暫停時(shí)間與堆大小無關(guān)。

11. JEP 381：刪除Solaris和SPARC端口

官方描述：

　　刪除所有特定于Solaris操作系統(tǒng)的源代碼。

　　刪除所有特定于SPARC體系結(jié)構(gòu)的源代碼。

　　更新文檔和源代碼注釋以用于將來的版本。

改動(dòng)原因：

　　當(dāng)前正在開發(fā)的許多項(xiàng)目和功能（例如Valhalla，Loom和Panama）都需要對(duì)CPU體系結(jié)構(gòu)和特定于操作系統(tǒng)的代碼進(jìn)行重大更改。放棄對(duì)Solaris和SPARC端口的支持將使OpenJDK社區(qū)中的貢獻(xiàn)者能夠加速新功能的開發(fā)，這些新功能將推動(dòng)平臺(tái)向前發(fā)展。

12.JEP 383：外部存儲(chǔ)器訪問API（第二個(gè)孵化器）

官方描述：

　　引入一個(gè)API，以允許Java程序安全有效地訪問Java堆之外的外部?jī)?nèi)存。

　　在Java 14作為孵化API，在JDK15中第二次孵化。

　　以jdk.incubator.foreign相同的名稱包形式提供了外部存儲(chǔ)器訪問API ；它引入了三個(gè)主要抽象：MemorySegment，MemoryAddress和MemoryLayout。

13.JEP 384：Records（第二預(yù)覽）

官方描述：

　　使用records增強(qiáng)Java編程語(yǔ)言，record 是充當(dāng)不可變數(shù)據(jù)的透明載體的類。記錄可以看作是名義元組。

• 設(shè)計(jì)一個(gè)表達(dá)簡(jiǎn)單值集合的面向?qū)ο蟮臉?gòu)造。

• 幫助程序員專注于對(duì)不可變數(shù)據(jù)進(jìn)行建模，而不是對(duì)可擴(kuò)展行為進(jìn)行建模。

• 自動(dòng)實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)的方法，例如equals和訪問器。

• 保留長(zhǎng)期的Java原則，例如標(biāo)稱類型和遷移兼容性

官方示例：

例如，先前聲明的記錄record Point(int x, int y)?{?}-將被編譯為：

record?Point(int?x,?int?y)?{
????//?Implicitly?declared?fields
????private?final?int?x;
????private?final?int?y;

????//?Other?implicit?declarations?elided?...

????//?Implicitly?declared?canonical?constructor
????Point(int?x,?int?y)?{
????????this.x?=?x;
????????this.y?=?y;
????}
}

簡(jiǎn)而言之：

　　似于lombok,主要目的是為了簡(jiǎn)化作用，不用再寫構(gòu)造方法、equals，hashCode，toString等方法。

代碼示例：

public?record?Student(String?name,int?age)?{
}

public?class?Main?{
????public?static?void?main(String[]?args)?{
????????Student?student?=?new?Student("張三",20);
????????System.out.println(student);
????????System.out.println(student.name());
????????System.out.println(student.age());
????}
}

14.JEP 385：棄用RMI激活以進(jìn)行刪除

官方描述：

　　棄用RMI激活?機(jī)制以便將來刪除。RMI激活是RMI的過時(shí)部分，自Java 8開始，RMI激活是可選的。不會(huì)棄用RMI的其他部分。

改動(dòng)原因：

　　分布式系統(tǒng)至少在過去十年中一直基于Web技術(shù)。Web服務(wù)領(lǐng)域已經(jīng)解決了有關(guān)穿越防火墻，篩選請(qǐng)求，身份驗(yàn)證和安全性的問題。延遲實(shí)例化資源由負(fù)載平衡器，業(yè)務(wù)流程和容器處理。這些機(jī)制在分布式系統(tǒng)的RMI激活模型中均不存在。

　　RMI激活的使用量幾乎消失了。沒有證據(jù)表明有任何新的應(yīng)用程序被編寫為使用RMI激活，并且有證據(jù)表明很少有現(xiàn)有應(yīng)用程序使用RMI激活。對(duì)各種開放源代碼庫(kù)的搜索幾乎沒有發(fā)現(xiàn)任何與激活相關(guān)的API。

間而言之：

　　RMI激活的功能使用極少，Web服務(wù)有更優(yōu)秀的問題解決方案，RMI激活增加了維護(hù)的費(fèi)用。　　

四、總結(jié)

　　總的來說，JDK15新功能不多，可以根據(jù)自己的實(shí)際需要，根據(jù)JDK版本功能走向來選擇合理的功能。

粉絲福利：Java從入門到入土學(xué)習(xí)路線圖

??????

??長(zhǎng)按上方微信二維碼?2 秒

感謝點(diǎn)贊支持下哈?