Java SE e Jakarta EE

Un nuovo slancio dietro i nuovi nomi?di

Introduzione

Nei due articoli scritti meno di un anno fa (vedi riquadro “Articoli nella stessa serie” a destra più in basso) si riscontrava come, nel corso del 2017 si fosse passati per Java EE dalla stasi a un rilancio del processo di rilascio, con un nuovo garante che non sarebbe stato più Oracle, ma la Eclipse Foundation.

In questo articolo facciamo il punto di quello che è successo nel frattempo — decantate le acque — e allarghiamo il discorso anche a Java SE, visto che pure per la Standard Edition si presentano novità interessanti, specie se viste in prospettiva di lungo termine. E proprio da Java SE partiamo.

 

Un nuovo modello di rilascio

Storicamente, le varie versioni di Java sono state rilasciate con un modello feature-driven: dopo il lancio del linguaggio di programmazione, ogni versione successiva della piattaforma avrebbe dovuto contenere delle nuove funzionalità, dei miglioramenti, dei cambiamenti — in qualche caso anche abbastanza drastici — tali da giustificare la definizione di una nuova versione principale.

Eravamo negli anni del software desktop in cui ogni nuova versione di qualche “programma” di largo uso o di un sistema operativo veniva salutata con lo stesso entusiasmo con cui oggi tribù di fan boys accolgono l’uscita sul mercato dell’ultimo modello di iPhone. Erano altri tempi e periodi di due anni tra una version e l’altra non erano percepiti come infiniti, specie se a tale attesa corrispondeva effettivamente un cambiamento e/o un miglioramento del prodotto che si aveva sottomano.

Vizi e virtù del rilascio feature-driven

La tabella 1 mostra uno schema con la denominazione — quando presente — e la data di rilascio della versione standard di Java dal primo JDK del 1996 alla ultima recente versione. I lettori che desiderassero approfondire sia le vicende storiche che gli aspetti tecnici di questo lungo percorso possono leggere due articoli scritti da Luca Vetti Tagliati qualche anno fa [1] [2].

Tabella 1 – Schema riassuntivo delle versioni di Java SE. È interessante notare anche il cambiamento di denominazione: in particolare, quelli avvenuti tra le versioni Merlin, Tiger e Mustang suscitarono anche svariate discussioni.

Tabella 1 – Schema riassuntivo delle versioni di Java SE. È interessante notare anche il cambiamento di denominazione: in particolare, quelli avvenuti tra le versioni Merlin, Tiger e Mustang suscitarono anche svariate discussioni.

 

Questo approccio, secondo cui la nuova versione viene pubblicata quando sono pronte le feature che sono state pianificate per tale rilascio, ha funzionato perfettamente nei primissimi anni, su base annuale, e ha funzionato bene con cadenza biennale nella prima metà degli anni Zero, che hanno tra l’altro visto la grande affermazione delle tecnologie Java in senso lato.

Ma ha subito dei gravi intoppi, con rinvii, ritardi, ripensamenti e quant’altro a partire dalla seconda metà del decennio scorso: Java SE 7 ha richiesto quasi cinque anni per vedere la luce e le successive versioni 8 e 9 hanno “sforato” di parecchio il previsto periodo di due anni di sviluppo… E, oggigiorno in ambito IT, due anni sono davvero un’eternità.

Il passaggio alle release time-based

Come già illustrato nei precedenti articoli, su tali ritardi hanno avuto un impatto il mutato scenario IT, la riorganizzazione dei progetti Java legati al “passaggio di proprietà” da Sun Microsystems a Oracle — che ha peraltro comportato ulteriori cambiamenti per quanto riguarda Java EE, che vedremo più avanti nell’articolo — e anche l’affermazione di modelli di sviluppo e di gestione ispirati al pensiero Lean/Agile.

Tutto ciò ha condotto alla decisione di Oracle di passare, per Java SE, a un modello di rilascio basato su cadenze temporali prestabilite: d’ora in poi ogni sei mesi sarà rilasciata una nuova versione della piattaforma. La decisione, già presentata lo scorso settembre su suo blog dal Capo Architetto del Java Platform Group di Oracle [3], è stata precisata dalla “JEP 322: Time-Based Release Versioning” [4].

 

Caratteristiche e conseguenze della release a time-based

Il funzionamento del nuovo sistema è presto descritto e c’è anche un breve video che lo illustra [5]: in pratica ci saranno feature release o release principali, alcune delle quali saranno marcate come LTS (Long Term Support), saranno cioè supportate per svariati anni da Oracle, con un meccanismo che poi vedremo meglio. Accanto a queste release principali, ci saranno anche delle update release cioè degli aggiornamenti che però non contengono cambiamenti significativi. Ma vediamo in dettaglio questo schema.

Feature release

A marzo e settembre di ogni anno sarà disponibile una nuova versione di Java; questa nuova versione rilasciata su base semestrale conterrà comunque dei cambiamenti, definiti come feature o enhancement, intendendo con feature un cambiamento significativo o richiesto fortemente dalla comunità Java e con enhancement tutte le altre aggiunte. Gli elementi di dubbia definizione — “è una funzionalità o solo un miglioramento?” — saranno considearti come appartenenti alla prima categoria.

