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實戰聯盟 的文章
