Oracle Proposes 6-Month Release Cadence for Java

Mark Reinhold, chief architect of Oracle's Java Platform Group, says "Java needs to move forward faster" if it's going to compete effectively with other software development platforms, which are evolving at a more rapid pace. He made that rather non-controversial declaration this morning on his personal blog, but he also offered a strategy for making this happen that might stir some debate.

Reinhold backed off an earlier suggestion that the community switch from its historical feature-driven release model to a time-driven "train" model (think Eclipse Release Train, with a feature release every two years.) "The two-year train model was appealing in theory, but it proved unworkable in practice," he wrote.

Instead, he's now proposing a strict, time-based release schedule for the Java SE Platform and the JDK that provides 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 train," he wrote, "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."

Specifically, Reinhold is proposing the following:

• Feature releases can contain any type of feature, not just new and improved APIs, but also language and JVM features. New features will be merged only when they're nearly finished, so the release currently in development is feature-complete at all times. Feature releases will ship in March and September of each year, starting in March 2018.
• Update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Each feature release will receive two updates before the next feature release. Update releases will ship quarterly in January, April, July, and October, as they do today.
• Every three years, starting in September of 2018, the feature release will be a long-term support release. Updates will be available for at least three years and quite possibly longer, depending on the vendor.

This model doesn't really alter the current rate of change overall, he allowed, but it provides "many more opportunities to deliver innovation."

"The six-month feature releases will be smaller than the multi-year feature releases of the past," he wrote, "and therefore easier to adopt. Six-month feature releases will also reduce the pressure to backport new features to older releases, since the next feature release will never be more than six months away."

Reinhold acknowledged in the blog post that his proposal will, if adopted, require major changes in how contributors in the OpenJDK Community produce the JDK itself. In a note posted to the OpenJDK mailing list, he laid out how that community might implement this new model as a single, long-running "JDK" release project that hosts the mainline code base and produces the feature releases, and a single, long-running "JDK Updates" project to produce the update releases.

"Two long-running projects will save some administrative overhead, and also eliminate the confusion that regularly arises when someone is a Committer to JDK $N but not JDK $N + 1," he wrote, adding parenthetically, "We could consider just one long-running project, but two makes more sense since the two types of releases will have different policies, content, schedules, and leadership."

He gets specific here, too, outlining how his proposed JDK Project would run:

• The main development line will always be open but fixes, enhancements, and features should be integrated only when they're nearly finished. The main line should be feature complete at all times.
• We'll fork the main line into a release-stabilization branch three months before the GA date of the next feature release. That branch will immediately be in Rampdown Phase 1, enter Rampdown Phase 2 a month later, and then enter the Release Candidate phase a month after that. (Whether the branch is another repository or an actual Mercurial branch is a detail we can figure out later.)
• We'll continue to use the JDK Enhancement Proposal (JEP) Process for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration.

He also laid out some changes his team at Oracle plans to implement:

• Starting with JDK 9 we'll ship OpenJDK builds under the GPL, to make it easier for developers to deploy Java applications to cloud environments.
• We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" such as Java Flight Recorder and Mission Control, under a click-through binary-code license. Oracle will continue to offer paid support for these builds.
• After JDK 9 we'll open source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JD builds completely interchangeable.
• Starting with JDK 9 we'll reduce the set of ports that we maintain, focusing mainly on Linux, macOS, and Windows on the x64 architecture. Other OpenJDK contributors will be welcome to take on the other ports that Oracle engineers currently maintain.
• Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK.

That's a lot of change, but to his credit, Reinhold is offering a well-considered plan and asking for feedback. And it could be argued that what he's proposing fulfills the long-held dreams of Java jocks everywhere.

Oracle is clearly gearing up for a big JavaOne this year. Reinhold's posts about accelerating the Java timeline come on the heels of news that Oracle is considering moving the Java EE Platform to an open source foundation. Should be an interesting show.

Posted by John K. Waters on September 6, 2017