With the release of Java 11, the transition of Java into an OpenJDK-first project is finally complete. The days of most Java installations using the proprietary OracleJDK binaries are at an end. This increased focus on Open and Free Java naturally brings the contributions of companies other than Oracle into greater prominence. InfoQ recently spoke with Rich Sharples, senior director of product management for Middleware at Red Hat, to discuss OpenJDK and Red Hat's involvement with it.
InfoQ: Red Hat has been a contributor to OpenJDK since the very earliest days. Can you speak to your history with the project?
Rich Sharples: Red Hat announced a broad contributor agreement with Sun Microsystems on November 5, 2007. This agreement covered the participation of Red Hat engineers in all Sun-led open source projects. As part of this, Red Hat signed Sun’s OpenJDK Community TCK License Agreement, becoming the first major software vendor to do so. Red Hat also committed to sharing its developers’ contributions with Sun to create the OpenJDK community and foster innovation. Red Hat is one of the largest contributors to OpenJDK after Oracle.
By doing this, Red Hat has deepened its participation in the Java ecosystem, which was significant after its acquisition of JBoss in the previous year. In 2009, Sun was acquired by Oracle and the relationship that had developed between Sun and Red Hat was continued under Oracle.
Since joining the OpenJDK project in 2007, Red Hat has continued contributing in the upstream OpenJDK community, as well as packaging and supporting OpenJDK with Red Hat Enterprise Linux. For example, Red Hat assumed leadership of OpenJDK 6 in 2013 (and supported it until 2016) and took over stewardship of OpenJDK 7 in 2015. Andrew Haley explains more about our stewardship in this post on the Red Hat Developer Blog.
OpenJDK 6 was packaged and supported in Red Hat Enterprise Linux 5, 6, and 7, as was OpenJDK 7. OpenJDK 8 is supported in Red Hat Enterprise Linux 6 and 7. OpenJDK 11 is supported in Red Hat Enterprise Linux 7.6. In addition to providing support across a range of Red Hat Enterprise Linux versions, we have consistently provided lifecycle support for our OpenJDK distributions.
The lifecycle for OpenJDK 7 has recently been extended to June 2020, and the lifecycle for OpenJDK 8 has been extended to June 2023 with the intent of providing users with sufficient time to migrate workloads to OpenJDK 11.
In addition to distributing and providing lifecycle support for OpenJDK on Red Hat Enterprise Linux, Red Hat’s open source Java middleware products support OpenJDK for Red Hat Enterprise Linux, enabling users to get a full stack support from the operating system through to application services from a single vendor, and other Red Hat products internally run on OpenJDK. We are a leader in offering support to customers worldwide that rely on open source to run their production workloads.
InfoQ: Let's talk about the current state of play. As it stands right now, how many engineers at Red Hat are working on OpenJDK (both full-time and part-time)? What areas are they working on?
Sharples: As a policy, we don’t publicize Red Hat’s investment in particular projects.
The lead engineer of Red Hat's Java Platform team Andrew Haley has been a member of the OpenJDK Governing Board for many years and is also the lead of the AArch64-port projects. Additionally, Andrew is also the lead of the JDK 7 project and intends to apply for leadership of OpenJDK 8 and 11 after Oracle EOLs them.
InfoQ: To talk about specific technologies - which areas do you think Red Hat has contributed the most to? What are the technical components where Red Hat's leadership has been strongest?
Sharples: Red Hat started, wrote much of, and leads the 64-bit ARMv8 port, AArch64 for OpenJDK, and helped move it into the upstream OpenJDK project. Currently, we’re working with the OpenJDK community on a new ultra-low pause time Garbage Collector named Shenandoah that’s outside the OpenJDK mainline now - but fully supported in Red Hat Enterprise Linux 7. The work is targeted to enter mainline in OpenJDK 12.
InfoQ: The current state of garbage collection in OpenJDK is very interesting. For example, as of JDK 11, G1 is finally reaching full maturity as a collector. Red Hat obviously has the Shenandoah collector, while Oracle has been working on ZGC. Can you comment on Red Hat's approach to participation in the GC space, especially as regards G1? How would you compare and contrast Shenandoah and ZGC? Would you like to give an estimate as to when Red Hat thinks that Shenandoah will be a plausible choice for a production collector?
Sharples: Our main area of participation continues to remain Shenandoah GC at this time. Additionally, a very significant (although not user-visible) collaboration is happening in the development of Hotspot's GC interface, in which Red Hat is actively participating.
GC code used to be spread around a lot of Hotspot code, but it's now very well separated, both from Hotspot’s core and each GC from every other. Shenandoah shares some code with G1, which lead to a couple of improvements and bug fixes there too. Notably, G1 has adopted a few features which originally appeared in Shenandoah first, for example multi-threaded full-GC and, very recently, heap uncommit on idle.
ZGC and Shenandoah are very similar in their goals (reduce pause times on large heaps). However they follow a very different implementation strategy -- Shenandoah uses Brooks Pointers, whereas ZGC uses colored pointers and multiple-memory-mappings.
ZGC is often better in terms of throughput and pause-times. However, Shenandoah has better ergonomics, which means that it can practically operate better in difficult conditions like almost-full heap or allocation bursts. ZGC cannot (by design) use compressed oops, which means that it has a disadvantage on medium-sized (<32GB) heaps. Furthermore, even though it's never been a goal, Shenandoah operates very well on small heaps, making it an ideal GC for applications that may grow in size, but are not guaranteed to do so.
Shenandoah is already offered as a production choice as part of RHEL >= 7.5's JDK-8u distribution, and to our knowledge, it is already used as such. We're currently working on getting Shenandoah into upstream in JDK12. When it lands there, it'll be an experimental feature. We cannot say at this time when the experimental flag will be removed in upstream OpenJDK distribution.
InfoQ: Obviously, one of the big news pieces recently has been the news that Red Hat is to be acquired. How will this change the position of Red Hat relative to OpenJDK?
Sharples: We cannot say anything additional about IBM. Please refer back to our press release and our blog post from Jim Whitehurst.
InfoQ: What do you think the most exciting parts of OpenJDK (and the wider Java / JVM ecosystem) are right now? Which technologies and new developments do you think are the ones that our readers should pay the closest attention to in the next 12-18 months?
Sharples: Java has to move beyond its sweet spot as a scalable language runtime for large-scale business critical applications and better compete with lighter, nimbler languages and runtimes - especially in cloud-native environments where memory footprint and latency are very sensitive.
What’s exciting to note is that the Java community continues to innovate at the JVM level. Among other things, Graal and Substrate VM recognize that the average lifespan of a running JVM is significantly shorter in a container and devops environment. Monolithic applications ran on the JVM for months at a time, containerized microservices in a continuous delivery environment may run for days or hours, and in the serverless world they may run for (milli)seconds.
It’s important to note that it’s not just the JVM that has become exciting (again), but the broader Java ecosystem is keeping pace. Along with optimizing the JVM itself and the continuous introduction of new lightweight and nimble runtimes like Thorntail, there are projects like Eclipse MicroProfile and its specifications that help bring Java EE developers who have traditionally written monolithic applications to the world of lightweight microservices.
Red Hat, with tools like the Fabic8 Maven Plugin and Spring Cloud Kubernetes, has been leading the way for developing Java applications that are native to Kubernetes, Istio, and OpenShift. This greatly simplifies the microservices architecture that only a couple of years ago required many standalone infrastructure services that had to be managed individually. The Java ecosystem as a whole continues to move forward at a rapid pace.
We’re also thinking about new chip architectures (like ARM and GPUs) for specialized workloads such as AI and Machine Learning as well as new elements of the cloud architecture such as edge devices, gateways, mobile devices and wearables.
InfoQ: Any other comments for our readers?
Sharples: The interest in Java has never been greater and the future of Java has never been brighter.