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.
Figura 2 – Lo schema del nuovo modello di rilascio delle versioni del JDK.
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à.
Luigi Mandarino ha cominciato ad appassionarsi ai computer con il glorioso ZX Spectrum 48k: una bomba, per l‘epoca 🙂 Dopo gli studi di ingegneria, si è dedicato per diversi anni allo sviluppo di applicazioni Java, specie per la piattaforma Enterprise. Successivamente, ha svolto il ruolo di architetto dei sistemi interessandosi particolarmente alle architetture di integrazione. Attualmente, svolge consulenze a svariate aziende in particolare nel settore bancario, assicurativo e finanziario, principalmente su temi inerenti le architetture Java EE e le dinamiche di processo secondo un approccio Lean/Agile.