JDK 11 进入 Rampdown 第二阶段,正式版已在路上
之前我们曾报道过 JDK 11 已于6月底进入 Rampdown Phase One 阶段,当时 JDK 11 的所有新特性就已被冻结,不再加入新的 JEP 。
就在前两天,JDK 11 进入 Rampdown Phase Two 。之前的第一阶段持续一个月,主要修复 P1-P3 级错误;进入第二阶段后,将主要修复 P1-P2 级错误,并遵循 JEP 3 进行改进:
随着时间的临近,再有两个预览版本,JDK 11 就将迎来正式版本。
JDK 11 总共包含 17 个新的 JEP ,分别为:
181: Nest-Based Access Control(基于嵌套的访问控制)
309: Dynamic Class-File Constants(动态类文件常量)
315: Improve Aarch64 Intrinsics(改进 Aarch64 Intrinsics)
318: Epsilon: A No-Op Garbage Collector(Epsilon — 一个无操作的垃圾收集器)
320: Remove the Java EE and CORBA Modules(删除 Java EE 和 CORBA 模块)
323: Local-Variable Syntax for Lambda Parameters(用于 Lambda 参数的局部变量语法)
324: Key Agreement with Curve25519 and Curve448(Curve25519 和 Curve448 算法的密钥协议)
327: Unicode 10
328: Flight Recorder
329: ChaCha20 and Poly1305 Cryptographic Algorithms(ChaCha20 和 Poly1305 加密算法)
330: Launch Single-File Source-Code Programs(启动单一文件的源代码程序)
331: Low-Overhead Heap Profiling(低开销的 Heap Profiling)
332: Transport Layer Security (TLS) 1.3(支持 TLS 1.3)
333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) (可伸缩低延迟垃圾收集器)
335: Deprecate the Nashorn JavaScript Engine(弃用 Nashorn JavaScript 引擎)
336: Deprecate the Pack200 Tools and API (弃用 Pack200 工具和 API)
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Python 之父透露退位隐情,与核心开发团队产生隔阂
Python 创始人Guido van Rossum 前段时间宣布脱离 Python 决策层,辞去所谓的 BDFL (终生仁慈的独裁者) 身份曾引发热议,当时他以PEP 572改进提案的争吵事件为例,表明其退出缘由。近日 Guido van Rossum 在接受外媒InfoWorld 采访时,再次聊到了关于他退出决策层背后的隐情,以及对 Python 开发流程的看法。 图片来源:Dan Stroud(CC BY-SA 4.0) InfoWorld:为什么辞去 BDFL 职务? van Rossum:其实,所谓的终生和独裁都只是玩笑话。在过去十年的大部分时间里,我一直有退休的念头。我自身有一些健康问题,雪上加霜的是我需要无数次地去告诉社区的人们该如何做事并保持冷静,也需要无数次地去向别人解释 Python 的语言哲学。 压倒骆驼的最后一根稻草是一个非常有争议的 Python 改进提案(即PEP 572),在我接受它之后,他们去了像 Twitter 这样的社交媒体并说出了一些真正伤害我个人的话语。而且说这些事情的实际上都是 Python 的核心开发者,所以我觉得我们相互之间已不再信任。 I...
- 下一篇
新旧之争,JDK 团队发起 Project Skara 引争议
JDK 团队在上周五发起了一起名为 “Project Skara” 的意见征集,旨在讨论如何改进自 2008 年以来一直使用Mercurial 存储库的 JDK 源码管理方案。 据悉,发起这个项目的原因是想帮助 OpenJDK 贡献者提高效率。JDK 开发者和 OpenJDK 审查员Joe Darcy 在邮件中写道: 为帮助 OpenJDK 贡献者提高效率,Project Skara 建议无论是经验丰富的提交者还是新人,都来参与讨论代替 SCM 和代码审查的选项,比如基于 Git 而不再是 Mercurial,甚至是其他第三方选择。 为更好地进行对比,Project Skara 还打算未来在不同的服务商下托管 JDK 12 的源码。 Joe 还列出了一些评估标准,供贡献者参考: 性能:从主存储库进行克隆操作的时间,本地操作的时间等 空间效率:在不同地区的可用性 支持 Linux、Mac 和 Windows 等常见开发环境 能够轻松承载 JDK 的整个历史以及未来十年的增长预期 支持常用的 JDK 代码审查实践 程序化 API,可辅助或自动化审核和管理流程 邮件发起后,参与者的意见明显分...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Mario游戏-低调大师作品
- CentOS关闭SELinux安全模块
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G