一、JDK 與 JRE 的關系

JDK :JavaDevelopmentKit (Java開發(fā)工具包)

JRE :JavaRuntimeEnvironment (Java運行環(huán)境)

說明：

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

JRE = JVM + Java SE標準類庫

---

二、JDK 8 的目錄結構

說明：

bin 目錄包含命令行開發(fā)和調(diào)試工具，如javac，jar和javadoc。

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

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

jre/bin 目錄包含基本命令，如java命令。 在Windows平臺上，它包含系統(tǒng)的運行時動態(tài)鏈接庫（DLL）。

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

---

三、JDK 9 的目錄結構

說明：

沒有名為jre的子目錄

bin 目錄包含所有命令。 在Windows平臺上，它繼續(xù)包含系統(tǒng)的運行時動態(tài)鏈接庫。

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

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

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

legal 目錄包含法律聲明

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

---

四、Java9新增特性：

102: Process API Updates

進程操作API 升級，提升對操作系統(tǒng)進程的控制和管理。

新增的

java.lang.ProcessHandle

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

java.lang.Process

類的功能也被加強了。

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

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

已經(jīng)獲取到了JVM的進程，我們該如何將該進程優(yōu)雅的停掉呢？下面的代碼給出了答案

110: HTTP 2 Client

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

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

143: Improve Contended Locking

優(yōu)化競爭鎖的性能

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

158: Unified JVM Logging

統(tǒng)一 JVM 日志

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

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

165: Compiler Control

193: Variable Handles

操作內(nèi)存，用來替代sun.misc.Unsafe。操作內(nèi)存更安全，且性能相同或相似的等效sun.misc.unsafe操作。

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

197: Segmented Code Cache

代碼分段緩存

Java 9的另一個性能提升來自于JIT(Just-in-time)編譯器。當某段代碼被大量重復執(zhí)行的時候, 虛擬機會把這段代碼編譯成機器碼(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包里一起發(fā)布，這樣，開發(fā)者就可以直接使用JDK而無需再引入第三方JSON工具包了

199: Smart Java Compilation, Phase Two

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

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

200: The Modular JDK

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

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)方法和默認的方法。一定程度上，擴展了接口的功能，此時的接口更像是一個抽象類。

在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，方便對程序進行調(diào)試，以及快速檢驗 API 的可行性無須無須創(chuàng)建一個項目來學習 API，打開 JShell 即可。

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

這是我們在Jshell這個控制臺下運行，我們?nèi)绾芜\行腳本文件呢？

223: New Version-String Scheme

224: HTML5 Javadoc

jdk 8 ：生成的java幫助文檔是在HTML 4 中，而HTML 4 已經(jīng)是很久的標準了。

jdk 9 ：javadoc的輸出，現(xiàn)在符合兼容HTML 5 標準。

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

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

225: Javadoc Search

226: UTF-8 Property Files

屬性文件支持 UTF-8 編碼

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

227: Unicode 7.0

JDK9升級現(xiàn)有的平臺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 中實現(xiàn)輕量級高性能 JS runtime。這個新特性可以保障 Java 9 更好的融合 JavaScript 和 Java 的兩方之力。

237: Linux/AArch64 Port

連接到Linux / AArch64的端口。

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

238: Multi-Release JAR Files

當一個新版本的Java出現(xiàn)的時候，你的庫用戶要花費數(shù)年時間才會切換到這個新的版本。這就意味著庫得去向后兼容你想要支持的最老的Java版本（許多情況下就是Java 6 或者 Java7）。這實際上意味著未來的很長一段時間，你都不能在庫中運用Java 9所提供的新特性。幸運的是，多版本兼容jar功能能讓你創(chuàng)建僅在特定版本的Java環(huán)境中運行庫程序選擇使用的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是一個實驗性的、不受支持的、過時的工具。高級堆可視化工具和分析器已經(jīng)使用多年。

243: Java-Level JVM Compiler Interface

動態(tài)編譯器

對于整個編程語言的發(fā)展，可能都具有非常重要的意義，雖然未必引起了廣泛關注。目前 Graal Core API 已經(jīng)被集成進入 Java 9，雖然還只是初始一小步，但是完全用 Java 語言來實現(xiàn)的可靠的、高性能的動態(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 成為默認的垃圾收集器

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

249: OCSP Stapling for TLS

250: Store Interned Strings in CDS Archives

251: Multi-Resolution Images

接口java.awt.image.MultiResolutionImage封裝了一系列的不同分辨率圖像到一個單獨對象的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)化字符串占用空間

在很多應用當中，字符串已經(jīng)成為一個消耗內(nèi)存的主要部分。通過優(yōu)化字符串的占用空間，應用的內(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 模塊化-重大特性

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

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的所有組件引入了一個通用的日志系統(tǒng)，提供了JVM日志的基礎設施，你可以不用專門為了打印某些日志而添加一些專門的標簽，只需要使用統(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中大量對象的附加測試

279: Improve Test-Failure Troubleshooting

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

280: Indify String Concatenation

281: HotSpot C++ Unit-Test Framework

282: jlink: The Java Linker

Java連接器

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

284: New HotSpot Build System

使用構建基礎架構重寫熱點構建系統(tǒng)。

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

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

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

285: Spin-Wait Hints

定義API以允許Java代碼提示正在執(zhí)行旋轉循環(huán)，即自旋等待提示。

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

287: SHA-3 Hash Algorithms

實現(xiàn)NIST FIPS 202中指定的SHA - 3加密散列函數(shù)(僅字節(jié))。

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

288: Disable SHA-1 Certificates

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

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

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

289: Deprecate the Applet API

Applet API 被標記為為過時。

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

290: Filter Incoming Serialization Data

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

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

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

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

但是從經(jīng)驗來看，很多 Java 應用選擇的是 CMS+ParNew，而且很多應用針對 CMS 的行為做了優(yōu)化?，F(xiàn)在宣布去掉 CMS，或許還為時過早。

292: Implement Selected ECMAScript 6 Features in Nashorn

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

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

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

294: Linux/s390x Port

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

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

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

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

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

295: Ahead-of-Time Compilation

AOT 編譯

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

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

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

該功能目前仍處于試驗階段，希望java10能有一個更穩(wěn)定的版本。

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

297: Unified arm32/arm64 Port

arm 32和arm 64的統(tǒng)一熱點端口集成到JDK中。

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

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

298: Remove Demos and Samples

刪除過時和未維護的演示和示例，其目的不是創(chuàng)建新的或替換的演示和示例。

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

299: Reorganize Documentation

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

目標

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

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

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

推薦相關文章：

《Java8最值得學習的新特性：Lambda，Stream API》

《java9 150多項新特性，大改版，內(nèi)附源碼，實戰(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