No U-turn
Non si torna indietro. A più riprese ci siamo occupati negli ultimi due anni dei cambiamenti sopravvenuti in casa Oracle nella ownership, nel modello di rilascio e finanche nella denominazione di ciò che un tempo era semplicemente Java e che poi — differenziatosi nell’uso standard ed enterprise — era divenuto Java SE e Java EE. Ma di tempo ne è passato…
Meno di un anno fa pubblicavamo un articolo [1] che riassumeva il nuovo percorso di Jakarta EE e si concentrava sul nuovo modello di rilascio delle versioni “standard” di Java e del suo JDK. Rimandando a quell’articolo per approfondimenti, riassumiamo brevemente per i più pigri il nuovo schema di distribuzione.
Feature release, update release, , LTS
Ecco schematizzata la nuova modalità di distribuzione.
- A marzo e settembre di ogni anno veranno rilasciate delle feature release di Java cioè delle versioni principali che avranno delle nuove funzionalità o dei significativi miglioramenti rispetto alla precedente. La numerazione delle feature release è progressiva: per esempio, quella distribuita a partire da settembre 2018 è la 11.0 (per il significato di quel numero “0”, si rimanda all’articolo [1]).
- Ogni release principale riceverà solo due aggiornamenti, a cadenza fissa: la release principale distribuita lo scorso settembre ha ricevuto aggiornamenti in ottobre e gennaio, e quindi l’ultima versione è la 11.0.2. Tali update release sono solo aggiornamenti minori, per risolvere piccoli problemi o aggiungere miglioramenti secondari. La prossima release principale che uscirà a marzo 2018, sarà Java 12 e riceverà update release in aprile (12.0.1) e luglio (12.0.2). E via, avanti con questo schema che prevede di passare sempre alla nuova release principale ogni volta che essa sarà disponibile, ogni sei mesi, a ogni marzo e settembre.
- Questo schema piace molto agli sviluppatori che vogliono provare nuove funzionalità con cadenza semestrale, ma piace meno a chi deve garantire affidabili ambienti di produzione senza instabilità dovute eventualmente alle nuove versioni. Per questo, ogni tre anni, una delle versioni principali sarà “marcata” come Long Term Support (LTS) e supportata con aggiornamenti e patch per tutto il triennio.
La versione uscita a settembre 2018, Java 11 è considerata la prima Long Term Support e sarà supportata a lungo termine fino alla prossima LTS, prevista per settembre 2021.
Uso commerciale e JDK aperti
È qui che arriva l’inghippo. Se le feature release — o versioni principali — saranno rilasciate con licenza “GPL + Classpath Exception” (OpenJDK) [2], le Long Term Release saranno rilasciate tramite Oracle JDK quindi con una licenza che non è libera né gratuita.
Java 8 abbandonato… ma fino a un certo punto
Ora, la cosa “buffa” è che da un lato Oracle cesserà di rilasciare aggiornamenti gratuiti per Java 8 usato per scopi commerciali e raccomanda quindi di passare alle versioni più recenti di Java. Ciò implica, nel caso sia necessario affidarsi al supporto a lungo termine, di far ricorso alle distribuzioni LTS tramite Oracle JDK con un programma di abbonamento per utente/mese o per processore. Pur non essendo costosissimo tale programma può rappresentare un significativo aggravio per svariate aziende: si parte da 2,50 dollari al mese per utente e dai 25 dollari per processore e si “sconta” il costo al crescere dei volumi di adozione.
Dall’altro lato, però, Oracle fornisce un programma a pagamento [3] che continua ad assicurare assistenza ed eventuali aggiornamenti per il JDK 8 ben oltre la scadenza — si parla del 2025 — insita nel nuovo modello di distribuzione semestrale. In pratica, con una piccola forzatura, il JDK 8 diventa a sua volta una sorta di versione con supporto a lungo termine, anche se è fuori dal nuovo schema di distribuzione cominciato con Java 9.
Perché? La risposta è banale: Java 8 è ancora fortemente diffuso in molti ambienti e viene usato in numerosi progetti, che non sono sembrati così entusiasti di adottare le versioni successive. Java 8 fu un passo in avanti rispetto a un periodo di relativa stasi e — seppur con molti ritardi e sensate critiche — inglobò il Progetto Lambda con la programmazione funzionale.
E allora Java 11?
Ma allora, se si adotta un programma di abbonamento presso Oracle, perché non passare direttamente alla LTS Java 11 che è la versione più aggiornata — ancora per alcune settimane — e che, anche dopo l’uscita del JDK 17 previsto per settembre 2021, verrà comunque supportata per numerosi anni? Probabilmente le nuove funzioni — tra cui una migliore efficienza in termini di crittografia e sicurezza, il supporto a Unicode 10.0, miglioramenti alle prestazioni e l’introduzione di un Z-Garbage Collector sperimentale a bassa latenza — non fanno pari, per alcuni, con una serie di modifiche e di funzionalità definitivamente rimosse.
Nell’ottica di razionalizzare i pacchetti, Java 11 ha scorporato JavaFX — che resterà disponibile, ma come tecnologia a sé, slegata dal nuovo ciclo di distribuzione delle release — e ha definitivamente rimosso ciò che già era deprecato a partire dalla versione 9, ad esempio i moduli Java EE e CORBA ancora presenti e che effettivamente non servono più, anche tenendo conto delle attuali evoluzioni di Jakarta EE.
Però resta il fatto che alcune applicazioni vecchie — ma tuttora in uso — fanno affidamento proprio su quei moduli per funzionare senza problemi e potrebbero nascere delle incompatibilità di binari e codice sorgente nel passare applicazioni basate su JDK 6, 7 o 8 verso la nuova versione di Java.
Probabilmente, nulla a cui non sia possibile porre rimedio: ma i rimedi hanno un costo in termini di tempo, energie e applicazione. Certo, se pensiamo che CORBA è una tecnologia degli anni Novanta e che ormai ha perso tutti i vantaggi che poteva avere ai suoi inizi, comprendiamo l’approccio di Oracle, che magari punta anche a sollecitare uno svecchiamento del modo in cui sono costruite alcune applicazioni Java ormai datate. Però, anche qui… “se non è rotto, meglio non metterci le mani” resta un adagio seguito in molti ambienti di produzione.
Oracle e le sue alternative
Come messo bene in luce da Fabrizio Giudici nel suo articolo [4] pubblicato un paio di numeri addietro, questa rivoluzione nel sistema di distribuzione delle versioni — con la differenziazione tra release “proprietarie” disponibili via Oracle JDK e release “aperte” basate su OpenJDK e rilasciate con varie modalità [5] — apre degli scenari interessanti anche per distribuzioni alternative sullo stile di quello che avviene da un quarto di secolo per Linux.
E come per le distro Linux, anche per i JDK Java “non Oracle”, le diverse aziende seguono approcci e target diversificati per i JDK e i piani di supporto che propongono. Vediamo di seguito, molto brevemente, alcune di queste proposte, convinti che l’immediato futuro vedrà un po’ di fermento in questo campo, prima di arrivare a una certa stabilità.
Oracle LTS e Java SE Subscription
Abbiamo già detto abbastanza a proposito di questa soluzione “ortodossa”. Accanto al supporto LTS con Java 11, per i “nostalgici” del bel tempo che fu, resta attiva la Oracle Java SE Subscription [6] a pagamento, che oltre alla licenza per uso commerciale e al supporto tecnico, inlcude anche aggiornamenti alle versioni legacy di Java, prima fra tutte Java SE 8. I prezzi sono quelli indicati in precedenza.
Amazon: Corretto
Pur con i limiti indicati nell’articolo citato [4], Amazon Corretto [7] sembra promettere molto bene e prova ne sia che è la distribuzione di Java usata effettivamente da Amazon sui propri server. Accanto alla versione basata su OpenJDK 8, è disponibile la beta della versione 11, e ne è previsto il funzionamento sui tre principali sistemi operativi. I pacchetti sono scaricabili gratuitamente, ma il supporto segue anche qui un “doppio binario”: chi usufruisce dei servizi Premium AWS — e quindi paga Amazon per un’infrastruttura tecnologica — riceve un supporto a lungo termine con tutte le patch che saranno necessarie per la sicurezza e il miglioramento delle prestazioni. Gli altri dovranno far ricorso all’aiuto della community tramite GitHub.
Azul Systems: Zulu
Azul propone Zulu [8], una soluzione Enterprise dal costo non indifferente: circa 13000 dollari all’anno per un uso limitato a 25 sistemi, con un aumento dei costi per adozioni più ampie.
A fronte di questo investimento, Zulu mette sul piatto la sua esperienza, fornisce delle build certificate dell’OpenJDK, sia in versione 8 che 11, garantisce un supporto commerciale lungo otto anni in cui fornisce correzione di bug, aggiornamenti di sicurezza e tutte le altre patch necesssarie.
IBM: Runtimes for Business
Quella dei Runtimes for Business [9] è la proposta di IBM per certi versi simile alle altre, ma per alcuni aspetti un po’ diversa. I costi sono calcolati su base annua per utente autorizzato (48 dollari all’anno, cadauno) e garantiscono supporto commerciale diversificato per i runtime Java open source oltre al monitoraggio e alla gestione di applicazioni Java. “Diversificato” significa che, mentre per problemi minori si segue una normale procedura con orari di ufficio, i problemi più severi vengono seguiti con copertura continua e ininterrotta. Questo supporto riguarda le community builds dell’OpenJDK 8 che prevedono l’esecuzione della JVM OpenJ9 di Eclipse [10].
Va poi ricordato che IBM ha recentemente acquisito Red Hat — le due aziende, peraltro, erano da tempo partner — e pare che anche Red Hat dovrebbe fornire un supporto a lungo termine per una propria distribuzione dei OpenJDK per Windows. Si starà a vedere, perché le acquisizioni delle aziende portano a periodi di ristrutturazione che spesso hanno grossi impatti sui progetti in atto o previsti per il futuro. La storia di Java di questi ultimi anni ce lo ha ricordato.
Conclusioni
Come tutti i periodi di transizione e di cambiamento, anche il nuovo modello adottato per il versionamento e la distribuzione di Java ha creato delle difficoltà e dei malumori, ma al contempo ha aperto scenari legati alla distribuzione di OpenJDK “reimpacchettati” con un adeguato supporto a lungo termine.
È probabile che l’immediato futuro porterà chiarezza e linearità anche in questo campo: che ci si affidi alla LTS Oracle JDK o a qualche distro OpenJDK, le aziende troveranno il “vestito” più adatto alle loro esigenze e contribuiranno a spingere i grandi attori del mondo IT a trovare modalità di distribuzione delle versioni di Java in grado di garantire affidabilità e stabilità.