长期支援版本Java 11释出，更新TLS 1.3并加入高效能垃圾回收器
甲骨文提醒开发者，TLS 1.3使用半关闭政策，与TLS 1.2和先前版本都不同，因此原本采用双工关闭政策的应用程式，升级可能遇到相容性问题。
按赞加入iThome粉丝团
文/李建兴 | 2018-09-27发表
Java 10在3月释出时便预告，Java 11将会在9月时到来，并且为长期支援版本，而今甲骨文依照预告释出Java 11，成为从去年宣布每六个月发布新版本计画下的第一个长期支援版本。这个版本重点放在增强开发人员生产力及对先进加密和互联网标准的支援，包括TLS 1.3和HTTP/2。
全球Java开发人员和甲骨文的工程师，透过OpenJDK社群以及JCP的努力下，释出了Java SE 11（JDK 11），从Java SE 8以来，社群增加了超过100个新功能强化，共同发布了JDK 9、10和这次的第11版。
最近传输层安全性协定TLS 1.3标准通过，Java作为企业最爱用开发语言，也正式开始支援TLS 1.3，但新旧版本升级有特别需要注意的地方，官方提到，TLS 1.3使用半关闭政策，而TLS 1.2和先前版本则使用双工关闭政策，因此对于原本依赖双工关闭政策的应用程式，升级到TLS 1.3的时候可能存在相容性问题。TLS 1.3不支援DSA签章算法，当服务器配置仅只使用DSA凭证，则无法升级到TLS 1.3。
TLS 1.3支援的加密套件与TLS 1.2和更早版本都不同，因此当应用程式硬编码加密套件不再提供支援，则可能无法在不修改程式码的情况下直接使用TLS 1.3。另外，TLS 1.3对话恢复和密钥更新行为都和TLS 1.2等早前版本不同，虽然这些改变对相容性影响不大，但是当应用程式依赖TLS协定的交握细节，则可能会存在风险。
Java 11引入了基于巢的存取控制（Nest-Based Access Control ），这个存取控制上下文（Access Control Context）和Java中既有的巢状型别概念一致。在Java SE 11中，Java虚拟机器将类别和接口安排到一个新的存取控制上下文中称为巢，巢允许在逻辑上为相同程式码实体部分的类别和接口，但是却被编译到不同类别档案，也能够存取彼此的私有成员，而不需要编译器插入可存取扩展方法。
这次更新加入了一个实验性的功能，称为可扩展的低延迟垃圾回收器（Scalable Low-Latency Garbage Collector，ZGC），目的在使暂停时间不超过10ms，且暂停时间不随着堆积或是即时配置大小而改变，并有能力处理数百MB到数TB堆积的能力。由于ZGC的核心是并行垃圾回收器，而这代表着当Java执行绪还正在运作的时候，所有诸如参照处理或是字串表清除等繁重的工作，都已经能够同时处理完成，而这极大程度降低了垃圾回收工作对于应用程式回应时间的负面影响。
其他重要的更新还有动态类别档案常量（Dynamic Class-file Constants），能降低创建可实体化类别档案常量新形式时的成本。此外还有Flight Recorder，这是一个用于Java应用程式和HotSpot JVM故障排除的低成本的资料收集框架。
甲骨文对Java 11进行了不少更新和修正，更详细的资讯可以参照Java 11释出说明文件。
https://www.ithome.com.tw/news/126133