Tappa obbligata

A più riprese [1] [2] ci siamo occupati del lungo processo di “riconfigurazione” delle piattaforme Java SE e Java EE che, dopo un periodo di relativo immobilismo da molti imputato — forse anche eccessivamente — alle politiche di Oracle, avevano cominciato, poco più di due anni fa a riprendere progressiva accelerazione fino agli esiti di cui parleremo in questo articolo.

Con il rilascio delle specifiche di Jakarta EE 8 avvenuto lo scorso settembre, siamo finalmente arrivati a una tappa importante di questo processo di rilancio, con una piattaforma che non presenta novità tecnologiche eclatanti, ma che mette nuovamente a disposizione degli sviluppatori e delle aziende una versione open source e vendor neutral di Java EE 8, pur con tutte le necessarie modifiche.

Rimandiamo agli articoli nei Riferimenti — e, in maniera “annidata”, a quelli citati in tali articoli — il lettore che non abbia seguito tutta la vicenda e che sappia poco di questa “storia infinita”. Qui ci limiteremo a riassumere ancora una volta i problemi che sono insorti nel passaggio da Java EE di Oracle al nuovo progetto Jakarta EE della Eclipse Foundation.

Una controversia che non è solo nominale

Per riassumere al massimo, diremo che le trattative tra Oracle e la Eclipse Foundation per il passaggio di Java EE Oracle verso il nuovo progetto open Jakarta EE hanno avuto una serie di intoppi e che la proprietà di una serie di “marchi” commerciali ha finito per impedire alla Eclipse Foundation e al suo progetto Jakarta EE di poter usare il termine “Java”.

Il nucleo tecnico del problema sta “semplicemente” — si fa per dire — nel fatto che se Jakarta EE vuole essere una nuova incarnazione della piattaforma enterprise con future evoluzioni e un normale processo di versioni successive, è necessario svincolarsi dalla pesante eredità Java EE 8 Oracle legata anzitutto ai namespace javax.*, con tutti i potenziali problemi che questo comporta.

Rinominare tutto con il nuovo namespace jakarta.* avrebbe risolto tutti i problemi legati al marchio e alla licenza, liberando Eclipse dagli obblighi imposti da Oracle e consentendo di pianificare una roadmap per le evoluzioni future della piattaforma enterprise Jakarta EE.

Il fatto è che però le applicazioni attuali non avrebbero funzionato sulla nuova piattaforma senza prima un adeguato processo di refactoring e una ricompilazione delle stesse. Pur con tutte le soluzioni anche tecniche a questo problema che si possono individuare, si tratta veramente di una migrazione “epocale” di codice se si pensa al numero e alla portata delle applicazioni Java EE su cui si reggono moltissime attività.

L’orientamento prevalso su cui si è fin da subito orientata la Community è però stato proprio la soluzione drastica. Il problema del passaggio da javax.* a jakarta.* verrebbe risolto con un Big Bang, una sterzata brusca data una volta per tutte con il cambiamento verso jakarta.*

Ma questo creerebbe a sua volta altri problemi, pur svincolando definitivamente Jakarta EE da ciò che essa fu nel passato.

Jakarta EE 8: qualche considerazione

Proprio alla vigilia dell’importante conferenza EclipseCon Europe 2019 [3] che si terrà in Germania e che vedrà alcuni di questi temi trattati con dovizia di particolare, cerchiamo di capire brevemente cosa c’è di nuovo (poco) e di importante (molto) nella piattaforma Jakarta EE 8 da poco rilasciata.

Processo per la scrittura delle specifiche

Prima di tutto, va ricordato che è stato messo a punto un nuovo processo di raccolta delle specifiche, denominato Eclipse Foundation Specification Process (EFSP). Esso non è più concentrato sull’approccio “specification first” — come accadeva nel JCP — ma su una modalità “code first”: le lunghissime e burocratiche procedure di definizione e accettazione delle specifiche sono sostituite da un processo di validazione di software funzionante. Parallelamente si è lavorato anche sulla semplificazione del processo che certifica la “compliancy” da parte dei vari produttori. Il modello di governance è basato sulla community ed è di tipo multi-vendor senza il legame a un solo produttore.

Piena compatibilità con Java EE 8

Le specifiche di Jakarta EE 8 [4], sviluppate secondo il processo appena citato, sono pienamente compatibili con le specifiche di Java EE 8 di Oracle. Di fatto, Jakarta EE 8 include le stesse API e utilizza il medesimo modello di programmazione da sempre usato dagli sviluppatori Java. I Technology Compatibility Kit (TCK) sono pienamente compatibili con quelli di Java EE 8 perché basati su di essi. Sarà quindi possibile effettuare una migrazione verso Jakarta EE 8 senza dover modificare le applicazioni.

