SEARCH FINANCIAL SERVICES INFRASTRUCTURE SECURITY SCIENCE INTERVIEWS

 

     

There’s not a moment to lose!

By Mark Reinhold, Chief Architect of the Java Platform Group at Oracle

September 06, 2017

Moving Java Forward Faster

For over twenty years the Java SE Plat­form and the JDK have evolved in large, ir­reg­u­lar, and some­what un­pre­dictable steps. Each fea­ture re­lease has been dri­ven by one or a few sig­nif­i­cant fea­tures, and so the sched­ule of each re­lease has been ad­justed as needed — some­times more than once! — in order to ac­com­mo­date the de­vel­op­ment of those fea­tures.

This ap­proach made it pos­si­ble to de­liver big new fea­tures at a high level of qual­ity, after thor­ough re­view and test­ing by early adopters. The down­side, how­ever, was that smaller API, lan­guage, and JVM fea­tures could only be de­liv­ered when the big fea­tures were ready.

This was an ac­cept­able trade­off in the decades be­fore and after the turn of the cen­tury, when Java com­peted with just a few plat­forms which evolved at a sim­i­lar stately pace. Nowa­days, how­ever, Java com­petes with many plat­forms which evolve at a more rapid pace.

For Java to re­main com­pet­i­tive it must not just con­tinue to move for­ward — it must move for­ward faster.

Back on the train Five years ago I mused in this space on the ten­sion be­tween de­vel­op­ers, who pre­fer rapid in­no­va­tion, and en­ter­prises, which pre­fer sta­bil­ity, and the fact that every­one prefers reg­u­lar and pre­dictable re­leases.

To ad­dress these dif­fer­ing de­sires I sug­gested, back then, that we switch from the his­tor­i­cal fea­ture-dri­ven re­lease model to a time-dri­ven “train” model, with a fea­ture re­lease every two years. In this type of model the de­vel­op­ment process is a con­tin­u­ous pipeline of in­no­va­tion that’s only loosely cou­pled to the ac­tual re­lease process, which it­self has a con­stant ca­dence. Any par­tic­u­lar fea­ture, large or small, is merged only when it’s nearly fin­ished. If a fea­ture misses the cur­rent train then that’s un­for­tu­nate but it’s not the end of the world, since the next train will al­ready be wait­ing and will also leave on sched­ule.

The two-year train model was ap­peal­ing in the­ory, but proved un­work­able in prac­tice. We took an ad­di­tional eight months for Java 8 in order to ad­dress crit­i­cal se­cu­rity is­sues and fin­ish Pro­ject Lambda, which was prefer­able to de­lay­ing Lambda by two years. We ini­tially planned Java 9 as a two-and-a-half year re­lease in order to in­clude Pro­ject Jig­saw, which was prefer­able to de­lay­ing Jig­saw by an ad­di­tional eigh­teen months, yet in the end we wound up tak­ing an ad­di­tional year and so Java 9 will ship this month, three and a half years after Java 8.

A two-year re­lease ca­dence is, in ret­ro­spect, sim­ply too slow. To achieve a con­stant ca­dence we must ship fea­ture re­leases at a more rapid rate. De­fer­ring a fea­ture from one re­lease to the next should be a tac­ti­cal de­ci­sion with minor in­con­ve­niences rather than a strate­gic de­ci­sion with major con­se­quences.

So, let’s ship a fea­ture re­lease every six months.

That’s fast enough to min­i­mize the pain of wait­ing for the next train, yet slow enough that we can still de­liver each re­lease at a high level of qual­ity.

