Oracle Reviews the Java Rapid Release Cadence: So Far, So Good
One of the most-mentioned keynote topics at this year's Oracle OpenWorld-adjacent Code One 2019 conference, wrapping up this week in San Francisco, was the rapid release cadence for Java SE and the JDK, which Oracle announced in 2017 and launched in March of last year.
The rapid release cadence has proved to be one of those slap-the-forehead innovations that revivified the process of evolving the Java platform. Instead of allowing years to pass between releases and putting intense pressure on, well, every contributor in the community, to deliver and bet on big, fully formed enhancements, the new process runs on a cycle that calls for a feature release every six months, update releases every quarter, and a long-term support release every three years.
"That's fast enough to minimize the pain of waiting for the next [release] train," wrote Mark Reinhold, chief architect of Oracle's Java Platform Group, in the blog post in which he first proposed the faster cadence, "yet slow enough that we can still deliver each release at a high level of quality, preserving Java's key long-term values of compatibility, reliability, and thoughtful evolution."
JDK 10 was the first feature release of the new cycle; Java 11, which was released six months later, was the first long-term support (LTS) release. The next LTS release will be Java 17, scheduled September 2021. Java 13, which went GA this week, is not an LTS release, which means it will be obsoleted with the release of Java 14 in March, 2020.
And yet it seems people are still getting used to the idea, which I suppose underscores the depth of the change. Java Language Architect Brian Goetz reminded conference attendees during his Code One keynote to remember that the rapid release cadence imposed a truly fundamental change on a long-established process.
"A lot of people, including, quite honestly, us, were pretty skeptical at first," Goetz admitted. "It seemed inconceivable that we could turn a ship as big as Java that quickly. There were even fears that Java 10 and 11 might have no features at all. But looking back, it would be really hard to overstate what a significant change the rapid release cadence has been."
Among the benefits of the new cadence, he said, are the obvious: "We can deliver value more often, and you don't have to wait as long for any particular feature to come out." And the not-so-obvious: "It has brought about this fundamental change in how we design, plan, and deliver new features by lowering the cost of a feature missing the boat. Missing by six months is a whole lot different from missing by several years. [The faster release cadence] has drastically reduced our release-management overhead internally, which allows us to spend more energy on designing and building features and less energy on managing releases."
"And at the same time, having more releases has encouraged us to learn how to break down complex features into smaller ones, so we can deliver in phases," he added. "The results, which has sort of been an unexpected one, is that our feature pipeline has become richer than it has ever been. The whole thing has been one big virtuous circle."
Adapting to the faster release cadence has required the Java community to "recalibrate our expectations," Goetz said, "about what constitutes something worth upgrading.
"In the old world, when we had these big releases every few years, and those big releases tended to have big features, like Generics and Lambda's, there was already plenty of motivation to upgrade. The reality now is, we're not going to be seeing a lot of those big features in the future. And that's not because we're not innovating. It's because those big features are going to get broken up into smaller features and delivered in phases. There's just as much innovation going on -- perhaps more -- but it's going to be spread out over a large number of smaller deliveries."
During his Code One presentation, Georges Saab, VP of Oracle's Java Platform Group and OpenJDK chairperson, also reminisced about the launch of the new release cadence into skeptical waters.
"Many folks were excited about the faster cadence," he said. "Many folks were apprehensive about it. And there are a lot of people who were actually both ... . Some of the most apprehensive people were on my team at Oracle working on Java! When we floated the idea of six months releases, they really thought I was crazy. They said because of the Java Community Process (JCP), through which the Java platform evolves, it just takes too long. This process requires that there be a specification, a reference implementation, and a certified compatible testing kit ... .But I had faith that, like us, many in the JCP Executive Committee (EC) wanted to see a faster and more gradual evolution of Java."
And then he brought out the big guns: Bruno Souza, leader of the Brazilian Java community known as SouJava, and Gil Tene, CTO and co-founder of Azul Systems, maker of the Zing Java runtime, among other products, the only vendor focused exclusively on Java and the JVM. Both are JCP EC members. (The lively Souza wore a cape that has yet to be explained.)
Tene said he and the other EC members were very skeptical when they first heard about the rapid release cadence for Java. "The benefits of the faster cadence were obvious," he said, "if it could be done, but the shortest we had ever done a spec process at the time was 10 months."
The challenge for the EC, Souza said, came down to one question: "How do we do a fast open-source model and at the same time retain the stability Java has."
"As we moved to a fast cadence process," he said, "we had to take a very critical look at what [we were] doing a the JCP. And so we removed everything that prevented us from going to an open-source-friendly-early-release-often model, but at the same time we kept and improved on everything that guarantees the stability, long term, of the specification that is so important to the Java community."
Tene agreed that the rapid release cadence was a welcome idea that had to prove itself to the EC in specific ways. The JCP is where the specification, the reference implementation, and the Technology Compatibility Kit (TCK) come together, he said.
"The reason the Java ecosystem has such a rich set of code and libraries -- the reason Maven Central works on all the differentiated cases out there -- is because we do this work, because the specification is specific, and because the TCK lets us verify that all these implementations really will run the same way," he said.
How did it work out?
"We think it's worked out great," Tene said.
Posted by John K. Waters on September 20, 2019