Da bradipo a ghepardo

Il titolo del post, volutamente provocatorio, si riferisce ad un avvenimento importante che ha scosso tutta la comunità Java e che è collegato a un articolo pubblicato sul blog di Mark Reinhold, Chief Architect of the Java Platform Group in Oracle, nel quale ha proposto, in breve, un cambiamento epocale nella temporizzazione dei rilasci della piattaforma Java e del JDK.

Secondo Reinhold, infatti, l’ecosistema Java si è evoluto negli anni in un modo piuttosto irregolare e non ha mai avuto uno schedule programmato in modo temporalmente omogeneo. Si è data sempre maggiore priorità alle big feature integrabili nel linguaggio a scapito, magari, di piccoli anche se significativi cambiamenti. Ciò ha comportato che, finché queste feature non fossero completate e adeguatamente testate, la release finale della piattaforma slittasse di conseguenza.

Questi ritardi di rilascio, mentre erano accettabili diversi anni fa dove piattaforme concorrenti si aggiornavano con la stessa lentezza, oggi non lo sono più perché le stesse piattaforme evolvono con una certa rapidità. Ecco dunque la necessità che anche l’ecosistema Java inizi a evolversi molto più rapidamente, al fine di garantirne un’adeguata competitività e cercando, comunque, di mitigare anche la normale tensione che esiste tra gli sviluppatori, ansiosi di vedere sempre più innovazioni e in tempi rapidi, e il mondo enterprise che invece desidera più stabilità e sicurezza. Nelle parole di Reinhold:

Una cadenza di rilasci biennale, in retrospettiva, è semplicemente troppo lenta. Per raggiungere una cadenza regolare dobbiamo pubblicare versioni feature a ritmo più rapido. Posporre una feature da una versione a un’altra dovrebbe essere una decisione tattica dalle conseguenze minime più che una decisione strategica con impatto significativo.
Per cui pubblichiamo una versione feature ogni sei mesi.

Ciò detto, vediamo dunque di esplicitare il predetto cambiamento sulle release di Java proposto da Reinhold e che sarà, tranne modifiche dell’ultima ora, operativo dal prossimo 20 marzo 2018.

I rilasci di Java cambieranno da un modello definito di tipo feature-driven (ogni rilascio era vincolato al completamento di importanti feature che poteva causare anche diversi anni di ritardo) ad un modello definito di tipo time-driven che garantirà:

• Una feature release ogni sei mesi. Questa conterrà qualsiasi cosa: da API nuove o migliorate a feature proprie del linguaggio o della JVM. Ogni release dovrà essere disponibile in marzo e settembre di ogni anno e la prima partirà dal marzo 2018 (JDK 10).
• Un update ogni tre mesi. Saranno limitati all’eliminazione di eventuali bug o alla risoluzione di problemi di sicurezza delle nuove feature. Ogni update dovrà essere disponibile in gennaio, aprile, luglio e ottobre di ogni anno.
• Una long-term support release (LTS) ogni tre anni, la prima delle quali partirà da settembre 2018 (JDK 11). Questa release avrà la garanzia di ottenere update almeno per tutti e tre gli anni della sua esistenza.

Per sapere proprio tutto della versione attuale di Java.

 
Nella pratica questo nuovo modello di rilascio, time-based, potrà soddisfare sia gli sviluppatori, più inclini a volere in tempi rapidi innovazioni e nuove feature per il linguaggio (adotteranno le feature release con update semestrali ma dovranno sottostare ad aggiornamenti comunque semestrali: Java 10, Java 11 eccetera), sia il mondo enterprise più incline, invece, a usare una release Java meno innovativa ma stabile (adotteranno una release long-term support con update garantiti per tutto il triennio e l’aggiorneranno solo dopo almeno tre anni).

Chiudiamo infine con una nota pratica su questo cambiamento dei rilasci di Java, che è esplicitato bene nel JEP 322 Time-Based Release Versioning del prossimo JDK 10, e ha sostituito la possibile stringa di versione proposta sempre da Reihnold, la quale avrebbe dovuto avere il formato $YEAR.$MONTH (per esempio, la release di marzo sarebbe stata designata 18.3, quella di settembre 18.9 e così via).

In accordo, dunque, con il JEP 322, la futura stringa di versione per Java sarà costituita dai seguenti elementi:

• $FEATURE: incrementata ogni sei mesi. In marzo 2018 varrà 10 (JDK 10), in settembre 2018 11 (JDK 11) e così via.
• $INTERIM: varrà sempre 0 perché in questo modello di rilascio ogni sei mesi non si avrà mai una versione intermedia. Verrà comunque lasciata per motivi di flessibilità e possibilità di utilizzo.
• $UPDATE: verrà incrementata un mese dopo l’incremento di $FEATURE e poi ogni tre mesi. Ad aprile 2018 avremo per esempio il valore 1 (JDK 10.0.1), a luglio 2018 il valore 2 (JDK 10.0.2).

A partire da marzo 2018 avremo quindi un nuovo release schedule per la piattaforma Java: piuttosto che una big release con una moltitudine di cambiamenti ogni tre o quattro anni, avremo tante piccole release ogni sei mesi. Dunque, dopo la release di JDK 9 (settembre 2017), avremo un JDK 10 a marzo 2018, un JDK 11 a settembre 2018 e così via. È un cambiamento notevole: vedremo che effetti avrà.