Rilasci basati sul tempo di Java

1. Introduzione

In questo articolo, discuteremo delle nuove versioni di Java basate sul tempo e dell'impatto su tutti i tipi di sviluppatori.

Le modifiche alla pianificazione del rilascio includono l'aggiornamento della fornitura delle funzionalità e dei livelli di supporto per le versioni di Java. Nel complesso, queste modifiche sono nettamente diverse da Java che è stato supportato da Oracle dal 2010.

2. Perché le versioni semestrali?

Per quelli di noi abituati alla cadenza di rilascio storicamente lenta di Java, questa è una partenza piuttosto significativa. Perché un cambiamento così drammatico?

In origine, Java ha definito le sue versioni principali attorno all'introduzione di funzionalità di grandi dimensioni. Ciò ha avuto la tendenza a creare ritardi, come quelli che tutti abbiamo sperimentato con Java 8 e 9. Ha anche rallentato l'innovazione del linguaggio mentre si sono evoluti altri linguaggi con cicli di feedback più stretti.

In poche parole, periodi di rilascio più brevi portano a passi avanti più piccoli e più gestibili. E le funzionalità più piccole sono più facili da adottare.

Un tale modello si accoppia bene nelle condizioni attuali e consente allo sviluppo di JDK di funzionare con metodologie agili simili alla comunità che supporta. Inoltre, rende Java più competitivo con runtime come NodeJS e Python.

Ovviamente, anche il ritmo più lento ha i suoi vantaggi, quindi il ciclo di rilascio di sei mesi gioca un ruolo anche in un framework di supporto a lungo termine più ampio, che esamineremo nella Sezione 4.

3. Modifica del numero di versione

Un aspetto meccanico di questa modifica è un nuovo schema del numero di versione.

3.1. Schema stringa versione JEP 223

Conosciamo tutti quello vecchio, codificato in JEP 223. Questo schema rendeva i numeri di versione incrementali e trasmetteva informazioni aggiuntive.

 Actual Hypothetical Release Type long short ------------ ------------------------ Security 2013/06 1.7.0_25-b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Security 2013/10 1.7.0_45-b18 7u45 Security 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60

Se eseguiamo java -version su una JVM per la versione 8 o precedente, vedremo qualcosa di simile:

>java -version java version "1.6.0_27" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

In questo caso, potremmo supporre che questo sia per Java 6, che è corretto, e il 27 ° aggiornamento, che è sbagliato. Lo schema di numerazione non è così intuitivo come sembra.

I rilasci minori erano multipli di 10 e i rilasci di sicurezza riempivano tutto il resto. In genere, vedremmo la breve stringa aggiunta alle nostre installazioni locali, come JDK 1.8u174. La prossima versione potrebbe essere JDK 1.8u180, che sarebbe una versione minore con nuove correzioni.

3.2. Nuovo schema stringa di versione

Il nuovo schema di stringhe di versione " rifonderà i numeri di versione per codificare non compatibilità e significato ma, piuttosto, il passare del tempo, in termini di cicli di rilascio " , secondo Mark Reinhold nel JEP.

Diamo un'occhiata ad alcuni:

9.0.4 11.0.2 10.0.1

A una rapida occhiata questo sembra essere il controllo delle versioni semantico; Tuttavia, questo non è il caso.

Con il controllo delle versioni semantico, la struttura tipica è $ MAJOR. $ MINOR. $ PATCH , ma la nuova struttura della versione di Java è:

$FEATURE.$INTERIM.$UPDATE.$PATCH

$ FEATURE è quella che potremmo pensare come la versione principale , ma aumenterà ogni sei mesi indipendentemente dalle garanzie di compatibilità. E $ PATCH è per le versioni di manutenzione. Ma è qui che finiscono le somiglianze.

Innanzitutto, $ INTERIM è un segnaposto, riservato da Oracle per esigenze future. Per il momento sarà sempre zero.

In secondo luogo, $ UPDATE è basato sul tempo come $ FEATURE e si aggiorna mensilmente dopo l'ultima versione della funzionalità.

Infine, gli zeri finali vengono troncati.

Ciò significa che 11 è il numero di rilascio per Java 11, rilasciato a settembre 2018, 11.0.1 è il suo primo aggiornamento mensile a ottobre e 11.0.1.3 sarebbe un'ipotetica terza versione di patch dalla versione di ottobre.

4. Distribuzioni di versioni multiple

Successivamente, diamo un'occhiata a come scegliere la versione giusta.

4.1. Stabilità

Simply put, Java now has a fast channel, every six months, and a slow channel, every three years.Each third-year release is called an LTS release.

On the fast channel, the language releases features in incubation. These language features stabilize in the LTS release.

So, for companies that can embrace volatility in exchange for using new features, they can use the fast channel. For enterprises that appreciate stability and can wait to upgrade, they can upgrade at each LTS release.

Experimentation with JDK versions enables developers to find the best fit.

4.2. Support

There's also, of course, the matter of support. Now that Java 8 support has sunset, what do we do?

And as discussed earlier, the answer comes in LTS versions, Java 11 being the most recent LTS release and 17 being the next. Updates will be available and supported by vendors such as Oracle and Azul.

If we can trust the support of the community, then Redhat, IBM, and others have stated their support for applying bug fixes for OpenJDK. Also, the AdoptOpenJDK project provides pre-built binaries for OpenJDK.

4.3. Licensing

One area of confusion for some is the difference between OpenJDK and Oracle JDK.

Actually, they are nearly identical, differing only in which bug fixes and security patches have been picked up, according to Brian Goetz.

OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.

4.4. Fragmentation

With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.

Of course, containerization could help address this. From Docker and CoreOS to Red Hat's OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.

5. Conclusion

In conclusione, possiamo aspettarci molto di più dal team Java di Oracle con un rilascio regolare di Java ogni sei mesi. In qualità di sviluppatore Java, la prospettiva di nuove funzionalità del linguaggio ogni sei mesi è entusiasmante.

Teniamo a mente alcune delle implicazioni mentre decidiamo quale sia il nostro canale di aggiornamento se abbiamo bisogno di supporto e licenza e come affrontare la frammentazione.