Questo aspetto è stato sottolineato anche dai produttori di middleware, come JBoss, che hanno affermato chiaramente la possibilità di portare le proprie applicazioni Java EE 8 su Jakarta EE 8 senza problemi.

La Ecliplse Foundation tiene a specificare che questa release è una base di partenza. Non è niente di nuovo, insomma, dal punto di vista tecnico, ma è la tappa obbligata da cui ripartire per l’evoluzione di delle tecnologie Java Enterprise verso un nuovo modello basato su un processo in cui la comunità ha il ruolo principale, che è aperto e che non è legato necessariamente a uno specifico produttore.

Questo implica anche la possibilità di un nuovo slancio da parte di produttori, sviluppatori e clienti vari che adesso hanno delle fondamenta sicure su cui possono trasferire le loro applicazioni e i loro prodotti Java EE. Jakarta EE 8 rappresenta il nuovo stack Java enterprise, standard, aperto e orientato al cloud.

Non si tratta solo di belle parole, ma di affermazioni basate sulla consapevolezza che aziende quali Fujitsu, IBM, Payara, Red Hat, Tomitribe — e addirittura la stessa Oracle con il server WebLogic — si sono impegnate seriamente nello sviluppo di prodotti perfettamente compatibili con Jakarta EE.

Server Jakarta EE 8

Oltre alle specifiche, la Eclipse Foundation ha rilasciato anche GlassFish 5.1.0 [5], l’application server “della casa”, totalmente compatibile con le specifiche Jakarta EE e che include l’implementazione delle API Jakarta EE, sia quelle “obbligatorie” che quelle opzionali, e supera tutti i test TCK di Jakarta EE. GlassFish è un prodotto già completo, dotato di console di amministrazione, funzionalità di clustering, e di tutta una serie di funzionalità e strumenti utili per gli sviluppatori e per chi si occupa della messa in produzione.

Ma non finisce qui. In accordo a quanto detto sopra riguardo al coinvolgimento di altre importanti aziende, anche IBM ha voluto fare la sua parte. E infatti, Open Liberty [6], il server runtime Java open source sviluppato con il supporto di IBM è stato certificato come pienamente compatibile con l’implementazione dei profili Jakarta EE 8.

Un primo passo verso il futuro

Anche se non introduce significative novità tecniche — e non poteva essere altrimenti — Jakarta EE 8 non è un semplice “reimpacchettamento” open di Java EE Oracle, ma rappresenta il passaggio necessario da cui ripartire per un’evoluzione della piattaforma enterprise in senso aperto e cloud native.

Restano aperti dei problemi sulla cui risoluzione sarà ora necessario concentrarsi per poter effettuare, finalmente, i passi successivi verso il futuro di Jakarta EE.

Al primo posto, c’è il problema del namespace di cui abbiamo già data ampia descrizione: sarà indispensabile da ora in poi risolvere il problema della transizione a jakarta.*   Quale strategia si seguirà? Vantaggi e svantaggi delle varie opzioni sono ormai ben noti. Si rinomineranno tutti i pacchetti, con la strategia “big bang” una volta per tutte — soluzione drastica e piena di conseguenze difficili da gestire, ma “definitiva” e capace di azzerare tutto per una ripartenza — oppure si seguirà una strada incrementale, rinominando solo i pacchetti in cui le API avranno subito reali cambiamenti? Quale che sia, una decisione si impone al più presto, ora che le specifiche Jakarta EE 8 sono state pubblicate e che si comincia a pensare alla versione successiva.

Altro problema è che, per quanto pubblicati, I documenti delle specifiche non sempre sono completi e dettagliati. I motivi sono molteplici, compresi dei ritardi nella consegna degli “originali” da parte di Oracle. Ad ogni modo, comunque sia andata, ciò implica che produttori e sviluppatori dovranno impiegare ancora svariato tempo prima di avere ben chiari alcuni dettagli e agire di conseguenza.

L’impressione è che la strada verso le evoluzioni future sia ancora lunga e che sarà necessario ancora un significativo periodo di “assestamento” per la definitiva affermazione di Jakarta EE 8.

Conclusioni

Non mancano i problemi e le incompiutezze, quindi, in questa piattaforma Jakarta EE 8. Ciò nonostante, si tratta di un importante punto di ripartenza verso la nuova dimensione che attende per i prossimi anni la piattaforma enterprise erede di Java EE. Di positivo c’è che ormai il gioco è in mano alla community che, per quanto attesa a un enorme lavoro, ha certamente le capacità per rimuovere gli ultimi blocchi e procedere oltre. Magari a passo lento ma, finalmente, libero e con una direzione abbastanza chiara.