随着Java 11的发布，Java最终完成了到OpenJDK一等项目的过渡。使用专有OracleJDK二进制文件的日子已经结束了。对Java开放性和免费的关注自然而然将Oracle以外的公司的贡献带入到了聚光灯下。最近，InfoQ采访了Red Hat中间件产品管理高级总监Rich Sharples，讨论了OpenJDK和Red Hat的参与情况。
\nInfoQ：在很早之前，Red Hat就一直是OpenJDK的贡献者。你能谈谈你和这个项目之间的历史渊源吗？
\nRich Sharples：Red Hat于2007年11月5日宣布与Sun Microsystems达成广泛的贡献者协议。这项协议包括了Red Hat工程师参与Sun领导的所有开源项目。同时，Red Hat签署了Sun的OpenJDK Community TCK许可协议，成为第一家签署该协议的主要软件供应商。Red Hat还与Sun分享开发人员的贡献，共同创建OpenJDK社区以及促进创新。Red Hat是继Oracle之后OpenJDK的最大贡献者之一。
\nRed Hat通过上述举措深度参与Java生态系统，这在Red Hat收购JBoss之后的时期起到了非常重要的作用。2009年，Sun被Oracle收购，Sun和Red Hat之间已经建立起来的关系在Oracle眼皮底下继续发展。
\n自2007年加入OpenJDK项目以来，Red Hat持续为上游OpenJDK社区做出贡献，并将OpenJDK打包进了Red Hat Enterprise Linux中。Red Hat曾在2013年领导OpenJDK 6的开发（支持到2016年），并在2015年接管了OpenJDK 7的管理权。Andrew Haley在Red Hat开发者博客的这篇文章中详细介绍了我们接管的工作。
\n和OpenJDK 7一样，OpenJDK 6被打包进了Red Hat Enterprise Linux 5、6和7当中。Red Hat Enterprise Linux 6和7还支持OpenJDK 8。Red Hat Enterprise Linux 7.6支持OpenJDK 11。除了为一系列Red Hat Enterprise Linux版本提供支持外，我们还一直为OpenJDK发行版提供全生命周期支持。
\n最近，OpenJDK 7的生命周期被延长至2020年6月，OpenJDK 8被延长至2023年6月，旨在为用户提供足够的时间将工作负载迁移到OpenJDK 11。
\n除了为Red Hat Enterprise Linux上的OpenJDK提供发行和生命周期支持外，Red Hat的开源Java中间件产品也支持Red Hat Enterprise Linux的OpenJDK，让户能够从单个供应商获得从操作系统到应用程序服务的完整技术栈支持。其他的Red Hat产品也运行在OpenJDK上。我们是一个为全球依赖开源软件运行应用程序工作负载的客户提供支持的领先厂商。
\nInfoQ：我们来谈谈目前的状况。目前看来，Red Hat有多少工程师正在参与OpenJDK的工作（全职和兼职）？主要参与哪些方面的工作？
\nSharples：出于政策方面的考虑，我们不方便公开Red Hat在特定项目上的投入情况。
\nRed Hat Java平台团队首席工程师Andrew Haley多年来一直是OpenJDK管理委员会的成员，同时也是AArch64移植项目的负责人。此外，Andrew还是JDK 7项目的负责人，并打算在Oracle支持周期结束后申请负责OpenJDK 8和11的开发。
\nInfoQ：在具体技术方面，你认为Red Hat在哪些领域做出了最大的贡献？哪些技术组件可以体现Red Hat的强大领导力？
\nSharples：Red Hat领导了64位ARMv8的移植，即OpenJDK的AArch64项目，并将它并入上游的OpenJDK项目中。目前，我们正在与OpenJDK社区合作开发一个新的超低停顿时间的垃圾回收器，名字叫作Shenandoah，它处于OpenJDK主线之外——但在Red Hat Enterprise Linux 7中得到完整的支持。这项工作计划在OpenJDK 12中并入主线。
\nInfoQ：目前，OpenJDK垃圾回收方面的情况非常有意思。例如，截止JDK 11，G1最终成为一个成熟的垃圾回收器。Red Hat有Shenandoah，而Oracle一直在开发ZGC。你能评论一下Red Hat在GC方面的参与情况吗，特别是关于G1？你如何对比Shenandoah和ZGC？你能否估计一下Red Hat认为Shenandoah会在什么时候成为一个生产就绪的垃圾回收器？
\nSharples：目前，我们主要参与的仍然是Shenandoah GC。此外，在Hotspot的GC接口开发方面（尽管对用户不可见）也进行了非常重要的协作，Red Hat正积极参与其中。
\n过去，GC代码与Hotspot代码交杂在一起，但现在每个GC的代码都很好地分离出来了。Shenandoah与G1共享了一些代码，所以需要做一些改进和bug修复。值得注意的是，G1采用了最初出现在Shenandoah中的一些特性，例如多线程Full GC，以及最近的空闲未提交堆（heap uncommit on idle）。
\nZGC和Shenandoah的目标非常相似（减少收集大堆的停顿时间），但它们遵循的是非常不同的实现策略——Shenandoah使用Brooks Pointers，而ZGC使用彩色指针和多内存映射。
\nZGC在吞吐量和停顿时间方面做得更好，而Shenandoah具有更好的人体工程学，这意味着它在一些恶劣的情况下（例如满堆或堆分配激增）会运行得更好。ZGC不能（按照设计）使用压缩的oops，这意味着它在中型（\u0026lt;32GB）的堆上有一定的弱势。此外，Shenandoah在小堆上运行良好，这让它有可能会成为增长型应用程序的理想GC，但并不保证会这样。
\n据我们所知，Shenandoah已经是JDK-8u发行版（Red Hat Enterprise Linux \u0026gt;= 7.5）的一部分。我们目前正在努力让Shenandoah进入上游（JDK 12）。如果我们做到了，它将成为一个实验性特性。我们现在还不敢说这个实验性标志什么时候将从上游OpenJDK发行版中移除。
\nInfoQ：显然，最近的一个重大新闻是Red Hat被IBM收购。这将给Red Hat与OpenJDK之间的关系带来什么样的影响？
\nSharples：关于与收购有关的内容请参阅我们发布的新闻和Jim Whitehurst的博文。
\nInfoQ：你认为OpenJDK（以及Java/JVM生态系统）最激动人心的部分是什么？你认为哪些技术是我们的读者在未来12到18个月内最应该关注的？
\nSharples：Java必须超越当前的位置，也就是作为大规模关键业务应用程序的可扩展语言运行时，并与更轻量、更灵活的语言和运行时展开竞争——特别是在内存占用和延迟非常敏感的云原生环境中。
\nJava社区继续在JVM层面进行创新。除此之外，Graal和Substrate VM已经认识到，在容器和DevOps环境中，JVM的平均运行寿命要短得多。单体应用程序一次在JVM上可以运行数月，而持续交付环境中的容器化微服务可能一次只运行数天或数小时，而在无服务器环境中，它们可能只运行几秒（甚至几毫秒）。
\n值得注意的是，不仅仅是JVM令人感到兴奋，更广泛的Java生态系统也正极力追赶。除了优化JVM本身以及不断引入像Thorntail这样的新的轻量级和灵活的运行时之外，Eclipse MicroProfile及其规范也有助于将开发传统单体应用程序的Java EE开发人员带入轻量级微服务领域。
\nRed Hat，以及Fabic8 Maven Plugin和Spring Cloud Kubernetes等工具，一直在引领Kubernetes、Istio和OpenShift原生Java应用程序的开发。这极大简化了微服务架构，而在几年前，它们需要很多单独管理的独立基础设施服务。整个Java生态系统在持续快速地向前发展。
\n我们也在考虑针对专门工作负载（如AI和机器学习）的芯片架构（如ARM和GPU）和云架构的新元素，如边缘设备、网关、移动设备和可穿戴设备。
\nInfoQ：还有其他想对我们读者说的吗？
\nSharples：人们对Java兴趣程度从未如此强烈，Java的未来也从未如此光明。
\n查看英文原文：
\n \n
扫一扫
647
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