Long term release

Ogni tre anni, a partire da settembre 2018, la feature release distribuita sarà considerata come long term release (cioè una release a LTS, a supporto sul lungo periodo). Questo accorgimento, che è in linea con quanto avviene ad esempio per certi sistemi operativi o per certi applicativi legati al mondo della progettazione ingegneristica o della produzione industriale, è stato preso per garantire alle grandi aziende una delle caratteristiche che più richiedono: sistemi basati su feature stabili e affidabili che non richiedano la riscrittura del software a ogni nuova versione. Ma, al tempo stesso, non va a “frustrare” l’esigenza contrastante degli sviluppatori che invece vogliono nuove feature funzionanti non appena disponibili e che le troveranno ogni sei mesi nelle varie feature release anche non LTS.

Quanto sarà lungo questo supporto? Be’, svariati anni. Oracle dichiara che, anche per versioni “vecchie” di Java, come Java 8, per quanto il supporto tecnico e gli aggiornamenti siano prossimi a concludersi, il supporto commerciale durerà almeno fino al 2025…

E inoltre si punta su una sorta di “doppio binario” su cui far correre le distribuzioni di Java SE: una volta che il nuovo modello di rilascio sarà andato a regime, l’OpenJDK sarà il veicolo di distribuzione per tutte le feature release rilasciate con licenza “GPL + Classpath Exception” [6], mentre le long term release saranno rilasciate tramite Oracle JDK.

Updates release

Le updates release saranno distribuite ogni gennaio, aprile, luglio e ottobre e, come dice il nome, si tratterà di semplici aggiornamenti il cui scopo sarà limitato a risolvere bug, problemi di sicurezza e così via. In questo modo, ogni release semestrale di Java riceverà due aggiornamenti, ma poi sarà bene passare alla feature release successiva.

Per fare un esempio, la feature release scaricata in marzo, sarà aggiornata in aprile e luglio. Ma a settembre non riceverà più aggiornamenti e andrà rimpiazzata con la nuova feature release uscita in quel mese.

“Liti” sulle denominazioni

La nuova cadenza semestrale assume quindi questa fisionomia

  • settembre ’17 = Java 9
  • marzo ’18 = Java 10
  • settembre ’18 = Java 11
  • marzo ’19 = Java 12

e così via…

Ciò ha favorito la proposta di abbandonare la denominazione a numeri progressivi cui siamo abituati e passare a una denominazione anno.mese (yy.m) cara alle distribuzioni di certi sistemi operativi. Con questa proposta, l’elenco appena visto sarebbe diventato:

  • settembre ’17 = Java 17.9
  • marzo ’18 = Java 18.3
  • settembre ’18 = Java 18.9
  • marzo ’19 = Java 19.3

e così via… con le updates release che avrebbero aggiunto un ulteriore suffisso.

Ci sono però state molte discussioni sugli svantaggi di questo sistema e, per ora, quello che è stato approvato nelle specifiche è di denominare le nuove versioni, più o meno, alla vecchia maniera, lasciando il sistema yy.m nei documenti, solo per capire ciò di cui si sta parlando.

In particolare, lo schema previsto dalla JEP 322 è il seguente:

$FEATURE.$INTERIM.$UPDATE.$PATCH

Non è difficile da capire, ma occorre una precisazione. $FEATURE è evidentemente la feature release, e $UPDATE è uno dei due aggiornamenti alla release rilasciati ad aprile e luglio per la feature release di marzo e a ottobre e gennaio per quella di settembre.

Pertanto, prendendo ad esempio la release di marzo 2018, il suo $FEATURE è 10 (Java 10), e il primo $UPDATE (quello di aprile) sarà 1, mentre il secondo (quello di luglio) sarà 2.

Gli altri due elementi, sono “straordinari” e non fanno parte del consueto schema: per essere brevissimi, $INTERIM è riservato per eventuali motivi di compatibilità futura, ma non è previsto nel nuovo schema e quindi è sempre uguale a 0. $PATCH è riservato alle patch di emergenza per risolvere bug o problemi urgenti che non possono attendere il nuovo aggiornamento: se la patch è presente, allora se ne riporterà il numero; se invece, come è auspicabile, non è presente, non si riporterà nulla.

In definitiva, la update release (quindi release principale più aggiornamento) di luglio 2018 dovrebbe essere indicata come

10.0.2

dove il secondo numero è lo 0 corrispondente a $INTERIM che è appunto sempre 0. In tutta onestà, non il modo più sempice e lineare di denominare le versioni, ma c’è di peggio…

 

E Java EE?

Già… eravamo rimasti al trasferimento delle licenze e delle successive iniziative di sviluppo della piattaforma Enterprise da Oracle verso la Eclipse Foundation. Era stata una attestazione di valore per quelle posizioni [7] che fin da subito avevano capito che la strada più sensata, a fronte di un sostanziale immobilismo di Oracle, era il passaggio di Java EE a una fondazione open — con concrete realizzazioni nel proprio portfolio, comunque — realmente interessata a portarne avanti lo sviluppo.

