建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
一、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
