La storia infinita

Evidentemente la “serialità” continua ad affascinare l’umanità fin dalle più antiche civiltà: dai poemi omerici alle medievali Chanson de geste, dalle trilogie di Star Wars al successo attuale del Trono di spade, passando per le innumerevoli telenovelas e soap operas degli scorsi decenni, abbiamo la conferma che seguire lo sviluppo di una serie di storie collegate è qualcosa che ci piace e, in certi casi, ci tiene avvinti a una saga.

Ora, con tutti questi fili narrativi che abbiamo a disposizione, francamente si potrebbe scegliere qualcosa di meglio rispetto a seguire “la storia infinita” connessa alle vicende di Java, nelle sue varie incarnazioni e, in particolare, nel passaggio da Java EE di Oracle a Jakarta EE della fondazione Eclipse. Ma la sorte ci ha riservato questo e, allora, con un ulteriore articolo, cerchiamo di fare il punto sugli ultimi, recentissimi sviluppi della questione.

Sì, perché l’ennesimo “intoppo” in questo lungo processo si è verificato proprio in questo maggio 2019, tanto da portare qualche osservatore a scrivere di “uccisione di Java EE” da parte di Oracle [3]. Mentre infatti le questioni che riguardano Java SE sembrano oramai avviate verso una normalizzazione [1] con vari tentativi di risoluzione dei diversi problemi che si presentano lungo il percorso, il passaggio da Java EE a Jakarta EE [2] ha incontrato un inatteso (?) stop proprio nelle ultime settimane.

Rimandando per un approfondimento della situazione all’articolo appena citato [2] e a quelli lì riportati nei riferimenti bibliografici, riassumiamo di seguito molto brevemente la questione per i lettori che già conoscono lo svolgimento degli eventi o che si accontentano di conoscerli per sommi capi.

Jakarta EE fin qui

Dopo l’acquisizione di Sun Microsystem in Oracle e la conseguente incorporazione del mondo Java da parte del colosso dei database, ci sono stati lunghi anni in cui non era chiara quale sarebbe stata la sorte di Java, in particolare della piattaforma Enterprise Edition.

Dopo un periodo di sostanziale immobilismo, attraverso varie vicende — che avevano visto anche prese di posizione molto nette da parte di alcune community di utenti e di esperti ex dipendenti Sun — si era finalmente arrivati a una lenta ripartenza durante i primi mesi del 2017. Nell’autunno di quell’anno, poi, giunse la notizia che ci sarebbe stato il trasferimento delle licenze, e delle successive iniziative di sviluppo della piattaforma Enterprise, da Oracle verso la Eclipse Foundation.

Il piano di Eclipse era sostanzialmente di ripartire da Java EE 8 facendolo evolvere ancor più verso lo stile architetturale a microservizi, il cloud e il serverless computing. Chiaramente, tutto questo processo che comportava il passaggio delle licenze, l’acquisizione della code base, l’organizzazione dei gruppi di lavoro non sarebbe entrato a regime nel giro di pochissimi mesi, ma richiedeva un certo tempo.

Tempo necessario anche per risolvere alcuni problemi legati a diritti di utilizzo, branding e denominazione del prodotto: Java (SE) sarebbe rimasto marchio di Oracle, mentre la piattaforma EE sarebbe stata ridenominata Jakarta, andando a ripescare il nome di un vecchio progetto sotto il cui “tetto” erano rientrate diverse tecnologie tra anni Novanta e primo decennio del nuovo Millennio.

È quindi cominciata una lunga fase di trattative tra Oracle ed Eclipse per definire i dettagli di questa transizione verso Jakarta EE. E, dopo circa un anno e mezzo di discussioni, siamo arrivati ad oggi.

Problemi sui “marchi”: non solo branding

E l’oggi non è lineare come ci si sarebbe aspettati inizialmente: era chiaro che Oracle volesse mantenere il controllo del brand Java e questo aveva comportato che Eclipse sarebbe diventata la custode di un “nuovo” prodotto, ossia Jakarta EE, piattaforma enterprise “nuova” ma creata sulle fondamenta — e anche su parecchio di più — di Java 8 EE.

