Oracle的釋出週期縮短，即以後每半年一個版本，即目前2018年3月份，JDK10，2018年9月份，可能會有新的版本，有很高概率是JDK11。

Oracle 釋出歷史圖

JavaFX從JDK分離為獨立模組

Oracle 近日在其官方部落格宣佈，從 JDK 11 開始，JavaFX 將作為獨立模組從 JDK 中分離出來，以使 JavaFX 更易於被採用。該調整將降低新貢獻者參與 OpenJFX 開源社群的門檻。

JavaFX 於 JavaOne 2007 大會上首次對外公佈，並被迅速拿來與 Adobe Flex 和 Microsoft Silverlight 做比較。該技術於 2011 年完全開源，並在一年後成為 Oracle JDK 的一部分。

Oracle 解釋稱，隨著 Java SE 9 模組系統的出現，是時候將 JavaFX 與 JDK 分離開來，以便讓 JavaFX 可以單獨下載使用。這將使使用 JavaFX 框架的開發人員獲得更多的自由度和靈活性。而且，隨著 JDK 開發團隊的工作重點主要放在其快速版本迭代上，JavaFX 需要除 Oracle 之外，更多其他 OpenJFX 社群的貢獻力量驅動。

有其他JEP進入JDK11

最新訊息顯示，可能還有另外一個 JEP 會進入 JDK 11。根據日程安排，這可能是進入 JDK 11 的最後一項重大更改，所以請仔細閱讀。

JEP 332：傳輸層安全協議(TLS) 1.3

TLS 協議最近進行了一次重大的改進，與以前的版本相比，提升了安全性和效能。而為了保持競爭力和安全性，JDK 需要支援 TLS 1.3 以遵循最新標準。

最新版本的 TLS 使得其以前的所有版本都過時，並且不直接向後相容。如果 JDK 希望保留相關性，則需要升級到 TLS 1.3。而這個 JEP 的主要目標也不是支援 TLS 1.3 的每項特性，而是支援最小的可互操作和相容的 TLS 1.3 實現。

JDK11已確定的15個JEP完整列表

181: 基於巢狀的訪問控制(Nest-Based Access Control)

309: 動態類檔案常量(Dynamic Class-File Constants)

315: 改進 Aarch64 Intrinsics(Improve Aarch64 Intrinsics)

318:Epsilon— 一個無操作的垃圾收集器(Epsilon: A No-OpGarbageCollector)

320: 刪除Java EE和CORBA模組(RemovetheJava EEandCORBAModules)

321: HTTP Client (Standard)

323: 用於 Lambda 引數的區域性變數語法(Local-Variable Syntax for Lambda Parameters)

324: Curve25519 和 Curve448 演算法的金鑰協議(Key Agreement with Curve25519 and Curve448)

327: Unicode 10

328: Flight Recorder

329: ChaCha20 和 Poly1305 加密演算法(ChaCha20 and Poly1305 Cryptographic Algorithms)

330: 啟動單一檔案的原始碼程式(LaunchSingle-File Source-Code Programs)

331: Low-Overhead Heap Profiling

333: 處於試驗階段的可伸縮低延遲垃圾收集器 ZGC: A Scalable Low-LatencyGarbageCollector(Experimental)

336: 棄用 Pack200 工具和API(Deprecate the Pack200 Tools andAPI)

JDK11優缺點

好處：

JDK的快速更新，一定程度上迎合了開發者及現在技術的發展潮流，同時也使JDK快速地應對市場的。並且，大版本的更新是不需要過多地考慮相容性問題，一定程度上是不用考慮相容性，所以JDK9才有了版本的劃分（機智的選擇）

不足：

以前的JDK都是很長時間才釋出一個版本，並且，小版本間修復安全性問題及小BUG，不會存在相容性問題。但是現在不一樣了，對於開發人員來說，學習成本大大增加，短期釋出版本，長期釋出版本。

尤其是對於那些已經完全適應了老版本開發的程式設計師，這完全是個顛覆性的改變，很難去適應，估計也很難去改變，可惜，時代的車輪，不知道會轉向哪裡

對於廣大的JAVA開發人員及相關的運維人員，就個人而言，我強烈建議，使用Oracle官網提供支援的JDK版本，尤其是生產環境。

更多精彩內容關注“IT實戰聯盟”公*眾*號哦