西安聚合軟件有限公司

西安聚合軟件有限公司

當前位置:首頁 > 文章中心 > 公司動態 > Java9新特性逐項解析,總有一項get到你的點

Java9新特性逐項解析,總有一項get到你的點

2018-01-22 西安聚合軟件有限公司 閱讀 1405

 一、JDK 與 JRE 的關系

JDK :JavaDevelopmentKit (Java開發工具包)

JRE :JavaRuntimeEnvironment (Java運行環境)

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

說明:

JDK = JRE + 開發工具集(例如Javac編譯工具等)

JRE = JVM + Java SE標準類庫


二、JDK 8 的目錄結構

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

說明:

bin 目錄包含命令行開發和調試工具,如javac,jar和javadoc。

include目錄包含在編譯本地代碼時使用的C/C++頭文件

lib 目錄包含JDK工具的幾個JAR和其他類型的文件。 它有一個tools.jar文件,其中包含javac編譯器的Java類

jre/bin 目錄包含基本命令,如java命令。 在Windows平臺上,它包含系統的運行時動態鏈接庫(DLL)。

jre/lib 目錄包含用戶可編輯的配置文件,如.properties和.policy文件。包含幾個JAR。 rt.jar文件包含運行時的Java類和資源文件。


三、JDK 9 的目錄結構

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

說明:

沒有名為jre的子目錄

bin 目錄包含所有命令。 在Windows平臺上,它繼續包含系統的運行時動態鏈接庫。

conf 目錄包含用戶可編輯的配置文件,例如以前位于jrelib目錄中的.properties和.policy文件

include 目錄包含要在以前編譯本地代碼時使用的C/C++頭文件。 它只存在于JDK中

jmods 目錄包含JMOD格式的平臺模塊。 創建自定義運行時映像時需要它。 它只存在于JDK中

legal 目錄包含法律聲明

lib 目錄包含非Windows平臺上的動態鏈接本地庫。 其子目錄和文件不應由開發人員直接編輯或使用


四、Java9新增特性:

102: Process API Updates

進程操作API 升級,提升對操作系統進程的控制和管理。

新增的

java.lang.ProcessHandle

類豐富了對進程的操作,同時原有的

java.lang.Process

類的功能也被加強了。

在Java很早的版本中,提供了Process這樣的API可以獲得進程的一些信息,包括runtime,甚至是用它來執行當前主機的一些命令,但是請大家思考一個問題,你如何獲得你當前Java運行程序的PID?很顯然通過Process是無法獲得的,需要借助于JMX才能得到,但是在這一次的增強中,你將會很輕松的得到這樣的信息,我們來看一個簡單的例子:

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

上面有大量的Optional,這是Java 8中的API,同樣在Java 9中對其進行了增強。

已經獲取到了JVM的進程,我們該如何將該進程優雅的停掉呢?下面的代碼給出了答案

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

110: HTTP 2 Client

就目前而言,JDK提供的Http訪問功能,幾乎都需要依賴于HttpURLConnection,但是這個類大家在寫代碼的時候很少使用,我們一般都會選擇Apache的Http Client,此次在Java 9的版本中引入了一個新的package:java.net.http,里面提供了對Http訪問很好的支持,不僅支持Http1.1而且還支持HTTP2,以及WebSocket,據說性能可以超過Apache HttpClient,Netty,Jetty,簡單的來看一個代碼片段:

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

通過上面的一小段代碼,我們也發現了Java 9對斷言機制同樣增加了一些增強,多說一些題外話,我們目前的系統中運行一個嚴重依賴于Hive beelineServer的程序,beeline server不是很穩定,經常出現卡頓,甚至假死,假死后也不回復的問題,這樣就導致我們的程序也會出現卡頓,如果運維人員不對其進行清理,系統運行幾個月之后會發現很多僵尸進程,于是增加一個獲取當前JVM PID的功能,然后判斷到超過給定的時間對其進行主動殺死,完全是程序內部的行為,但是獲取PID就必須借助于JMX的動作,另外殺死它也必須借助于操作系統的命令,諸如kill這樣的命令,顯得非常的麻煩,但是Java 9的方式明顯要優雅方便許多。

