Oracle's Georges Saab on the Impact of Faster Java Releases

Oracle announced the general availability of JDK 12 last week, which is the third release under its still newish accelerated release cadence. 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 for release in September 2021.

Three releases into the new cycle seemed like a good time to touch base with Georges Saab, VP of the Java Platform Group at Oracle and chairperson of the OpenJDK governing board, about the impact of the faster Java release cadence on the developer community and his own team at Oracle.

We last talked about the new release schedule back in 2017 when Mark Reinhold [chief architect of Oracle's Java Platform Group] publicly proposed the idea. But you had already been laying the groundwork with Java 9. You said at the time that you felt "the time is right for the Java ecosystem to make this work." Were you right about that?
Back before we started this, before they actually experienced it, people were understandably skeptical. But in the past few months, especially since Java 11 came out, the developers I talk to are saying that, once they did the hard work of getting up to Java 9 , they were able to move forward with almost no difficulty at all. Java 9 was the last of the major disruptions. For people who have something running on Java 9, moving to 10, 11 and 12 are small steps that are akin to what we used to call "minor releases."

But people still have to make their way from Java 8 to Java 9 to experience all this easy-upgrade goodness.
A couple of years ago, I heard a lot of people saying, well, maybe Java 8 is good enough, and we should just stay on that forever. But now I hear from a lot of people who are very excited about the roadmap we have, because they're seeing concrete evidence on a regular basis that we're making good on that roadmap. The things we're talking about -- Valhalla, Panama, Loom, Metropolis -- are coming into releases. Those projects are exciting, and they understand that getting on a modern release train is going to put them in a great place to take advantage of those things as they come out.

So, you'd say the new release cadence is achieving the goals you originally had for it?
You have to keep in mind what our goals are, and where we were coming from when we decided to do this. In the past, we would work on one of these major releases for two to three, even four years. And we would have a bunch of changes and improvements that landed as a major, disrupting release, which was very hard on everyone. What we've done is found a better way of improving our processes and the way new versions of the spec are revved, so that we can get those changes out in smaller chunks to people much more rapidly. What this is really about is making sure we keep Java relevant and that we're able to deliver functionality into the hands of developers quickly.

This is a big change, and I think lots of people are still having to stop and remind themselves that the latest release isn't going to be this massive, disruptive challenge. Do you think your decision to rev the major release number each time has caused a bit confusing in this regard?
I do, actually. Because we chose to streamline the numbering, eliminate "major releases," and not use, say 11u20, 11u30, 11u40, there is that automatic expectation that these are major disruptions coming every six months. But, of course, our intention is the opposite. We're providing small, evolutionary steps forward and incremental change that is easy to adopt but getting you the functionality you need. And we're continuing to evolve the language and platform so that Java continues to be relevant for another two decades.

But another advantage with this approach, which I've heard you talk about, is how these incremental changes often will constitute pieces of a bigger picture.
A really good example of that is Switch Expressions [which was included in JDK 12]. People are very excited about this feature. It's small, it makes your code easier to write, and more importantly it makes your code easier to read. We're including it as a preview so we can get feedback and make sure it's as good and solid as it can be when it's finalized, and informed by real, live use cases.

But if you look at JEP 325, way down at the bottom of the page, you'll see under "Dependencies" it says "Pattern Matching (JEP 305) depends on this JEP." It's not an end in itself, but a step toward a much larger and more ambitious improvement to Java. This is something that we would have done previously in one of those large, disruptive releases, all at once. The faster cadence allows us to do this kind of thing in small improvements across multiple releases.

But the faster release cadence also makes it easier to leave features out of a release, as you did this time around with Raw String Literals.
That's right. This is a good example of a key advantage of this model. If this had been a two-to-three-to-four-year major release, the pressure to keep it in would have been extremely high, because if it didn't, you'd be waiting for it for years. The stakes of leaving it out were much, much higher.

How has your team adapted to the faster release cadence?
They've adapted wonderfully. Having the predictability of knowing when features come out means we can reduce the overhead of producing them tremendously. We're not constantly having to shuffle different schedules, planning and re-planning when a feature drifts out of scope. So, for the team, it has been quite liberating.

Any doubters in the bunch?
It has been a bit of a cultural shift. Some people on my team were apprehensive about [the faster release cadence] before we moved into it. But now they've seen how it's actually making their lives much easier. Our end game for releases has never been calmer than it has been in the last year and a half. And people love that.

One thing people worried about before we got started was what we would do if we had a release where there wasn't anything ready -- no new JEPs came in? We went through that thought experiment before we introduced the six-month releases. And we realized pretty quickly that the minor updates we did in the past were effectively on a six-month cadence. They sometimes involved quite significant implementation changes or improvements, but they always included a bunch of bug fixes. So, we decided, even if we don't have any JEPs come into a release, we're always going to have somewhere in the neighborhood of 1,500 to 3,000 bug fixes. That in and of itself is worthy of a release.

When the new six-month cadence was announced there was some talk about "release fatigue." Have you seen that in the Java community?
It's sort of like asking, if your kids had Christmas twice a year, do you think they'd experience "Christmas fatigue?" The parents might, I guess. What I'm hearing people say now is that they are seeing so much evidence that updating to 9 and finding the move to 10 and 11 so smooth, they're excited about the new cadence and what's coming down the pike.

Posted by John K. Waters on March 26, 2019