JDK11即将来临，新特性了解一下

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版本，尤其是生产环境。

注意：本文归作者所有，未经作者允许，不得转载