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.
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.