重磅!Java 16 正式發(fā)布_第1頁
重磅!Java 16 正式發(fā)布_第2頁
重磅!Java 16 正式發(fā)布_第3頁
重磅!Java 16 正式發(fā)布_第4頁
重磅!Java 16 正式發(fā)布_第5頁
已閱讀5頁,還剩4頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

重磅!Java16正式發(fā)布Java16發(fā)布了!2020年是值得紀念的一年,這一年中我們慶祝了Java的25歲生日。經過二十多年的持續(xù)創(chuàng)新,Java一直在:通過適應不斷變化的技術格局來保持靈活性,同時維持平臺獨立性。通過保持向后兼容性來保證可靠性。在不犧牲安全性的前提下加速創(chuàng)新來保持優(yōu)勢。Java憑借自身不斷提高平臺性能、穩(wěn)定性和安全性的能力,一直是開發(fā)人員中最流行的編程語言。IDC的最新報告“JavaTurns25”顯示,超過900萬名開發(fā)人員(全球專職開發(fā)人員中的69%)在使用Java——比其他任何語言都多。甲骨文還在繼續(xù)探索Java的持續(xù)創(chuàng)新之路,并自豪地宣布Java16正式發(fā)布,這也是我們轉向六個月發(fā)布周期后的第七個特性版本。這種可預測水平使開發(fā)人員可以更輕松地管理他們對創(chuàng)新的采用計劃。上圖顯示了自Java8以來每個版本的特性數量1Java16現在已可用甲骨文現在為所有開發(fā)人員和企業(yè)提供Java16,按照甲骨文重要補丁更新(CPU)時間表,甲骨文JDK16將至少獲得兩次季度更新,隨后是甲骨文JDK17。Java17將于2021年9月正式發(fā)布,但是已經提供了它的早期訪問版本。甲骨文再次使用開源GNU通用公共許可證v2和ClasspathException(GPLv2+CPE)將Java16作為甲骨文OpenJDK版本提供,并且針對使用甲骨文JDK版本作為甲骨文產品或服務一部分的用戶,或希望能夠獲得商業(yè)支持的用戶提供商業(yè)許可。2Java16,我們攜手同行與之前的版本類似,我們將繼續(xù)感謝來自OpenJDK社區(qū)中眾多個人和組織對Java16所做的貢獻——我們攜手同行,共同構建Java!JDK16修復比率JDK的總體變化率多年來一直保持基本穩(wěn)定,但是在六個月的發(fā)布周期下,可用于生產的創(chuàng)新交付速度已大大提高。過去,我們每隔幾年在大型主要版本中發(fā)布成千上萬的修復和大約一百個JDK增強提案(JEP);而現在,我們改為更易于管理、更容易預測的六個月周期,在較小的特性版本中提供增強特性。這些更改的范圍從重大特性到小型改進和例行維護、錯誤修復和文檔改進。每個更改都在JDK錯誤系統(tǒng)中用一個問題的一次提交來表示。在Java16中標記為修復的1,897個問題中,有1,397個由甲骨文工作人員完成,還有500個由個人開發(fā)人員和為其他組織工作的開發(fā)人員貢獻。我們整理了貢獻者所在組織的數據,得到了以下組織分布圖:上圖顯示每個組織貢獻的修復數量甲骨文要感謝為ARM、SAP、RedHat和騰訊等組織工作的開發(fā)人員所做的杰出貢獻,同時也感謝來自小型組織(如AmpereComputing、Bellsoft、DataDog、Microdoc和獨立開發(fā)人員)的貢獻,他們貢獻了Java16中3%的修復。我們同樣感謝許多審查提案更改的經驗豐富的開發(fā)人員、嘗試采用早期訪問版本并報告問題的早期采用者、以及在OpenJDK郵件列表中提供反饋的敬業(yè)專業(yè)人員。3Java16的新特性伴隨著數千個性能、穩(wěn)定性和安全性更新,Java16為用戶提供了十七項主要的增強/更改(稱為JDK增強提案——JEP),包括三個孵化器模塊和一個預覽特性。孵化器模塊(IncubatorModule)中引入了一些增強,這是一種將非最終API和非最終工具交給開發(fā)人員的方法,該方法允許用戶提供反饋,從而改善Java平臺的質量。搜索后端架構師公眾號回復“架構整潔”,送你一份驚喜禮包。同樣,一些增強被作為JavaSE平臺的預覽特性、語言或VM特性引入,這些增強已完全指定、完全實現但不是永久性的。JDK特性版本中提供了這些增強,以推動開發(fā)人員根據實際使用情況提供反饋,這可能會導致它們在將來的版本中永久保留。這為用戶提供了及時反饋的機會,并讓工具供應商有機會在大量Java開發(fā)人員在生產中使用特性之前為其提供支持。Java16隨附的17個JEP分為六個不同類別:新語言特性