Pro­posal Tak­ing in­spi­ra­tion from the re­lease mod­els used by other plat­forms and by var­i­ous op­er­at­ing-sys­tem dis­tri­b­u­tions, I pro­pose that after Java 9 we adopt a strict, time-based model with a new fea­ture re­lease every six months, up­date re­leases every quar­ter, and a long-term sup­port re­lease every three years.

  • Fea­ture re­leases can con­tain any type of fea­ture, in­clud­ing not just new and im­proved APIs but also lan­guage and JVM fea­tures. New fea­tures will be merged only when they’re nearly fin­ished, so that the re­lease cur­rently in de­vel­op­ment is fea­ture-com­plete at all times. Fea­ture re­leases will ship in March and Sep­tem­ber of each year, start­ing in March of 2018.
  • Up­date re­leases will be strictly lim­ited to fixes of se­cu­rity is­sues, re­gres­sions, and bugs in newer fea­tures. Each fea­ture re­lease will re­ceive two up­dates be­fore the next fea­ture re­lease. Up­date re­leases will ship quar­terly in Jan­u­ary, April, July, and Oc­to­ber, as they do today.
  • Every three years, start­ing in Sep­tem­ber of 2018, the fea­ture re­lease will be a long-term sup­port re­lease. Up­dates for these re­leases will be avail­able for at least three years and quite pos­si­bly longer, de­pend­ing upon your ven­dor.

In this model the over­all rate of change should be about the same as it is today; what’s dif­fer­ent is that there will be many more op­por­tu­ni­ties to de­liver in­no­va­tion. The six-month fea­ture re­leases will be smaller than the multi-year fea­ture re­leases of the past, and there­fore eas­ier to adopt. Six-month fea­ture re­leases will also re­duce the pres­sure to back­port new fea­tures to older re­leases, since the next fea­ture re­lease will never be more than six months away.

De­vel­op­ers who pre­fer rapid in­no­va­tion, so that they can lever­age new fea­tures in pro­duc­tion as soon as pos­si­ble, can use the most re­cent fea­ture re­lease or an up­date re­lease thereof and move on to the next one when it ships. They can de­liver an ap­pli­ca­tion in a Docker image, or other type of con­tainer pack­age, along with the exact Java re­lease on which the ap­pli­ca­tion will run. Since the ap­pli­ca­tion and the Java re­lease can al­ways be tested to­gether, in a mod­ern con­tin­u­ous-in­te­gra­tion and con­tin­u­ous-de­ploy­ment pipeline, it will be straight­for­ward to move from one Java re­lease to the next.

En­ter­prises that pre­fer sta­bil­ity, so that they can run mul­ti­ple large ap­pli­ca­tions on a sin­gle shared Java re­lease, can in­stead use the cur­rent long-term sup­port re­lease. They can plan ahead to mi­grate from one long-term sup­port re­lease to the next, like clock­work, every three years.

To make it clear that these are time-based re­leases, and to make it easy to fig­ure out the re­lease date of any par­tic­u­lar re­lease, the ver­sion strings of fea­ture re­leases will be of the form $YEAR.$MONTH. Thus next year’s March re­lease will be 18.3, and the Sep­tem­ber long-term sup­port re­lease will be 18.9.

Im­pli­ca­tions This pro­posal will, if adopted, re­quire major changes in how con­trib­u­tors in the Open­JDK Com­mu­nity pro­duce the JDK it­self; I’ve posted some ini­tial thoughts as to how we might pro­ceed there. It will be made eas­ier if we can re­duce the over­head of the Java Com­mu­nity Process, which gov­erns the evo­lu­tion of the Java SE Plat­form; my col­leagues Brian Goetz and Georges Saab have al­ready raised this topic with the JCP Ex­ec­u­tive Com­mit­tee.

This pro­posal will, ul­ti­mately, af­fect every de­vel­oper, user, and en­ter­prise that re­lies upon Java. It will, if suc­cess­ful, help Java re­main com­pet­i­tive — while main­tain­ing its core val­ues of com­pat­i­bil­ity, re­li­a­bil­ity, and thought­ful evo­lu­tion — for many years to come.

Terms of Use | Copyright © 2002 - 2017 CONSTITUENTWORKS SM  CORPORATION. All rights reserved. | Privacy Statement