143: Improve Contended Locking

優化競爭鎖的性能

能夠改善程序運行時的多線程同步效率。

158: Unified JVM Logging

統一 JVM 日志

日志是解決問題的唯一有效途徑:曾經很難知道導致JVM性能問題和導致JVM崩潰的根本原因。不同的JVM日志的碎片化和日志選項(例如:JVM組件對于日志使用的是不同的機制和規則),這使得JVM難以進行調試。

解決該問題最佳方法:對所有的JVM組件引入一個單一的系統,這些JVM組件支持細粒度的和易配置的JVM日志

165: Compiler Control

193: Variable Handles

操作內存,用來替代sun.misc.Unsafe。操作內存更安全,且性能相同或相似的等效sun.misc.unsafe操作。

在JDK 9中提供了一個新的包,叫做java.lang.invoke里面有一系列很重要的類比如VarHandler和MethodHandles,提供了類似于原子操作以及Unsafe操作的功能。

197: Segmented Code Cache

代碼分段緩存

Java 9的另一個性能提升來自于JIT(Just-in-time)編譯器。當某段代碼被大量重復執行的時候, 虛擬機會把這段代碼編譯成機器碼(native code)并儲存在代碼緩存里面, 繼而通過訪問緩存中不同分段的代碼來提升編譯器的效率。代碼分段緩存機制將會提升許多方面的性能,如當JVM進行垃圾回收掃描的時候,就可以直接跳過永駐代碼,從而提升效率

JDK 9 中的代碼段在 Segmented Code Cache 的作用下,可以被更加細分,而且每個代碼段還可以包括特定類型的編譯代碼,這個功能同樣也有望提升 Java 9 性能。

這個特性一般不會在 Java 代碼中直接使用,它通過對本地編譯代碼(即代碼緩存)進行更好的組織,讓 JRE 的運行效率有所提高。

198: Light-Weight JSON API

盡管目前有多種處理JSON的Java工具(如Google的Gson、阿里巴巴的FastJson、IBM的Json4J等),但JSON API是Java語言的一部分,輕量并且運用了Java 8的新特性。JSON API將放在java.util包里一起發布,這樣,開發者就可以直接使用JDK而無需再引入第三方JSON工具包了

199: Smart Java Compilation, Phase Two

改進sjavac工具的穩定性和可移植性,使其可以更好地用于大型項目的構建。

智能Java編譯工具(sjavac)的第一階段始于JEP139這個項目, 用于在多核處理器情況下提升JDK的編譯速度。如今,這個項目已經進入第二階段即JEP199, 其目的是改進Java編譯工具,并取代目前JDK編譯工具javac,繼而成為Java環境默認的通用的智能編譯工具

200: The Modular JDK

Java 9中最重要的功能,毫無疑問就是模塊化(Module),代碼名字叫做Jigsaw(拉鋸),這個拉鋸項目拉了幾年,終于要把龐大冗余的Java鋸成一個個的Module,方便開發和部署。熟悉Java的同學,都知道JRE有一個超級大rt.jar(例如,Java 8的rt.jar中有65M),運行一個hello world,你也需要一個數百兆的JRE環境,如果在J2EE環境,情況將變得復雜無比

201: Modular Source Code

211: Elide Deprecation Warnings on Import Statements

212: Resolve Lint and Doclint Warnings

213: Milling Project Coin

接口的私有方法

Java 8中規定接口中的方法除了抽象方法之外,還可以定義靜態方法和默認的方法。一定程度上,擴展了接口的功能,此時的接口更像是一個抽象類。

在Java 9中,接口更加的靈活和強大,連方法的訪問權限修飾符都可以聲明為private的了,此時方法將不會成為你對外暴露的API的一部分。

214: Remove GC Combinations Deprecated in JDK 8

215: Tiered Attribution for javac

216: Process Import Statements Correctly

217: Annotations Pipeline 2.0