Questo avrebbe potuto comportare dei problemi sul nome dei pacchetti, dal momento che il classico javax.* non era facile da cambiare, pena la mancanza di retrocompatibilità, in un nuovo jakarta.* che comunque sarà con ogni probabilità il namespace di ogni futuro nuovo pacchetto.

E allora che cosa è successo di preciso?

Lunghe trattative con il classico coltello dalla parte del manico…

Sul blog della Eclipse Foundation è stato pubblicato un breve resoconto [4] del punto di svolta — o di stallo, a seconda della prospettiva — a cui le trattative tra Oracle ed Eclipse sono arrivate in questi giorni. Non è la sola fonte da cui attingere informazioni, visto che lo Steering Commitee di Eclipse ha pubblicato anche dei riassunti delle varie riunioni [5].

Alcuni dei punti salienti che si possono estrapolare dal post e dalle altre fonti, e che ci informano su cosa non è andato nelle trattative, sono i seguenti:

• non è stato possibile trovare un accordo tra Oracle ed Eclipse riguardo ai termini d’uso dei marchi registrati Java — presenti nei prodotti Java EE che Eclipse sta usando come base per la transizione — tuttora di proprietà di Oracle che ne nega l’uso libero a Eclipse; da quanto si intuisce, sembra che questo approccio così restrittivo sia intervenuto in fase di trattativa e non fosse stato manifestato fin dall’inizio del processo di passaggio Oracle Java EE 8 —> Eclipse Jakarta EE 8;
• Oracle consente l’uso dei pacchetti con namespace * all’interno delle specifiche Jakarta EE, ma solo a patto che essi non siano modificati in alcun modo; dovrà infatti essere garantita la totale compatibilità con le specifiche Java EE corrispondenti;
• dal punto precedente deriva la richiesta di Oracle che i “nuovi” — per modo di dire — pacchetti * presenti in Jakarta EE debbano continuare a rispettare i medesimi requisiti di compatibilità per quanto riguarda container e distribuzioni certificate che avevano prima; per capirci meglio, i pacchetti javax.* eventualmente contenuti in Jakarta EE dovranno essere testati e distribuiti con container che contengano implementazioni di Java SE certificate sotto licenza Oracle e non di altri produttori, eliminando di fatto l’intenzione di essere vendor-independent;
• il nome Java EE deve sparire dalla denominazione dei vari pacchetti e delle varie tecnologie e pertanto devono essere cambiate denominazioni e sigle tipo Java Persistence API (JPA), Enterprise JavaBeans (EJB) e molte altre; appare chiaro che non si tratta del problema più grande, ma è comunque un ulteriore adempimento a cui ottemperare.

Conseguenze e considerazioni

Al di là di valutazioni “morali” (“Oracle se ne è approfittata…”, “No, è stata Eclipse a comportarsi ingenuamente!”) che lasciano un po’ il tempo che trovano, e prima ancora di passare agli aspetti più strettamente tecnici, ci sono delle considerazioni di tipo legale e commerciale da tenere presenti, e che fanno capire quanto sia problematica una questione come quella che stiamo illustrando.

Per il diritto commerciale USA, Eclipse è una fondazione, con un preciso statuto e svariate clausole cui ottemperare per mantenere questo status, il quale garantisce, tra l’altro, una serie di esenzioni fiscali che — detto molto ruvidamente — “consentono alla baracca di stare in piedi”. Se Eclipse venisse meno ad alcuni dei principi che la connotano come fondazione, e non come azienda, dovrebbe cominciare a pagare al fisco delle cifre molto più sostanziose di quelle che paga adesso e finirebbe per dover chiudere i battenti.

Proporre ad Eclipse di rimanere legata a un solo vendor — in questo caso Oracle — significa proprio farla rinunciare a questa sua posizione di neutralità. Pertanto Eclipse proprio non può accettare le condizioni che la costringono a distribuire esclusivamente container e versioni di Java SE con licenza Oracle e non anche di altri produttori (IBM, Red Hat…) perché perderebbe il suo status di fondazione e finirebbe, con ogni probabilità, impossibilitata a continuare le sue attività.

