Miti da sfatare

Forse qualcuno ricorderà una trasmissione televisiva di qualche anno fa, Miti da sfatare. Con un approccio molto “americano”, i due conduttori organizzavano esperimenti e prove varie per verificare la validità di leggende metropolitane o interrogativi più o meno credibili, decretando infine se fossimo in presenza di un “mito” nato da chissà quale ragione, oppure se si trattasse di fatti verificabili e veritieri.

Lo stile per divulgare delle verità scientifiche era sicuramente poco ortodosso ma, in svariate occasioni, i casi erano presentati in maniera seria e documentata e consentivano al telespettatore di riflettere e comprendere i meccanismi dietro certi fenomeni.

A questa trasmissione devono essersi ispirati gli attuali responsabili di Jakarta EE nel momento in cui hanno deciso di proporre alcuni seminari online [1] per sfatare i miti sulla piattaforma open che ha preso il posto di Java EE.

L’idea è di aiutare una ripartenza della piattaforma partendo dalla consapevolezza che Java può apparire “vecchio” dal momento che ha superato ormai il quarto di secolo di esistenza. La longevità del linguaggio e della piattaforma — e soprattutto le vicende articolate che hanno segnato il passaggio prima da Sun a Oracle e poi, nel 2017, da Oracle a Eclipse [2] — hanno creato sicuramente dei problemi a Java, ma non hanno intaccato il fatto che esso resti uno dei linguaggi di programmazione più conosciuti e usati al mondo, e che la relativa piattaforma enterprise mantenga un’affidabilità e una versatilità tali da renderla ancora una soluzione credibile per molte applicazioni di business.

Il primo dei seminari si intitola, non a caso, Is Java EE Outdated and Dead? ma quelli successivi saranno più tecnici e dedicati ad aspetti specifici (cloud, microservizi, modelli di deployment).

Ripartenze

Un tale attivismo si spiega bene con il recente rilascio di Jakarta EE 9.1 [3], un passo decisamente importante nel percorso di rinascita della piattaforma Enterprise.

Come già illustrato in articoli precedenti, il passaggio da Java EE a Jakarta EE ha rappresentato la svolta verso quello che, forse con un po’ di enfasi, la Eclipse Foundation definisce “il futuro di Java cloud-native”).

Da un certo punto di vista, questo futuro è anche un po’ un ritorno all’antico, perché con il passaggio a Jakarta EE è stato messo a punto un nuovo processo di raccolta delle specifiche, che “idealmente” si riaggancia a quanto accadeva con il JCP, ma supera le lentezze di quell’approccio con una modalità “code first” e un abbandono definitivo delle procedure lunghe e burocratiche in favore di un processo di validazione del software funzionante.

Jakarta EE è infatti una piattaforma che consiste di API e documenti di specifiche, TCK (Technology Compatibility Kit, che servono a verificare e validare il codice implementato a partire da API e specifiche)e implementazioni compatibili, ossia quelle che hanno superato positivamente il vaglio del TCK.

E poi c’è l’importanza del contributo fornito dai vari produttori che adesso hanno delle fondamenta sicure su cui possono trasferire le loro applicazioni e i loro prodotti Java EE.

Il rilascio delle nuove versioni

Uno degli aspetti più importanti affrontati dal Jarkarta EE Working Group — che all’interno della Eclipse Foundation è risponsabile dello sviluppo della piattaforma enterprise — era quelllo di cambiare il modello di rilascio delle nuove versioni, puntando a una maggiore frequenza di nuove versioni incrementali.

Un tempo, tra una versione e l’altra di Java, che fosse linguaggio standard o piattaforma enterprise, passavano anni, e questa lentezza si era ulteriormente aggravata nel periodo di gestione di Java da parte di Oracle.

Da qualche tempo a questa parte le cose hanno preso una relativa speditezza e, dopo il rilascio di Jakarta EE 8 nell’autunno del 2019 — sostanzialmente un “reimpacchettamento” di quanto già esisteva —, a dicembre 2020 era arrivata la versione 9 con le prime reali novità, tra le quali il famigerato cambiamento di namespace da javax.* a jakarta.*

Arriva Jakarta EE 9.1

Da pochissime settimane sono state rilasciate le specifiche versione 9.1 della piattaforma e del web profile di Jakarta EE. Il web profile, se qualcuno casomai non lo sapesse, è un sottoinsieme delle funzionalità dell’intera piattaforma creato nell’ottica di limitare l’impronta dei container web, in termini sia fisici che concettuali.