JEP394,適用于instanceof的模式匹配模式匹配(PatternMatching)最早在Java14中作為預覽特性引入,在Java15中還是預覽特性。模式匹配通過對instacneof運算符進行模式匹配來增強Java編程語言。模式匹配使程序中的通用邏輯(即從對象中有條件地提取組件)得以更簡潔、更安全地表示。

JEP

395,記錄記錄(Records)在Java14和Java15中作為預覽特性引入。它提供了一種緊湊的語法來聲明類,這些類是淺層不可變數據的透明持有者。這將大大簡化這些類,并提高代碼的可讀性和可維護性。JVM改進

JEP

376,ZGC并發(fā)線程處理JEP376將ZGC線程棧處理從安全點轉移到一個并發(fā)階段,甚至在大堆上也允許在毫秒內暫停GC安全點。消除ZGC垃圾收集器中最后一個延遲源可以極大地提高應用程序的性能和效率。

JEP

387,彈性元空間此特性可將未使用的HotSpot類元數據(即元空間,metaspace)內存更快速地返回到操作系統(tǒng),從而減少元空間的占用空間。具有大量類加載和卸載活動的應用程序可能會占用大量未使用的空間。新方案將元空間內存按較小的塊分配,它將未使用的元空間內存返回給操作系統(tǒng)來提高彈性,從而提高應用程序性能并降低內存占用。新工具和庫

JEP

380,Unix-Domain套接字通道Unix-domain套接字一直是大多數Unix平臺的一個特性,現在在Windows10和WindowsServer2019也提供了支持。此特性為java.nio.channels包的套接字通道和服務器套接字通道API添加了Unix-domain(AF_UNIX)套接字支持。它擴展了繼承的通道機制以支持Unix-domain套接字通道和服務器套接字通道。Unix-domain套接字用于同一主機上的進程間通信(IPC)。它們在很大程度上類似于TCP/IP,區(qū)別在于套接字是通過文件系統(tǒng)路徑名而不是Internet協(xié)議(IP)地址和端口號尋址的。對于本地進程間通信,Unix-domain套接字比TCP/IP環(huán)回連接更安全、更有效。

JEP

392,打包工具此特性最初是作為Java14中的一個孵化器模塊引入的,該工具允許打包自包含的Java應用程序。它支持原生打包格式,為最終用戶提供自然的安裝體驗,這些格式包括Windows上的msi和exe、macOS上的pkg和dmg,還有Linux上的deb和rpm。它還允許在打包時指定啟動時參數,并且可以從命令行直接調用,也可以通過ToolProviderAPI以編程方式調用。注意jpackage模塊名稱從jdk.incubator.jpackage更改為jdk.jpackage。這將改善最終用戶在安裝應用程序時的體驗,并簡化了“應用商店”模型的部署。為未來做好準備

JEP

390,對基于值的類發(fā)出警告此特性將原始包裝器類(java.lang.Integer、java.lang.Double等)指定為基于值的(類似于java.util.Optional和java.time.LocalDateTime),并在其構造器中添加forRemoval(自JDK9開始被棄用),這樣會提示新的警告。在Java平臺中嘗試在任何基于值的類的實例上進行不正確的同步時,它會發(fā)出警告。許多流行的開源項目已經在其源中刪除了包裝構造器調用來響應Java9的棄用警告,并且鑒于“棄用移除”警告的緊迫性,我們可以期望更多開源項目跟上這一步伐。

