新聞中心
一、JDK 與 JRE 的關(guān)系

JDK :JavaDevelopmentKit (Java開(kāi)發(fā)工具包)
JRE :JavaRuntimeEnvironment (Java運(yùn)行環(huán)境)
說(shuō)明:
JDK = JRE + 開(kāi)發(fā)工具集(例如Javac編譯工具等)
JRE = JVM + Java SE標(biāo)準(zhǔn)類(lèi)庫(kù)
二、JDK 8 的目錄結(jié)構(gòu)
說(shuō)明:
bin 目錄包含命令行開(kāi)發(fā)和調(diào)試工具,如javac,jar和javadoc。
include目錄包含在編譯本地代碼時(shí)使用的C/C++頭文件
lib 目錄包含JDK工具的幾個(gè)JAR和其他類(lèi)型的文件。 它有一個(gè)tools.jar文件,其中包含javac編譯器的Java類(lèi)
jre/bin 目錄包含基本命令,如java命令。 在Windows平臺(tái)上,它包含系統(tǒng)的運(yùn)行時(shí)動(dòng)態(tài)鏈接庫(kù)(DLL)。
jre/lib 目錄包含用戶(hù)可編輯的配置文件,如.properties和.policy文件。包含幾個(gè)JAR。 rt.jar文件包含運(yùn)行時(shí)的Java類(lèi)和資源文件。
三、JDK 9 的目錄結(jié)構(gòu)
說(shuō)明:
沒(méi)有名為jre的子目錄
bin 目錄包含所有命令。 在Windows平臺(tái)上,它繼續(xù)包含系統(tǒng)的運(yùn)行時(shí)動(dòng)態(tài)鏈接庫(kù)。
conf 目錄包含用戶(hù)可編輯的配置文件,例如以前位于jrelib目錄中的.properties和.policy文件
include 目錄包含要在以前編譯本地代碼時(shí)使用的C/C++頭文件。 它只存在于JDK中
jmods 目錄包含JMOD格式的平臺(tái)模塊。 創(chuàng)建自定義運(yùn)行時(shí)映像時(shí)需要它。 它只存在于JDK中
legal 目錄包含法律聲明
lib 目錄包含非Windows平臺(tái)上的動(dòng)態(tài)鏈接本地庫(kù)。 其子目錄和文件不應(yīng)由開(kāi)發(fā)人員直接編輯或使用
四、Java9新增特性:
102: Process API Updates
進(jìn)程操作API 升級(jí),提升對(duì)操作系統(tǒng)進(jìn)程的控制和管理。
新增的
java.lang.ProcessHandle
類(lèi)豐富了對(duì)進(jìn)程的操作,同時(shí)原有的
java.lang.Process
類(lèi)的功能也被加強(qiáng)了。
在Java很早的版本中,提供了Process這樣的API可以獲得進(jìn)程的一些信息,包括runtime,甚至是用它來(lái)執(zhí)行當(dāng)前主機(jī)的一些命令,但是請(qǐng)大家思考一個(gè)問(wèn)題,你如何獲得你當(dāng)前Java運(yùn)行程序的PID?很顯然通過(guò)Process是無(wú)法獲得的,需要借助于JMX才能得到,但是在這一次的增強(qiáng)中,你將會(huì)很輕松的得到這樣的信息,我們來(lái)看一個(gè)簡(jiǎn)單的例子:
上面有大量的Optional,這是Java 8中的API,同樣在Java 9中對(duì)其進(jìn)行了增強(qiáng)。
已經(jīng)獲取到了JVM的進(jìn)程,我們?cè)撊绾螌⒃撨M(jìn)程優(yōu)雅的停掉呢?下面的代碼給出了答案
110: HTTP 2 Client
就目前而言,JDK提供的Http訪問(wèn)功能,幾乎都需要依賴(lài)于HttpURLConnection,但是這個(gè)類(lèi)大家在寫(xiě)代碼的時(shí)候很少使用,我們一般都會(huì)選擇Apache的Http Client,此次在Java 9的版本中引入了一個(gè)新的package:java.net.http,里面提供了對(duì)Http訪問(wèn)很好的支持,不僅支持Http1.1而且還支持HTTP2,以及WebSocket,據(jù)說(shuō)性能可以超過(guò)Apache HttpClient,Netty,Jetty,簡(jiǎn)單的來(lái)看一個(gè)代碼片段:
通過(guò)上面的一小段代碼,我們也發(fā)現(xiàn)了Java 9對(duì)斷言機(jī)制同樣增加了一些增強(qiáng),多說(shuō)一些題外話,我們目前的系統(tǒng)中運(yùn)行一個(gè)嚴(yán)重依賴(lài)于Hive beelineServer的程序,beeline server不是很穩(wěn)定,經(jīng)常出現(xiàn)卡頓,甚至假死,假死后也不回復(fù)的問(wèn)題,這樣就導(dǎo)致我們的程序也會(huì)出現(xiàn)卡頓,如果運(yùn)維人員不對(duì)其進(jìn)行清理,系統(tǒng)運(yùn)行幾個(gè)月之后會(huì)發(fā)現(xiàn)很多僵尸進(jìn)程,于是增加一個(gè)獲取當(dāng)前JVM PID的功能,然后判斷到超過(guò)給定的時(shí)間對(duì)其進(jìn)行主動(dòng)殺死,完全是程序內(nèi)部的行為,但是獲取PID就必須借助于JMX的動(dòng)作,另外殺死它也必須借助于操作系統(tǒng)的命令,諸如kill這樣的命令,顯得非常的麻煩,但是Java 9的方式明顯要優(yōu)雅方便許多。
143: Improve Contended Locking
優(yōu)化競(jìng)爭(zhēng)鎖的性能
能夠改善程序運(yùn)行時(shí)的多線程同步效率。
158: Unified JVM Logging
統(tǒng)一 JVM 日志
日志是解決問(wèn)題的唯一有效途徑:曾經(jīng)很難知道導(dǎo)致JVM性能問(wèn)題和導(dǎo)致JVM崩潰的根本原因。不同的JVM日志的碎片化和日志選項(xiàng)(例如:JVM組件對(duì)于日志使用的是不同的機(jī)制和規(guī)則),這使得JVM難以進(jìn)行調(diào)試。
解決該問(wèn)題最佳方法:對(duì)所有的JVM組件引入一個(gè)單一的系統(tǒng),這些JVM組件支持細(xì)粒度的和易配置的JVM日志
165: Compiler Control
193: Variable Handles
操作內(nèi)存,用來(lái)替代sun.misc.Unsafe。操作內(nèi)存更安全,且性能相同或相似的等效sun.misc.unsafe操作。
在JDK 9中提供了一個(gè)新的包,叫做java.lang.invoke里面有一系列很重要的類(lèi)比如VarHandler和MethodHandles,提供了類(lèi)似于原子操作以及Unsafe操作的功能。
197: Segmented Code Cache
代碼分段緩存
Java 9的另一個(gè)性能提升來(lái)自于JIT(Just-in-time)編譯器。當(dāng)某段代碼被大量重復(fù)執(zhí)行的時(shí)候, 虛擬機(jī)會(huì)把這段代碼編譯成機(jī)器碼(native code)并儲(chǔ)存在代碼緩存里面, 繼而通過(guò)訪問(wèn)緩存中不同分段的代碼來(lái)提升編譯器的效率。代碼分段緩存機(jī)制將會(huì)提升許多方面的性能,如當(dāng)JVM進(jìn)行垃圾回收掃描的時(shí)候,就可以直接跳過(guò)永駐代碼,從而提升效率
JDK 9 中的代碼段在 Segmented Code Cache 的作用下,可以被更加細(xì)分,而且每個(gè)代碼段還可以包括特定類(lèi)型的編譯代碼,這個(gè)功能同樣也有望提升 Java 9 性能。
這個(gè)特性一般不會(huì)在 Java 代碼中直接使用,它通過(guò)對(duì)本地編譯代碼(即代碼緩存)進(jìn)行更好的組織,讓 JRE 的運(yùn)行效率有所提高。
198: Light-Weight JSON API
盡管目前有多種處理JSON的Java工具(如Google的Gson、阿里巴巴的FastJson、IBM的Json4J等),但JSON API是Java語(yǔ)言的一部分,輕量并且運(yùn)用了Java 8的新特性。JSON API將放在java.util包里一起發(fā)布,這樣,開(kāi)發(fā)者就可以直接使用JDK而無(wú)需再引入第三方JSON工具包了
199: Smart Java Compilation, Phase Two
改進(jìn)sjavac工具的穩(wěn)定性和可移植性,使其可以更好地用于大型項(xiàng)目的構(gòu)建。
智能Java編譯工具(sjavac)的第一階段始于JEP139這個(gè)項(xiàng)目, 用于在多核處理器情況下提升JDK的編譯速度。如今,這個(gè)項(xiàng)目已經(jīng)進(jìn)入第二階段即JEP199, 其目的是改進(jìn)Java編譯工具,并取代目前JDK編譯工具javac,繼而成為Java環(huán)境默認(rèn)的通用的智能編譯工具
200: The Modular JDK
Java 9中最重要的功能,毫無(wú)疑問(wèn)就是模塊化(Module),代碼名字叫做Jigsaw(拉鋸),這個(gè)拉鋸項(xiàng)目拉了幾年,終于要把龐大冗余的Java鋸成一個(gè)個(gè)的Module,方便開(kāi)發(fā)和部署。熟悉Java的同學(xué),都知道JRE有一個(gè)超級(jí)大rt.jar(例如,Java 8的rt.jar中有65M),運(yùn)行一個(gè)hello world,你也需要一個(gè)數(shù)百兆的JRE環(huán)境,如果在J2EE環(huán)境,情況將變得復(fù)雜無(wú)比
201: Modular Source Code
211: Elide Deprecation Warnings on Import Statements
212: Resolve Lint and Doclint Warnings
213: Milling Project Coin
接口的私有方法
Java 8中規(guī)定接口中的方法除了抽象方法之外,還可以定義靜態(tài)方法和默認(rèn)的方法。一定程度上,擴(kuò)展了接口的功能,此時(shí)的接口更像是一個(gè)抽象類(lèi)。
在Java 9中,接口更加的靈活和強(qiáng)大,連方法的訪問(wèn)權(quán)限修飾符都可以聲明為private的了,此時(shí)方法將不會(huì)成為你對(duì)外暴露的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
模塊化運(yùn)行時(shí)鏡像
221: Simplified Doclet API
222: jshell: The Java Shell (Read-Eval-Print Loop)
交互式命令行
簡(jiǎn)稱(chēng) JShell,方便對(duì)程序進(jìn)行調(diào)試,以及快速檢驗(yàn) API 的可行性無(wú)須無(wú)須創(chuàng)建一個(gè)項(xiàng)目來(lái)學(xué)習(xí) API,打開(kāi) JShell 即可。
在Java 8 出來(lái)的時(shí)候,很多人都喊著,這是要搶奪Scala等基于JVM動(dòng)態(tài)語(yǔ)言的市場(chǎng)啊,其中有人給出了一個(gè)Java做不到的方向,那就是Scala可以當(dāng)作腳本語(yǔ)言,Java可以么?很明顯在此之前Java不行,ta也不具備動(dòng)態(tài)性,但是此次Java 9 卻讓Java也可以像腳本語(yǔ)言一樣來(lái)運(yùn)行了,主要得益于JShell,我們來(lái)看一下這個(gè)演示
這是我們?cè)贘shell這個(gè)控制臺(tái)下運(yùn)行,我們?nèi)绾芜\(yùn)行腳本文件呢?
223: New Version-String Scheme
224: HTML5 Javadoc
jdk 8 :生成的java幫助文檔是在HTML 4 中,而HTML 4 已經(jīng)是很久的標(biāo)準(zhǔn)了。
jdk 9 :javadoc的輸出,現(xiàn)在符合兼容HTML 5 標(biāo)準(zhǔn)。
下圖是java8 中生成的html頁(yè)面,如果想要找到一些類(lèi)文檔,必須在google中搜索
下圖是在java 9 中,添加了一個(gè)搜索框。
225: Javadoc Search
226: UTF-8 Property Files
屬性文件支持 UTF-8 編碼
ResourceBundle 的缺省編碼問(wèn)題一直是被吐槽的對(duì)象,非英文字符被轉(zhuǎn)碼為看不懂的形式,嚴(yán)重?fù)p害了代碼的可讀性。從 Java 9 開(kāi)始,ResourceBundle 默認(rèn)編碼為 UTF-8。
227: Unicode 7.0
JDK9升級(jí)現(xiàn)有的平臺(tái)APIs以支持Unicode標(biāo)準(zhǔn)的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 中附帶了一個(gè) Nashorn 的 parser API,它的目標(biāo)是 Java 在本地 JVM 中實(shí)現(xiàn)輕量級(jí)高性能 JS runtime。這個(gè)新特性可以保障 Java 9 更好的融合 JavaScript 和 Java 的兩方之力。
237: Linux/AArch64 Port
連接到Linux / AArch64的端口。
AArch64是ARM控股公司推出的新處理器體系結(jié)構(gòu)。它與32位ARM處理器架構(gòu)不同,實(shí)際上是一個(gè)完全的重新設(shè)計(jì)。它需要一個(gè)新的OpenJDK端口
238: Multi-Release JAR Files
當(dāng)一個(gè)新版本的Java出現(xiàn)的時(shí)候,你的庫(kù)用戶(hù)要花費(fèi)數(shù)年時(shí)間才會(huì)切換到這個(gè)新的版本。這就意味著庫(kù)得去向后兼容你想要支持的最老的Java版本(許多情況下就是Java 6 或者 Java7)。這實(shí)際上意味著未來(lái)的很長(zhǎng)一段時(shí)間,你都不能在庫(kù)中運(yùn)用Java 9所提供的新特性。幸運(yùn)的是,多版本兼容jar功能能讓你創(chuàng)建僅在特定版本的Java環(huán)境中運(yùn)行庫(kù)程序選擇使用的class版本。
240: Remove the JVM TI hprof Agent
從JDK中刪除高性能代理。
J2SE中提供了一個(gè)簡(jiǎn)單的命令行工具來(lái)對(duì)java程序的cpu和heap進(jìn)行 profiling,叫做HPROF。HPROF實(shí)際上是JVM中的一個(gè)native的庫(kù)。該工具已被更好的替代品所取代。
241: Remove the jhat Tool
刪除過(guò)時(shí)的jhat工具。
jhat是在JDK 6中基于Java . net帽子項(xiàng)目添加的。jhat是一個(gè)實(shí)驗(yàn)性的、不受支持的、過(guò)時(shí)的工具。高級(jí)堆可視化工具和分析器已經(jīng)使用多年。
243: Java-Level JVM Compiler Interface
動(dòng)態(tài)編譯器
對(duì)于整個(gè)編程語(yǔ)言的發(fā)展,可能都具有非常重要的意義,雖然未必引起了廣泛關(guān)注。目前 Graal Core API 已經(jīng)被集成進(jìn)入 Java 9,雖然還只是初始一小步,但是完全用 Java 語(yǔ)言來(lái)實(shí)現(xiàn)的可靠的、高性能的動(dòng)態(tài)編譯器,似乎不再是遙不可及。
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 成為默認(rèn)的垃圾收集器
G1 進(jìn)一步減少了 GC 時(shí)的停頓時(shí)間(GC pause time),其實(shí)它從 JDK 8u40 開(kāi)始就已經(jīng)十分完善,足以作為默認(rèn)的垃圾收集器了。
249: OCSP Stapling for TLS
250: Store Interned Strings in CDS Archives
251: Multi-Resolution Images
接口java.awt.image.MultiResolutionImage封裝了一系列的不同分辨率圖像到一個(gè)單獨(dú)對(duì)象的API,我么可以根據(jù)給定的DPI 矩陣獲取resolution-specific,看一下下面的代碼片段:
252: Use CLDR Locale Data by Default
253: Prepare JavaFX UI Controls & CSS APIs for Modularization
254: Compact Strings
優(yōu)化字符串占用空間
在很多應(yīng)用當(dāng)中,字符串已經(jīng)成為一個(gè)消耗內(nèi)存的主要部分。通過(guò)優(yōu)化字符串的占用空間,應(yīng)用的內(nèi)存使用可以得到明顯改善。
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 模塊化-重大特性
該項(xiàng)目主要的目的是為更小的設(shè)備提供可伸縮性,改進(jìn) JDK 和 Java SE 的安全性,對(duì)大型應(yīng)用的性能提升以及更易于構(gòu)建。這個(gè)功能會(huì)使 JDK、run-time images 以及 Java 源代碼等模塊化,甚至開(kāi)發(fā)者還可以創(chuàng)建自己的模塊來(lái)簡(jiǎn)化代碼
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
集合工廠方法:快速創(chuàng)建只讀集合
270: Reserved Stack Areas for Critical Sections
271: Unified GC Logging
該特性為JVM的所有組件引入了一個(gè)通用的日志系統(tǒng),提供了JVM日志的基礎(chǔ)設(shè)施,你可以不用專(zhuān)門(mén)為了打印某些日志而添加一些專(zhuān)門(mén)的標(biāo)簽,只需要使用統(tǒng)一的log指令即可,比如:
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中大量對(duì)象的附加測(cè)試
279: Improve Test-Failure Troubleshooting
自動(dòng)收集診斷信息,以便在測(cè)試失敗和超時(shí)的情況下進(jìn)一步排除故障。
280: Indify String Concatenation
281: HotSpot C++ Unit-Test Framework
282: jlink: The Java Linker
Java連接器
連接器負(fù)責(zé)高層會(huì)話,如http會(huì)話。連接器框架組件,基于NIO開(kāi)發(fā),用于javaiis http服務(wù)器項(xiàng)目。
284: New HotSpot Build System
使用構(gòu)建基礎(chǔ)架構(gòu)重寫(xiě)熱點(diǎn)構(gòu)建系統(tǒng)。
本項(xiàng)目的目標(biāo)是用一個(gè)新的、簡(jiǎn)化得多的基于build - infra框架的構(gòu)建系統(tǒng)替換當(dāng)前的構(gòu)建系統(tǒng)。更具體地說(shuō):
利用build - infra框架中提供的功能,最大限度地減少代碼重復(fù)。
簡(jiǎn)化熱點(diǎn)構(gòu)建系統(tǒng)以提供更易于維護(hù)的代碼庫(kù),并降低閾值以供將來(lái)改進(jìn)。
285: Spin-Wait Hints
定義API以允許Java代碼提示正在執(zhí)行旋轉(zhuǎn)循環(huán),即自旋等待提示。
定義一個(gè)API,允許Java代碼提示運(yùn)行時(shí)系統(tǒng)它處于旋轉(zhuǎn)循環(huán)中。API將是一個(gè)純提示,不包含語(yǔ)義行為需求(例如,無(wú)操作是有效的實(shí)現(xiàn))。允許JVM受益于在某些硬件平臺(tái)上可能有用的自旋循環(huán)特定行為。在JDK中提供無(wú)操作實(shí)現(xiàn)和固有實(shí)現(xiàn),并在至少一個(gè)主要硬件平臺(tái)上演示執(zhí)行優(yōu)勢(shì)。
287: SHA-3 Hash Algorithms
實(shí)現(xiàn)NIST FIPS 202中指定的SHA - 3加密散列函數(shù)(僅字節(jié))。
SHA - 2發(fā)布于10多年前,雖然尚未證明對(duì)SHA - 2的重大攻擊,但NIST認(rèn)為需要一種不同的加密散列函數(shù)來(lái)替代SHA - 2。九年來(lái),SHA - 3是NIST利用公開(kāi)競(jìng)爭(zhēng)和審查過(guò)程開(kāi)發(fā)的第一個(gè)加密哈希算法。FIPS 202 " SHA - 3標(biāo)準(zhǔn):基于排列的散列和可擴(kuò)展輸出函數(shù)"于2015年8月作為標(biāo)準(zhǔn)定稿。當(dāng)FIPS 202還是草稿時(shí),諸如BouncyCastle之類(lèi)的加密供應(yīng)商開(kāi)始支持SHA - 3。Solaris還將在即將發(fā)布的Solaris 12.0版本中支持SHA - 3。由于哈希函數(shù)在安全應(yīng)用程序中廣泛使用,并且其他供應(yīng)商已經(jīng)添加了SHA - 3實(shí)現(xiàn),因此在JDK中為SHA - 3提供支持非常重要。
288: Disable SHA-1 Certificates
通過(guò)提供更靈活的機(jī)制來(lái)禁用具有基于SHA - 1簽名的x . 509證書(shū)鏈,改進(jìn)了JDK的安全配置。
目標(biāo)不是禁用SHA - 1證書(shū)的所有用法。只有通過(guò)CertPathValidator和CertPathBuilder API的PKIX實(shí)現(xiàn)以及TrustManagerFactory API的SunX509和PKIX實(shí)現(xiàn)驗(yàn)證的X.509證書(shū)鏈才受限制。其他用途(解析等)。)中的證書(shū)不受影響。CertPathValidator、CertPathBuilder和TrustManagerFactory的第三方實(shí)現(xiàn)直接負(fù)責(zé)實(shí)施它們自己的限制。
基于SHA - 1的數(shù)字簽名算法的使用由于沖突攻擊的風(fēng)險(xiǎn)而日益成為安全問(wèn)題。NIST在SP 800 - 57第1部分中建議不再使用SHA - 1對(duì)數(shù)據(jù)應(yīng)用數(shù)字簽名。CA / Browser論壇對(duì)公眾信任的SSL證書(shū)的基線要求規(guī)定,自2016年1月1日起,證書(shū)頒發(fā)機(jī)構(gòu)不得使用SHA - 1頒發(fā)任何從屬CA或訂戶(hù)證書(shū)。其他軟件供應(yīng)商(谷歌、微軟、Mozilla、蘋(píng)果)已經(jīng)公布了在證書(shū)中對(duì)SHA - 1進(jìn)行貶值的計(jì)劃。在JDK中,x . 509證書(shū)鏈用于驗(yàn)證TLS中的服務(wù)器和客戶(hù)端以及驗(yàn)證簽名代碼的完整性和作者
289: Deprecate the Applet API
Applet API 被標(biāo)記為為過(guò)時(shí)。
要在web瀏覽器中運(yùn)行Java小程序,需要使用瀏覽器插件。然而,截至2015年底,許多瀏覽器供應(yīng)商要么已經(jīng)取消了插件支持,要么宣布了取消插件支持的時(shí)間表。一旦瀏覽器插件消失,就沒(méi)有理由使用Applet API。
290: Filter Incoming Serialization Data
291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector
Java 9 或?qū)⒎艞?CMS(并發(fā)標(biāo)記清除垃圾收集器)
取消對(duì)CMS的支持,然后刪除CMS代碼,或者至少更徹底地分離CMS代碼,將減少GC代碼庫(kù)的維護(hù)負(fù)擔(dān),并加快新的開(kāi)發(fā)。從長(zhǎng)遠(yuǎn)來(lái)看,G1垃圾收集器將取代CMS的大多數(shù)用途。
新版本未指定將刪除CMS支持的主要版本。何時(shí)執(zhí)行此操作,取決于G1收集器在多大程度上被證明是CMS的合適替代品。同時(shí),鼓勵(lì)CMS用戶(hù)遷移到G1收集器( - XX : + UseG1GC )。
但是從經(jīng)驗(yàn)來(lái)看,很多 Java 應(yīng)用選擇的是 CMS+ParNew,而且很多應(yīng)用針對(duì) CMS 的行為做了優(yōu)化?,F(xiàn)在宣布去掉 CMS,或許還為時(shí)過(guò)早。
292: Implement Selected ECMAScript 6 Features in Nashorn
ECMAScript 6于2015年6月發(fā)布。到目前為止,還沒(méi)有一個(gè)JavaScript引擎提供對(duì)ES6的完整支持,但是包括Google V8、Mozilla蜘蛛猴和JavaScript core在內(nèi)的主要引擎最近在實(shí)現(xiàn)ES6方面取得了重大進(jìn)展。
Nashorn 項(xiàng)目在 JDK 9 中得到改進(jìn),它為 Java 提供輕量級(jí)的 Javascript 運(yùn)行時(shí)。Nashorn 項(xiàng)目跟隨 Netscape 的 Rhino 項(xiàng)目,目的是為了在 Java 中實(shí)現(xiàn)一個(gè)高性能但輕量級(jí)的 Javascript 運(yùn)行時(shí)。Nashorn 項(xiàng)目使得 Java 應(yīng)用能夠嵌入 Javascript。它在 JDK 8 中為 Java 提供一個(gè) Javascript 引擎。
JDK 9 包含一個(gè)用來(lái)解析Nashorn 的ECMAScript 語(yǔ)法樹(shù)的API。這個(gè) API 使得 IDE 和服務(wù)端框架不需要依賴(lài) Nashorn 項(xiàng)目的內(nèi)部實(shí)現(xiàn)類(lèi),就能夠分析 ECMAScript 代碼。
294: Linux/s390x Port
s390x (也稱(chēng)為“系統(tǒng)z”或“z /體系結(jié)構(gòu)”)是由IBM開(kāi)發(fā)和支持的大型機(jī)體系結(jié)構(gòu)。包括Ubuntu、RHEL / Fedora和SuSE在內(nèi)的幾個(gè)Linux發(fā)行版在s390上運(yùn)行。
目前的云部署,包括TomEE、Cassandra、Spark、Hadoop和Neo4j等軟件包,嚴(yán)重依賴(lài)Java。因?yàn)榇蠖鄶?shù)軟件包都是開(kāi)源的,所以它們?cè)贠penJDK上運(yùn)行得最好,而OpenJDK目前對(duì)Linux / s390x不可用。
目前,零端口可用于在Linux / s390x上運(yùn)行JDK,但速度很慢(因?yàn)樗皇褂门f的、棄用的c++解釋器),并且測(cè)試不太好。它不是運(yùn)行應(yīng)用程序服務(wù)器或用Java編寫(xiě)的數(shù)據(jù)庫(kù)應(yīng)用程序等工作負(fù)載的真正替代方案。
IBM的Linux開(kāi)發(fā)工具包也可用于Linux / s390x,但它目前不是開(kāi)源的,Java應(yīng)用程序通常需要一些配置/調(diào)優(yōu)才能與它一起運(yùn)行。此外,它不能用于測(cè)試即將發(fā)布的Java版本的新功能,因?yàn)樗鼉H在JDK本身是GA之后發(fā)布。
SAP有一個(gè)完整的(即模板解釋器、C1和C2 JIT )和經(jīng)過(guò)認(rèn)證的( Java SE 1.4 - 8 ) s390x端口,已在生產(chǎn)中使用多年。
295: Ahead-of-Time Compilation
AOT 編譯
JIT(Just-in-time)編譯器可以在運(yùn)行時(shí)將熱點(diǎn)編譯成本地代碼,速度很快。但是 Java 項(xiàng)目現(xiàn)在變得很大很復(fù)雜,因此 JIT 編譯器需要花費(fèi)較長(zhǎng)時(shí)間才能熱身完,而且有些 Java 方法還沒(méi)法編譯,性能方面也會(huì)下降。AoT 編譯就是為了解決這些問(wèn)題而生的。
AOT 編譯作為實(shí)驗(yàn)特性被引入進(jìn)來(lái),開(kāi)發(fā)者可以利用新的 jaotc 工具將重點(diǎn)代碼轉(zhuǎn)換成類(lèi)似類(lèi)庫(kù)一樣的文件,這樣會(huì)大大降低啟動(dòng)開(kāi)銷(xiāo)。
這個(gè)功能使得 Java 應(yīng)用在被虛擬機(jī)啟動(dòng)之前能夠先將 Java 類(lèi)編譯為原生代碼。此功能旨在改進(jìn)小型和大型應(yīng)用程序的啟動(dòng)時(shí)間,同時(shí)對(duì)峰值性能的影響很小。
該功能目前仍處于試驗(yàn)階段,希望java10能有一個(gè)更穩(wěn)定的版本。
jaotc詳見(jiàn):http://blog.csdn.net/hj7jay/article/details/54580038
297: Unified arm32/arm64 Port
arm 32和arm 64的統(tǒng)一熱點(diǎn)端口集成到JDK中。
為arm 32和arm 64提供了C1和C2支持,使其與其他體系結(jié)構(gòu)保持一致。代碼已合并到aarch32項(xiàng)目區(qū)域中單獨(dú)存儲(chǔ)庫(kù)中的JDK 9樹(shù)中。
Oracle打算開(kāi)放ARM端口的消息已于2016年8月23日在aarch 32郵件列表中公布,并且aarch 32郵件列表中有幾個(gè)討論線索。
298: Remove Demos and Samples
刪除過(guò)時(shí)和未維護(hù)的演示和示例,其目的不是創(chuàng)建新的或替換的演示和示例。
JDK / src / demo和JDK / src / sample中的大多數(shù)現(xiàn)有演示和示例都已過(guò)時(shí)且未維護(hù),因此對(duì)處理JDK本身的開(kāi)發(fā)人員或更廣泛的Java社區(qū)都不再有用。它們的源代碼不再代表Java編程語(yǔ)言和Java SE平臺(tái)的最新使用情況,也沒(méi)有更新它們的計(jì)劃。更好的示例代碼可以從許多其他來(lái)源獲得,例如在更廣泛的社區(qū)中發(fā)布的許多文章、書(shū)籍和演示文稿中
299: Reorganize Documentation
重新組織JDK文檔的結(jié)構(gòu),包括源存儲(chǔ)庫(kù)和生成的文檔。
目標(biāo)
為生成的“文檔”映像正式定義一個(gè)組織,包括API規(guī)范、手冊(cè)頁(yè)(可視為工具規(guī)范)和其他JDK規(guī)范。
將javadoc工具生成的當(dāng)前20多組文檔合并到JDK映像的單個(gè)API規(guī)范集合中。
為源存儲(chǔ)庫(kù)中存在的非API規(guī)范定義一個(gè)組織,以便根據(jù)需要隨源代碼一起更新這些規(guī)范,并可以輕松地將其包括在生成的“文檔”映像中。
推薦相關(guān)文章:
《Java8最值得學(xué)習(xí)的新特性:Lambda,Stream API》
《java9 150多項(xiàng)新特性,大改版,內(nèi)附源碼,實(shí)戰(zhàn)解析,收藏!》
參考:
http://www.infoq.com/cn/articles/is-java-out-of-date
http://blog.csdn.net/hj7jay/article/details/54580038
http://blog.csdn.net/sijidou112/article/details/46632793
https://zhuanlan.zhihu.com/p/24800180
當(dāng)前名稱(chēng):Java9新特性逐項(xiàng)解析,總有一項(xiàng)get到你的點(diǎn)
瀏覽地址:http://fisionsoft.com.cn/article/coopgie.html


咨詢(xún)
建站咨詢(xún)