219: Datagram Transport Layer Security (DTLS)

220: Modular Run-Time Images

模塊化運行時鏡像

221: Simplified Doclet API

222: jshell: The Java Shell (Read-Eval-Print Loop)

交互式命令行

簡稱 JShell,方便對程序進行調試,以及快速檢驗 API 的可行性無須無須創建一個項目來學習 API,打開 JShell 即可。

在Java 8 出來的時候,很多人都喊著,這是要搶奪Scala等基于JVM動態語言的市場啊,其中有人給出了一個Java做不到的方向,那就是Scala可以當作腳本語言,Java可以么?很明顯在此之前Java不行,ta也不具備動態性,但是此次Java 9 卻讓Java也可以像腳本語言一樣來運行了,主要得益于JShell,我們來看一下這個演示

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

這是我們在Jshell這個控制臺下運行,我們如何運行腳本文件呢?

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

223: New Version-String Scheme

224: HTML5 Javadoc

jdk 8 :生成的java幫助文檔是在HTML 4 中,而HTML 4 已經是很久的標準了。

jdk 9 :javadoc的輸出,現在符合兼容HTML 5 標準。

下圖是java8 中生成的html頁面,如果想要找到一些類文檔,必須在google中搜索

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

下圖是在java 9 中,添加了一個搜索框。

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

225: Javadoc Search

226: UTF-8 Property Files

屬性文件支持 UTF-8 編碼

ResourceBundle 的缺省編碼問題一直是被吐槽的對象,非英文字符被轉碼為看不懂的形式,嚴重損害了代碼的可讀性。從 Java 9 開始,ResourceBundle 默認編碼為 UTF-8。

227: Unicode 7.0

JDK9升級現有的平臺APIs以支持Unicode標準的7.0版,支持Unicode的最新版本。

228: Add More Diagnostic Commands

229: Create PKCS12 Keystores by Default

231: Remove Launch-Time JRE Version Selection

232: Improve Secure Application Performance

233: Generate Run-Time Compiler Tests Automatically

235: Test Class-File Attributes Generated by javac

236: Parser API for Nashorn

JDK 9 中附帶了一個 Nashorn 的 parser API,它的目標是 Java 在本地 JVM 中實現輕量級高性能 JS runtime。這個新特性可以保障 Java 9 更好的融合 JavaScript 和 Java 的兩方之力。

237: Linux/AArch64 Port

連接到Linux / AArch64的端口。

AArch64是ARM控股公司推出的新處理器體系結構。它與32位ARM處理器架構不同,實際上是一個完全的重新設計。它需要一個新的OpenJDK端口

238: Multi-Release JAR Files

當一個新版本的Java出現的時候,你的庫用戶要花費數年時間才會切換到這個新的版本。這就意味著庫得去向后兼容你想要支持的最老的Java版本(許多情況下就是Java 6 或者 Java7)。這實際上意味著未來的很長一段時間,你都不能在庫中運用Java 9所提供的新特性。幸運的是,多版本兼容jar功能能讓你創建僅在特定版本的Java環境中運行庫程序選擇使用的class版本。

240: Remove the JVM TI hprof Agent

從JDK中刪除高性能代理。

J2SE中提供了一個簡單的命令行工具來對java程序的cpu和heap進行 profiling,叫做HPROF。HPROF實際上是JVM中的一個native的庫。該工具已被更好的替代品所取代。

241: Remove the jhat Tool

刪除過時的jhat工具。

jhat是在JDK 6中基于Java . net帽子項目添加的。jhat是一個實驗性的、不受支持的、過時的工具。高級堆可視化工具和分析器已經使用多年。

243: Java-Level JVM Compiler Interface

動態編譯器

對于整個編程語言的發展,可能都具有非常重要的意義,雖然未必引起了廣泛關注。目前 Graal Core API 已經被集成進入 Java 9,雖然還只是初始一小步,但是完全用 Java 語言來實現的可靠的、高性能的動態編譯器,似乎不再是遙不可及。