JEP

396,默認強封裝JDK內部元素此特性會默認強封裝JDK的所有內部元素,但關鍵內部API(例如sun.misc.Unsafe)除外。默認情況下,使用早期版本成功編譯的訪問JDK內部API的代碼可能不再起作用。鼓勵開發(fā)人員從使用內部元素遷移到使用標準API的方法上,以便他們及其用戶都可以無縫升級到將來的Java版本。強封裝由JDK9的啟動器選項–illegal-access控制,到JDK15默認改為warning,從JDK16開始默認為deny。(目前)仍然可以使用單個命令行選項放寬對所有軟件包的封裝,將來只有使用–add-opens打開特定的軟件包才行。孵化器和預覽特性

JEP

338,向量API(孵化器)該孵化器API提供了一個API的初始迭代以表達一些向量計算,這些計算在運行時可靠地編譯為支持的CPU架構上的最佳向量硬件指令,從而獲得優(yōu)于同等標量計算的性能,充分利用單指令多數據(SIMD)技術(大多數現代CPU上都可以使用的一種指令)。盡管HotSpot支持自動向量化,但是可轉換的標量操作集有限且易受代碼更改的影響。該API將使開發(fā)人員能夠輕松地用Java編寫可移植的高性能向量算法。

JEP

389,外部鏈接器API(孵化器)該孵化器API提供了靜態(tài)類型、純Java訪問原生代碼的特性,該API將大大簡化綁定原生庫的原本復雜且容易出錯的過程。Java1.1就已通過Java原生接口(JNI)支持了原生方法調用,但并不好用。Java開發(fā)人員應該能夠為特定任務綁定特定的原生庫。它還提供了外來函數支持,而無需任何中間的JNI粘合代碼。

JEP

393,外部存儲器訪問API(第3個孵化器)在Java14和Java15中作為孵化器API引入的這個API使Java程序能夠安全有效地對各種外部存儲器(例如本機存儲器、持久性存儲器、托管堆存儲器等)進行操作。它提供了外部鏈接器API的基礎。

JEP

397,密封類(第二預覽)這個預覽特性可以限制哪些類或接口可以擴展或實現它們;它允許類或接口的控制負責實現它的代碼;它還提供了比訪問修飾符更具聲明性的方式來限制對超類的使用。它還通過對模式進行詳盡的分析來支持模式匹配的未來發(fā)展。提升OpenJDK開發(fā)人員的生產力其余更改對Java開發(fā)人員(使用Java編寫代碼和運行應用程序的人員)不會直接可見,而只對Java開發(fā)人員(參與OpenJDK開發(fā)的人員)可見。

JEP

347,啟用C++14語言特性(在JDK源代碼中)它允許在JDKC++源代碼中使用C++14語言特性,并提供在HotSpot代碼中可以使用哪些特性的具體指導。在JDK15中,JDK中C++代碼使用的語言特性僅限于C++98/03語言標準。它要求更新各種平臺編譯器的最低可接受版本

JEP357,從Mercurial遷移到Git;JEP369,遷移到GitHub這些JEP將OpenJDK社區(qū)的源代碼存儲庫從Mercurial(hg)遷移到Git,并將它們托管在GitHub上以供JDK11及更高版本使用,其中包括將jcheck、webrev和defpath工具等工具更新到Git。Git減小了元數據的大?。s1/4),可節(jié)省本地磁盤空間并減少克隆時間。與Mercurial相比,現代工具鏈可以更好地與Git集成。OpenJDKGit存儲庫現在位于/openjdk。

JEP386,AlpineLinux移植;JEP388,Windows/AArch64移植這些JEP的重點不是移植工作本身,而是將它們集成到JDK主線存儲庫中;JEP386將JDK移植到AlpineLinux和其他使用musl作為x64上主要C庫的發(fā)行版上。此外,JEP388將JDK移植到WindowsAArch64(ARM64)。4工具鏈支持當前的工具鏈支持有助于提高開發(fā)人員的生產力。在Java16中,我們繼續(xù)歡迎領先的IDE

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論