Se poi questa mossa sia stata fatta da Oracle in maniera studiata, o semplicemente per il desiderio di mantenere il controllo su Java, non possiamo dirlo noi. Quello che sembra di capire dalla documentazione, però, è che queste restrizioni sono apparse durante le trattative e non erano state palesate fin dall’inizio del processo di trasferimento di Java EE verso Jakarta EE. Magari si è trattato di una contromossa di Oracle nei confronti di IBM, che aveva donato a Eclipse la JVM OpenJ9, ma di fatto ha messo in seria difficoltà i nuovi “gestori” di Jakarta EE.

I prossimi passi

Non è una situazione facile dalla quale muoversi: da varie parti si sono levate critiche e riflessioni che vedono molto difficile trovare una soluzione ai numerosi problemi sollevati da questo mancato accordo.

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

Se tutto venisse rinominato con il nuovo namespace jakarta.* ad esempio, ciò risolverebbe tutti i problemi legati al marchio e alla licenza, libererebbe Eclipse dagli obblighi imposti da Oracle e consentirebbe di pianificare una possibile roadmap per le evoluzioni future della piattaforma enterprise Jakarta EE.

Il fatto è che però le applicazioni attuali non funzionerebbero sulla nuova piattaforma senza prima un adeguato processo di refactoring e una ricompilazione delle stesse. Certo, si possono cercare delle soluzioni anche tecniche a questo problema, ma si tratterebbe veramente di una migrazione “epocale” di codice se si pensa al numero e alla portata delle applicazioni Java EE su cui si reggono moltissime delle attività economiche di questo pianeta…

Dal punto di vista degli sviluppatori occorrerà cambiare il codice dell’applicazione e le batterie di test, verificare tutto il codice di terze parti che fa riferimento alla specifica e così via… Non è poco lavoro!

Ma l’intenzione, dalle parti di Eclipse, sembra proprio quella di lavorare per rimuovere quanto prima i riferimenti a javax e rinominare tutto quanto [6] cercando le soluzioni tecniche che possano minimizzare i problemi connessi a tale scelta drastica: “minimizzare” comunque non significa “azzerare”.

L’unica cosa che appare chiara è il desiderio di “togliersi il dente” prima possibile: se questa sia la scelta migliore lo scopriremo nei prossimi mesi o, probabilmente, anni. Di sicuro, una volta superato l’enorme ostacolo rappresentato dalla migrazione verso Jakarta EE 8 con licenza open Eclipse, è possibile ipotizzare una progressione molto più lineare verso Jakarta EE 9 come scritto proprio nei comunicati della Eclipse Foundation. Però occorrerà capire se e come si supererà l’ostacolo grosso che si è profilato all’orizzonte.

“Intanto, a Gotham City…”

Concludiamo questo articolo con il riferimento a una notizia che, a dire il vero, c’entra poco con gli aspetti tecnici e strategici legati alla piattaforma Jakarta EE, ma che si collega però idealmente a quanto scritto finora.

Il concetto è che, come accade con i corsi d’acqua, se c’è una portata… una via per scorrere fino al mare si troverà. Potrà essere rappresentata dalle acque sommerse di un fiume carsico, dal piccolo e tortuoso corso di un torrente di montagna, o dall’ampio alveo di un fiume in pianura capace di esondare per kilometri anche se costretto entro stretti argini per certi tratti. E, passateci la metafora, questo succede anche con le tecnologie e con i linguaggi: se un “prodotto” ha una portata sufficiente, si fa strada anche laddove sembri potenzialmente arginato da tecnologie più conosciute e più affermate, o da accordi commerciali. Succederà per Jakarta EE? Non lo sappiamo.

Ma sappiamo che è già successo per Kotlin, linguaggio di programmazione conciso e produttivo, basato su JVM, completamente interoperabile con Java in entrambe le direzioni e che supporta sia il paradigma di sviluppo orientato agli oggetti che quello funzionale [7]. Kotlin può essere considerato a buona ragione nello sviluppo di nuove applicazioni, sia in ambito Android che lato server, come complemento o sostituto di Java.

A “certificarlo” è proprio Google che, alla conferenza degli sviluppatori Google I/O di Mountain View in California, nelle parole di Chet Haase — direttore del team di sviluppo UI di Android in Google — ha raccomandato di usare Kotlin come prima scelta per lo sviluppo di applicazioni Android: Java e C++ continueranno ad essere supportati, ovviamente, ma la preferenza è per Kotlin.