244: TLS Application-Layer Protocol Negotiation Extension

245: Validate JVM Command-Line Flag Arguments

246: Leverage CPU Instructions for GHASH and RSA

247: Compile for Older Platform Versions

248: Make G1 the Default Garbage Collector

G1 成為默認的垃圾收集器

G1 進一步減少了 GC 時的停頓時間(GC pause time),其實它從 JDK 8u40 開始就已經十分完善,足以作為默認的垃圾收集器了。

249: OCSP Stapling for TLS

250: Store Interned Strings in CDS Archives

251: Multi-Resolution Images

接口java.awt.image.MultiResolutionImage封裝了一系列的不同分辨率圖像到一個單獨對象的API,我么可以根據給定的DPI 矩陣獲取resolution-specific,看一下下面的代碼片段:

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

252: Use CLDR Locale Data by Default

253: Prepare JavaFX UI Controls & CSS APIs for Modularization

254: Compact Strings

優化字符串占用空間

在很多應用當中,字符串已經成為一個消耗內存的主要部分。通過優化字符串的占用空間,應用的內存使用可以得到明顯改善。


255: Merge Selected Xerces 2.11.0 Updates into JAXP

256: BeanInfo Annotations

257: Update JavaFX/Media to Newer Version of GStreamer

258: HarfBuzz Font-Layout Engine

259: Stack-Walking API

260: Encapsulate Most Internal APIs

261: Module System

Java 模塊化-重大特性

該項目主要的目的是為更小的設備提供可伸縮性,改進 JDK 和 Java SE 的安全性,對大型應用的性能提升以及更易于構建。這個功能會使 JDK、run-time images 以及 Java 源代碼等模塊化,甚至開發者還可以創建自己的模塊來簡化代碼

262: TIFF Image I/O

263: HiDPI Graphics on Windows and Linux

264: Platform Logging API and Service

265: Marlin Graphics Renderer

266: More Concurrency Updates

267: Unicode 8.0

268: XML Catalogs

269: Convenience Factory Methods for Collections

集合工廠方法:快速創建只讀集合

270: Reserved Stack Areas for Critical Sections

271: Unified GC Logging

該特性為JVM的所有組件引入了一個通用的日志系統,提供了JVM日志的基礎設施,你可以不用專門為了打印某些日志而添加一些專門的標簽,只需要使用統一的log指令即可,比如:

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

272: Platform-Specific Desktop Features

273: DRBG-Based SecureRandom Implementations

274: Enhanced Method Handles

275: Modular Java Application Packaging

276: Dynamic Linking of Language-Defined Object Models

277: Enhanced Deprecation

278: Additional Tests for Humongous Objects in G1

G1中大量對象的附加測試

279: Improve Test-Failure Troubleshooting

自動收集診斷信息,以便在測試失敗和超時的情況下進一步排除故障。

280: Indify String Concatenation

281: HotSpot C++ Unit-Test Framework

282: jlink: The Java Linker

Java連接器

連接器負責高層會話,如http會話。連接器框架組件,基于NIO開發,用于javaiis http服務器項目。

Java9新特性逐項解析,總有一項get到你的點,先收藏著!

284: New HotSpot Build System

使用構建基礎架構重寫熱點構建系統。

本項目的目標是用一個新的、簡化得多的基于build - infra框架的構建系統替換當前的構建系統。更具體地說:

利用build - infra框架中提供的功能,最大限度地減少代碼重復。

簡化熱點構建系統以提供更易于維護的代碼庫,并降低閾值以供將來改進。

285: Spin-Wait Hints

定義API以允許Java代碼提示正在執行旋轉循環,即自旋等待提示。

定義一個API,允許Java代碼提示運行時系統它處于旋轉循環中。API將是一個純提示,不包含語義行為需求(例如,無操作是有效的實現)。允許JVM受益于在某些硬件平臺上可能有用的自旋循環特定行為。在JDK中提供無操作實現和固有實現,并在至少一個主要硬件平臺上演示執行優勢。

287: SHA-3 Hash Algorithms

