JDK 11 最近有什么消息？我们不妨来看一下它的进展情况，包括最新的 JEP 提案。Java 的新版本发布计划意味着总会有一款新的 JDK 即将推出。根据他们的计划，6月将是 JDK 11 第一阶段的发布时期，7月将专门用于第二阶段的测试和发布，而首个发布候选版和最终发布候选版则定于8月份发布。
预计 JDK 11 将于9月25日正式发布，可用于正常使用。JDK 11 的计划阶段包含什么内容？最新消息显示，可能还有另外一个 JEP 会进入 JDK 11。根据日程安排，这可能是进入 JDK 11 的最后一项重大更改，所以请仔细阅读。 TLS 协议最近进行了一次重大的改进，与以前的版本相比，提升了安全性和性能。而为了保持竞争力和安全性，JDK 需要支持 TLS 1.3 以遵循最新标准。 最新版本的 TLS 使得其以前的所有版本都过时，并且不直接向后兼容。如果 JDK 希望保留相关性，则需要升级到 TLS 1.3。而这个 JEP 的主要目标也不是支持 TLS 1.3 的每项特性，而是支持最小的可互操作和兼容的 TLS 1.3 实现。有关更多信息，请点此参阅关于该 JEP 的文档。 四月份的时候就有报道指出，GCC 正在准备弃用英特尔内存保护扩展（Memory Protection Extensions，MPX），而英特尔也不再维护 MPX 的代码。在最近一次代码提交中，GCC 完全删除了 MPX 涉及到的42014行代码及超过500个文件，这意味着 GCC 9 不再支持英特尔内存保护扩展 MPX。
英特尔 MPX 旨在通过检查指针引用等来提供更好的软件安全性，以防止缓冲区溢出。尽管采用率并不高，但是自从英特尔 Skylake CPU 以来，MPX 支持一直都存在，并且近年来在 Linux 协议栈中得到了广泛应用。 有些人更倾向于使用 AddressSanitizer 和其他软件替代品来提高代码安全性，Linux 内核开发人员也一直在考虑从 Linux 中将 MPX 移除，像红帽和 SUSE 等开发人员希望放弃 MPX 以减轻维护负担。如今 GCC 从代码中移除了 MPX，那么接下来，Linux 内核中移除 MPX 也应该是可以确定的了，毕竟 MPX 支持是取决于编译器的。更多内容，请关注本次专辑…… 我们在 TechEmpower Framework Benchmarks 项目 5 周年之际发布了新一轮测试报告: Round 16. 这一轮对于那些稀饭大数字的人具有相当吸引力. 我们这里说的可不仅仅是每秒吞吐量(有些数字已经大过天了), 还有运行的测试数目(~1830), 测试的框架组合 (~464), 涉及的编程语言 (26), 还有运行一轮所需要的时间 (67 小时, 或者说 2410 亿毫秒). 欢迎各位前来围观我们的测试报告以及其中漫威式的数字吧.
最近几个月可谓这个项目最富有激情的阶段. 这段时间我们的社区贡献了许多非常棒的测试实现, 展现了(友善的)性能比拼带来的趣味. 回头我们会继续阐述这点. 这次将是一个稍长一点的 TFB 正式结果宣布, 因为有很多东西我们想和大家一起分享, 所以请耐心读下去吧. 在 15 轮结束之后, 我们大胆挑战了一个超级任务: 将大约 460 个测试实现从自家酿造的沙箱配置迁移到 Docker 容器中. 这个的确花了我们不少时间, 不过很值得, 整个项目因此受益匪浅.尤为重要的是因为采用了 Docker, 测试的可重复性和测量的一致性比其以前有明显提升. 从我们的持续测试结果反馈发现, 每次完整测试之间的变动非常小了. 而我们基本检测发现因为 Docker 化带来的性能影响基本上可以忽略不计, 即便有, 也是均匀施加与所有测试上面.讲真, 我们这个项目对 Docker 来说是一个完美匹配, 或者 Docker 对于我们的项目来讲是个完美匹配. 唯一的遗憾是当初我怎么没有碰到你. 还有就是 Docker 的动词形式是? 其实作为一个操作系统提供商，微软在多年前也和欧盟有过类似的交锋，当时欧盟指责微软将 Windows 媒体播放器和 Windows 绑定在一起。最后以微软的屈服告终，他们为欧洲创立了一个特殊的 Windows 版本，去掉了内置的大量应用程序。具体情况，请大家关注本次专辑…… |
