Is There Any Overlap Between Six Month Java Releases?

With the introduction of the new release cadence, the Java community has made good on its promise to deliver innovation at an accelerated pace. Starting with the release of JDK 9 back in September 2017, and following with JDK 10 (March 2018) and JDK 11 (September 2018), March 19, 2019 marked the general availability (GA) of JDK 12 — the fourth such six month release that has arrived, without slippage, on its expected delivery date.  For those wishing to adopt these new releases as they become available, one of the more common concerns revolves around the apparent lack of overlap between releases. That is to say, once a six-month release begins its support and update lifecycle, the previous version ends abruptly. At first glance, it appears that, in order to maintain a proper security posture, you'll have to migrate over to the latest release immediately, leaving no time for testing and certification.

There are, in fact, at least two mechanisms in place that should aid in transitioning from one six-month release to its immediate predecessor. In the description that follows, we'll discuss the ramifications of scheduling Java releases between planned quarterly security updates and, furthermore, point out that early access versions of future releases are, in general, made available well in advance of their formal release date. 

From a security perspective, built in overlap between successive releases is actually provided. The GA date for the six-month releases are deliberately placed in between planned quarterly updates (scheduled each year in January, April, July, and October). As a result, there is about a month's time where both old and new releases are at the same security baseline. If we use JDK 12 as an example, it did not receive a security update until April 16th. During that one-month period, there was no security difference between JDK 11 and JDK 12, meaning it didn't make any difference security-wise whether you were on the previous release or the one just introduced. That duration could have served as a transition and testing period where staying on JDK 11 did not sacrifice any security posture. The same overlap principle will hold true as newer JDK releases are introduced.

In the past, major Java releases were so few and far between, not to mention large and complex, that offering early access versions was a difficult and costly undertaking. The more incremental nature of the new release cadence makes it easier to provide early access versions of upcoming features and releases far in advance of their planned GA date.  For example, early access versions of JDK 13 have been available since February 2019, affording developers and testers many months of advance preparation before its planned September 2019 go-live date.

Gone are the days of three and four year Java release cycles. Granted, there are many positives to such stability, but it also left Java at an innovation disadvantage when it came to competing against other platforms for the hearts and minds of modern developers. What is, perhaps less than ideal, in this new world of rapid innovation, is the combination of having a month's worth of security baseline equivalence between old release and new, plus advance access to newer releases should assist those following the continuous integration paradigm with the new Java release cadence.