實現NIST FIPS 202中指定的SHA - 3加密散列函數(僅字節)。

SHA - 2發布于10多年前,雖然尚未證明對SHA - 2的重大攻擊,但NIST認為需要一種不同的加密散列函數來替代SHA - 2。九年來,SHA - 3是NIST利用公開競爭和審查過程開發的第一個加密哈希算法。FIPS 202 " SHA - 3標準:基于排列的散列和可擴展輸出函數"于2015年8月作為標準定稿。當FIPS 202還是草稿時,諸如BouncyCastle之類的加密供應商開始支持SHA - 3。Solaris還將在即將發布的Solaris 12.0版本中支持SHA - 3。由于哈希函數在安全應用程序中廣泛使用,并且其他供應商已經添加了SHA - 3實現,因此在JDK中為SHA - 3提供支持非常重要。

288: Disable SHA-1 Certificates

通過提供更靈活的機制來禁用具有基于SHA - 1簽名的x . 509證書鏈,改進了JDK的安全配置。

目標不是禁用SHA - 1證書的所有用法。只有通過CertPathValidator和CertPathBuilder API的PKIX實現以及TrustManagerFactory API的SunX509和PKIX實現驗證的X.509證書鏈才受限制。其他用途(解析等)。)中的證書不受影響。CertPathValidator、CertPathBuilder和TrustManagerFactory的第三方實現直接負責實施它們自己的限制。

基于SHA - 1的數字簽名算法的使用由于沖突攻擊的風險而日益成為安全問題。NIST在SP 800 - 57第1部分中建議不再使用SHA - 1對數據應用數字簽名。CA / Browser論壇對公眾信任的SSL證書的基線要求規定,自2016年1月1日起,證書頒發機構不得使用SHA - 1頒發任何從屬CA或訂戶證書。其他軟件供應商(谷歌、微軟、Mozilla、蘋果)已經公布了在證書中對SHA - 1進行貶值的計劃。在JDK中,x . 509證書鏈用于驗證TLS中的服務器和客戶端以及驗證簽名代碼的完整性和作者

289: Deprecate the Applet API

Applet API 被標記為為過時。

要在web瀏覽器中運行Java小程序,需要使用瀏覽器插件。然而,截至2015年底,許多瀏覽器供應商要么已經取消了插件支持,要么宣布了取消插件支持的時間表。一旦瀏覽器插件消失,就沒有理由使用Applet API。

290: Filter Incoming Serialization Data

291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector

Java 9 或將放棄 CMS(并發標記清除垃圾收集器)

取消對CMS的支持,然后刪除CMS代碼,或者至少更徹底地分離CMS代碼,將減少GC代碼庫的維護負擔,并加快新的開發。從長遠來看,G1垃圾收集器將取代CMS的大多數用途。

新版本未指定將刪除CMS支持的主要版本。何時執行此操作,取決于G1收集器在多大程度上被證明是CMS的合適替代品。同時,鼓勵CMS用戶遷移到G1收集器( - XX : + UseG1GC )。

但是從經驗來看,很多 Java 應用選擇的是 CMS+ParNew,而且很多應用針對 CMS 的行為做了優化。現在宣布去掉 CMS,或許還為時過早。

292: Implement Selected ECMAScript 6 Features in Nashorn

ECMAScript 6于2015年6月發布。到目前為止,還沒有一個JavaScript引擎提供對ES6的完整支持,但是包括Google V8、Mozilla蜘蛛猴和JavaScript core在內的主要引擎最近在實現ES6方面取得了重大進展。

Nashorn 項目在 JDK 9 中得到改進,它為 Java 提供輕量級的 Javascript 運行時。Nashorn 項目跟隨 Netscape 的 Rhino 項目,目的是為了在 Java 中實現一個高性能但輕量級的 Javascript 運行時。Nashorn 項目使得 Java 應用能夠嵌入 Javascript。它在 JDK 8 中為 Java 提供一個 Javascript 引擎。

