OpenJDK: More Speed, Less Haste

lights flashing on road
A fast release cadence provides the ability to add features without casting them in stone, making them part of the Java SE standard.

It's now over two years since the release of JDK 9, and with it, the switch to a time-based rather than feature-based release schedule. It seems incredible that it took very nearly eleven years to get from JDK 6 to JDK 9, yet in just over two years, we've gone from JDK 9 to JDK 13.

Each release under this new strategy provides a smaller set of features than we had in the old major release approach. What we're seeing, though, is the overall rate of change is faster than it's ever been, which is a significant advantage for keeping Java vibrant and attractive to developers.

Signs of JDK 14 Beginning to Appear

JDK 13 is currently in Rampdown Phase 1 (RDP 1), is scheduled to enter Rampdown Phase 2 (RDP 2) in a little over one week (on July 18, 2019), and is tentatively scheduled for General Availability on September 17, 2019. What this means, of course, is that it's time to start thinking about JDK 14! This post references and summarizes some of the online resources related to JDK 14 that are starting to appear.

Project JDK 14

The main OpenJDK JDK 14 page is the best place to start when wishing to see an overview of the release and its progress. Besides a reference to its associated specification (JSR 389: "Java SE 14 Platform"), the only other information available on this page as of this writing is a simple "Status" paragraph that references development repositories and the JDK Enhancement Proposal (JEP) process.

OK, Java Is Still Free, But Which Version Do I Use and Recommend to My Clients?

There remains significant confusion over the licensing and distribution of Java. I know this because I have contributed to this confusion. There is a debate in my college department over which version to use and how updates will be handled. Donald Smith, Sr. Director of Product Management at Oracle in Ottawa, has been kind enough to clear up these issues, probably for the 100th time. The purpose of this brief article is to summarize what I have learned. Before I begin, you should first read the following posts:

https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq
https://blogs.oracle.com/java-platform-group/oracle-jdk-releases-for-java-11-and-later

Mythbusters: 5 Myths About How Java Is Getting Better

Java was originally design for interactive television, but it was too advanced of technology for the cable television industry at the time. The history of Java starts with a team called Green Team, who initiated this project to develop a language for digital devices, such as set-top boxes, televisions, etc. However, it was suited for Internet programming. Later, Java incorporated by Netscape.

The main reasons for creating Java were simple: we needed a language that was robust, portable, platform-independent, secure, high-performance, multithreaded, architecture-neutral, object-oriented, interpreted, and dynamic.

WordPress Contributors Propose Shorter, Time-based Release Cycles

WordPress release cycles may soon take a more predictable cadence, as contributors are considering moving to a time-based approach. The discussion began during a recent core dev chat in mid-February when Gutenberg phase 2 lead Riad Benguella proposed the project move to shorter, automated release cycles.

The Gutenberg team has successfully been releasing a new version of the plugin every two weeks on schedule and any features that aren’t ready are postponed to the next releases automatically. Benguella contends that this type of release schedule has the potential to bring several benefits to WordPress:

  • Less stress for contributors
  • Predictability: People can plan around the release timelines easily
  • No delays as releases are not feature-based

Shortening major releases may prove more challenging for WordPress, which is at a much larger scale than the Gutenberg plugin. The plugin also has the added advantage of being able to manage releases and development on GitHub.

“I think there are a lot of infrastructure problems that need to be solved for WordPress before we could move to a fast, automated release cycle,” Gary Pendergast said.

“Having a major release once a month is achievable, it’s something I’d like us to get to, but the release process is too manual to have multiple releases running at the same time at the moment.”

Jonathan Desrosiers drafted a proposal that summarizes this discussion and outlines some of the manual tasks required for getting a major release out the door. These include time-consuming tasks like Trac gardening, creating a Field Guide, blog posts for the betas, RCs, and official release, documentation updates, videos, dev notes, and other items that are often completed by volunteers.

The 3-4 month release cycles that WordPress had from versions 3.9 – 4.7 allowed for all of the administrative overhead outlined above to be completed in a reasonable amount of time, but the general consensus is that some of these tasks could be more simplified and/or automated.

Desrosiers highlighted several benefits of moving to a shorter major release cycle, including less drastic change for users that might ultimately result in more users being comfortable enabling automatic updates for major releases. Detriments to shortening the release cycle are the increased burden it puts on volunteers as well as theme and plugin developers who need to push compatibility releases. It would also introduce more backporting work for security releases.

Several contributors have left feedback on the post with insight gleaned from other projects’ release scheduling. Jeremy Felt reviewed Firefox’s release owner table that assigns leadership and dates for several releases in advance.

“I think getting to a shorter release cycle in general will involve scheduling multiple releases and assigning their release leads in advance,” Felt said. “So far most of our scheduling is done as soon as the last release has been shipped.”

Joe McGill examined VS Code’s development process and found several similarities to the process he thinks WordPress could adopt in the future:

  1. A long term roadmap (theirs is 6–12 months) outlining major themes and features.
  2. A monthly release cadence based on 4 week sprints which begin with milestone planning and always results in a release of whatever was completed in that monthly iteration.
  3. Regular project triage, with release priorities managed at the team (i.e. Component) level.
  4. Documentation integrated into the development process.
  5. Automated testing of releases and upgrades.
  6. Only important regressions and security issues are handled in minor releases between monthly milestones, everything else is moved forward to the next release (or reprioritized in the backlog).

Several of these points echo feedback from other contributors who have identified documentation integrated into development and automated testing as ways to speed up major release cycles.

“If we don’t have the infrastructure and tooling to support a 1 month cycle, then I think we could attempt a 2 month cycle with a goal towards moving to shorter cycles,” McGill said.

The Gutenberg plugin’s relentless pace of iteration and predictable release cycles have opened up a world of new ideas for improving the process for WordPress core. Discussion around moving the project to shorter, time-based release cycles is still in the preliminary stages. No major changes have been agreed upon yet, but the process of exploring different ideas has put the spotlight on tasks that could afford to be tightened up in the release process. This falls in line with WordPress’ 2019 theme of “tightening up.”