Eclipse Enterprise for Java (EE4J)

Come sapete, lo scorso settembre il “prescelto” era stato Eclipse e in questi ultimi sei mesi sono stati fatti dei passi avanti, sebbene non siano mancati — neanche a dirlo, visto l’argomento — alcuni intoppi. La nascita dell’EE4J, il progetto Eclipse Enterprise for Java, in seno alla Eclipse, ha richiesto tempo ed energie; e a tal proposito, occorre però essere molto realistici: il passaggio delle licenze, l’acquisizione della code base, l’organizzazione dei gruppi di lavoro non sono attività che si portano a regime nel giro di due mesi.

Tra copyright e tecnologia

Lo scopo dichiarato di Eclipse era di prendere ciò che era Java EE 8, e spostarlo ulteriormente, da un punto di vista tecnologico, in direzione di microservizi, architetture cloud e serverless computing. Ma in questo percorso si è inserita una querelle relativa al nome del “prodotto” che ne sarebbe derivato: in breve, pur cedendo Java EE 8 a Eclipse, Oracle avrebbe preferito che i futuri sviluppi della Enterprise Edition non fossero più “marcati” Java, proprio per mantenere chiara la distinzione con Java SE il cui sviluppo — come visto nell’articolo — è stato reindirizzato su un binario più spedito.

Non è solo un problema di branding, come è facilmente comprensibile: se gli accordi prevedono che i package già esistenti in Java EE (javax.*) possano essere ancora usati, per i nuovi package che saranno sviluppati in futuro è richiesta una denominazione diversa, del tipo org.eclipse.xxx

Addio Java EE, betornato Jakarta EE!

Dopo una lunga e anche contrastata discussione, è stato recentemente deciso di abbandonare definitivamente la definizione Java EE e di parlare, d’ora in poi di Jakarta EE [9], che come molti di voi ricorderanno, non è affatto un nome nuovo nel panorama IT. Jakarta è stato un marchio abbandonato nel 2011, ma precedentemente usato dalla Apache Software Foundation che ne ha girato i diritti d’uso alla Eclipse Foundation.

Quando si decise di usare “Jakarta” per denominare una serie di progetti Apache (tra i quali emersero Struts e Tomcat, solo per dirne due), la scelta su questo nome fu fatto perché Jakarta è la principale città di Java (usando la grafia inglese). Al di là delle evocazioni di tipo geografico, la scelta di riutilizzare il termine per la nuova piattaforma Jakarta EE è stata fatta forse anche perché quella “J” iniziale è poprio la stessa di Java e potrà tornare utile in un gran numero di abbreviazioni.

 

Conclusioni

Per Java SE il quadro dei prossimi mesi appare abbastanza chiaro — e torneremo magari in un prossimo articolo a vedere gli aspetti tecnologici e le novità delle prossime versioni — almeno sul piano dei tempi e delle modalità di rilascio. Gli attuali sviluppi delle concezioni relative al processo di sviluppo del software non consentivano ulteriori ritardi nell’adozione di una modello basato su rilasci cadenzati a intervalli precisi e non troppo distanziati, i sei mesi appunto delle feature release.

Per Jakarta EE — e dobbiamo cominciare ormai a usare questa nuova denominazione — il discorso è un po’ più confuso. Si sa in che direzione si vuole andare, si è capito finalmente con quale modello e anche con quale “brand”, ma occorre ancora un po’ di tempo per cominciare a vedere ben delineata la rotta. Sicuramente torneremo a parlarne.

 

Riferimenti

[1] Luca Vetti Tagliati, L'evoluzione di Java: verso Java 8. I parte: Il caffè... da una quercia. MokaByte 171, marzo 2012

http://www.mokabyte.it/2012/03/javaevolution-1/

 

[2] Luca Vetti Tagliati, L'evoluzione di Java: verso Java 8. II parte: Da 1 a 7: il percorso fin qui (e anche un po‘ più avanti...). MokaByte 172, aprile 2012

http://www.mokabyte.it/2012/04/javaevolution-2/

 

[3] Mark Reinhold, Moving Java Forward Faster

https://mreinhold.org/blog/forward-faster

 

[4] JEP 322: Time-Based Release Versioning

http://openjdk.java.net/jeps/322

 

[5] Aurelio Garcia Ribeiro. Changes to JDK release model

https://goo.gl/tyNd2C

 

[6] GNU General Public License, version 2 with the Classpath Exception

http://openjdk.java.net/legal/gplv2+ce.html

 

[7] Java EE Guardians

https://javaee-guardians.io/

 

[8] EE4J

https://projects.eclipse.org/projects/ee4j/charter

 

[9] John K. Waters, Java EE Name Change To Jakarta EE. ADTMag

https://goo.gl/t7XCRx

 

Condividi

Pubblicato nel numero
238 aprile 2018
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…
Articoli nella stessa serie
Ti potrebbe interessare anche