Breve parentesi su Java SE: versioni “feature” vs. “LTS”

Prima di passare in veloce rassegna le novità di Jakarta EE 9.1, dobbiamo fare un breve accenno alla versione standard del linguaggio, e al JDK. Come i lettori sapranno, se la piattaforma enterprise è passata alla Ecliplse Foundation diventando Jakarta EE, invece Java SE è rimasta nell’ambito di Oracle.

Con il nuovo schema di rilascio delle versioni di Java SE messo a punto da Oracle, è stato finalmente abbandonato il modello che vedeva la pubblicazione di aggiornamenti corposi a distanza di molti anni da una versione all’altra e si è preferito un approccio incrementale.

Ogni sei mesi esce una versione nuova di Java SE, con le nuove funzionalità che sono pronte al momento. Si tratta delle cosiddette feature release, che si susseguono con costanza. Al momento della pubblicazione di questo articolo (giugno 2021), la feature release corrente è il JDK 16, pubblicato lo scorso marzo. Le feature release (non LTS) smettono di ricevere supporto quando vengono pubblicate quelle nuove.

Esistono però dei JDK che sono marcati come LTS, Long Time Support release, ossia per i quali è garantito supporto a lungo termine, per svariati anni. Questi sono quelli da usare in produzione per la realizzazione di applicazioni che dovranno “durare” nel tempo: ogni tre anni, una versione del JDK viene contrassegnata come LTS proprio per dare agli sviluppatori uno strumento affidabile e durevole. Al momento, la versione LTS è il JDK 11 (supporto almeno fino a settembre 2023), ma per settembre 2021 è prevista la nuova release LTS che sarà la JDK 17, la quale ci accompagnerà fino al 2024 (e sarà supportata fino al 2026).

Alcune novità di Jakarta EE 9.1

La parentesi appena vista su Java SE di Oracle, con i suoi JDK di tipo feature o LTS ci è servita per dire anzitutto che la nuova versione di Jakarta EE 9.1 è pienamente compatibile con Java SE 11, oltre che con la precedente Java SE 8. Questo è importante anche perché, in base a “sondaggi” effettuati presso la comunità degli sviluppatori, si era visto come l’uso della versione Java SE 11 LTS fosse cresciuto significativamente, arrivando nel 2020 a quasi un terzo degli sviluppatori che utilizzano Java SE come base per il loro lavoro. L’interoperabilità tra le due piattaforme, standard ed enterprise, garantisce a questo punto una notevole libertà di azione agli sviluppatori.

Altri aspetti da tener presenti sono anzitutto il fatto che siamo di fronte a una versione a incremento minore (9.1) il che segnala come ormai il meccanismo degli incrementi piccoli e frequenti sia finalmente entrato a regime. Come per la precedente versione 9, Jakarta EE 9.1 presenta un meccanismo che consente la migrazione di precedenti applicazioni Java EE 8 e Jarkarta EE 8 verso la nuova piattaforma.

Accanto alle specifiche e al web profile, sono stati rilasciati i TCK (Technology Compatibility Kit) che consentono di verificare la compatibilità del codice prodotto.

Tra le implementazioni di riferimento già verificate come compatibili con Jakarta SE 9.1, possiamo citare:

• Eclipse Glassfish
• Apache TomEE
• IBM Open Liberty
• Red Hat Wildfly
• ManageCat ManageFish

Come ulteriore nota, va detto che anche il Framework Spring farà finalmente il passo verso Jakarta 9.x, adottando il namespace jakarta.* nei pacchetti.

Conclusioni

La versione 9.1 di Jakarta EE non è nulla di rivoluzionario, ma è importante perché rappresenta un momento decisivo nella “normalizzazione” del processo, lungo e tormentato, che ha portato al passaggio da Java EE a Jakarta EE. Il meccanismo è stato avviato con la versione 8, ha fatto il primo significativo passo con Jakarta EE 9 ed è entrato a regime con questa versione incrementale.

In quest’ottica, il Jakarta EE working group della Eclipse Foundation, sta già pianificando Jakarta EE 10, nella quale saranno probabilmente preseni nuove funzionalità cloud native. Il contributo delle aziende interessate a unirsi al gruppo di lavoro sarà sicuramente importante.