JDK 9 包含一個用來解析Nashorn 的ECMAScript 語法樹的API。這個 API 使得 IDE 和服務端框架不需要依賴 Nashorn 項目的內部實現類,就能夠分析 ECMAScript 代碼。

294: Linux/s390x Port

s390x (也稱為“系統z”或“z /體系結構”)是由IBM開發和支持的大型機體系結構。包括Ubuntu、RHEL / Fedora和SuSE在內的幾個Linux發行版在s390上運行。

目前的云部署,包括TomEE、Cassandra、Spark、Hadoop和Neo4j等軟件包,嚴重依賴Java。因為大多數軟件包都是開源的,所以它們在OpenJDK上運行得最好,而OpenJDK目前對Linux / s390x不可用。

目前,零端口可用于在Linux / s390x上運行JDK,但速度很慢(因為它只使用舊的、棄用的c++解釋器),并且測試不太好。它不是運行應用程序服務器或用Java編寫的數據庫應用程序等工作負載的真正替代方案。

IBM的Linux開發工具包也可用于Linux / s390x,但它目前不是開源的,Java應用程序通常需要一些配置/調優才能與它一起運行。此外,它不能用于測試即將發布的Java版本的新功能,因為它僅在JDK本身是GA之后發布。

SAP有一個完整的(即模板解釋器、C1和C2 JIT )和經過認證的( Java SE 1.4 - 8 ) s390x端口,已在生產中使用多年。

295: Ahead-of-Time Compilation

AOT 編譯

JIT(Just-in-time)編譯器可以在運行時將熱點編譯成本地代碼,速度很快。但是 Java 項目現在變得很大很復雜,因此 JIT 編譯器需要花費較長時間才能熱身完,而且有些 Java 方法還沒法編譯,性能方面也會下降。AoT 編譯就是為了解決這些問題而生的。

AOT 編譯作為實驗特性被引入進來,開發者可以利用新的 jaotc 工具將重點代碼轉換成類似類庫一樣的文件,這樣會大大降低啟動開銷。

這個功能使得 Java 應用在被虛擬機啟動之前能夠先將 Java 類編譯為原生代碼。此功能旨在改進小型和大型應用程序的啟動時間,同時對峰值性能的影響很小。

該功能目前仍處于試驗階段,希望java10能有一個更穩定的版本。

jaotc詳見:http://blog.csdn.net/hj7jay/article/details/54580038

297: Unified arm32/arm64 Port

arm 32和arm 64的統一熱點端口集成到JDK中。

為arm 32和arm 64提供了C1和C2支持,使其與其他體系結構保持一致。代碼已合并到aarch32項目區域中單獨存儲庫中的JDK 9樹中。

Oracle打算開放ARM端口的消息已于2016年8月23日在aarch 32郵件列表中公布,并且aarch 32郵件列表中有幾個討論線索。

298: Remove Demos and Samples

刪除過時和未維護的演示和示例,其目的不是創建新的或替換的演示和示例。

JDK / src / demo和JDK / src / sample中的大多數現有演示和示例都已過時且未維護,因此對處理JDK本身的開發人員或更廣泛的Java社區都不再有用。它們的源代碼不再代表Java編程語言和Java SE平臺的最新使用情況,也沒有更新它們的計劃。更好的示例代碼可以從許多其他來源獲得,例如在更廣泛的社區中發布的許多文章、書籍和演示文稿中

299: Reorganize Documentation

重新組織JDK文檔的結構,包括源存儲庫和生成的文檔。

目標

為生成的“文檔”映像正式定義一個組織,包括API規范、手冊頁(可視為工具規范)和其他JDK規范。

將javadoc工具生成的當前20多組文檔合并到JDK映像的單個API規范集合中。

為源存儲庫中存在的非API規范定義一個組織,以便根據需要隨源代碼一起更新這些規范,并可以輕松地將其包括在生成的“文檔”映像中。


來源:頭條科技

作者:不宅的技術男     


? 西安聚合軟件有限公司 2015 All Rights Reserved. 陜ICP備12003568號-1
网上百家 乐的真实骗局