Introduzione

Che qualcosa si stesse finalmente muovendo per quello che riguarda la piattaforma Enterprise Edition di Java era apparso chiaro negli ultimi mesi. E di questo rimettersi in moto del processo che porta a Java EE 8 avevamo dato conto in un articolo [1] sul numero scorso di MokaByte.

Avevamo raccontato come, dopo l’acquisizione da parte di Oracle avvenuta nel 2010, tutto il processo di sviluppo delle nuove versioni di Java (sia SE che EE) avesse subito un rallentamento dovuto, a detta di molti, anche alla politica di “chiusura” e “accentramento” delle operazioni, messa deliberatamente in atto dal colosso dei DataBase.

Nello stesso articolo, a cui rimandiamo per eventuali approfondimenti, si tentava anche di dare una spiegazione dei motivi per cui si erano verificate tali scelte “politiche” verso il micromanagement e l’accentramento, con esclusione progressiva del ruolo della comunità : tra queste ragioni, un peso lo aveva sicuramente avuto il contenzioso legale tra Oracle e Google sui diritti di riuso del codice della JVM.

Avevamo poi raccontato di iniziative da parte di “gruppi di pressione” ad esempio i “Guardiani di Java EE” che indicavano a Oracle una via diversa da seguire in futuro per una proficua continuazione del percorso intrapreso da Java nei venti anni abbondanti di passati dalla sua nascita.

L’articolo si chiudeva riportando tutta una serie di traguardi che cominciavano a essere raggiunti e che ci facevano comprendere come, alla fine, pur con tutti gli intoppi degli anni precedenti, la versione 8 di Java EE stia finalmente per vedere la luce.

Java diventa open… ma non lo era già?

Pur con questa positiva ripresa del percorso di rilascio di Java EE 8, in pochi comunque si aspettavano che ci sarebbe stato un annuncio abbastanza sorprendente ad agosto… e uno ancor più dettagliato in settembre. Però — e occorre darne atto a chi lo aveva detto chiaramente come i Java EE Guardians [2] — c’era chi auspicava che Java EE fosse instradata verso un percorso di “cessione” a una fondazione open source, in cui codice, licenze e implementazioni di riferimento venissero donati a chi poteva garantirne lo sviluppo negli anni.

Opening Up Java EE

Su “The Aquarium”, uno dei blog di Oracle, il 17 agosto 2017 è stato pubblicato un articolo [3] intitolato appunto Opening Up Java EE in cui vengono delineate alcune possibili “rotte” da seguire nei prossimi anni per gestire al meglio l’evoluzione e lo sviluppo di Java EE.

Lì per lì, si è trattato solo di annunciare una possibilità per il futuro le cui modalità e i cui tempi sembravano ben lontani dall’esser definiti. Di certo, rispetto al periodo di stasi e di “impaludamento” a cui avevamo assistito negli ultimi anni, questo risultava comunque un annuncio dirompente.

I contenuti dell’annuncio

Prima di fare qualche considerazione e di illustrare anche i recentissimi passi successivi, cerchiamo di riassumere il contenuto dell’annuncio. Abbiamo riportato in grassetto alcune parti che ci sono apparse particolarmente significative.

• Java EE è una piattaforma complessa, tecnologicamente importante, molto diffusa, sulla quale sono basate molte applicazioni in grado di portare valore alle aziende e agli utenti finali.
• I lavori per Java EE 8 continuano a procedere e le specifiche sono quasi complete. Si ritiene che l’implementazione di riferimento possa essere rilasciata per la fine dell’estate.
• Una volta completata la versione 8, sarà arrivato il momento opportuno per ripensare il modo in cui viene sviluppato Java EE. L’obiettivo è rendere il processo più agile e capace di rispondere ai cambiamenti industriali e alle necessità tecnologiche.
• Va notato che Java EE è già sviluppata in modo open source con la partecipazione della comunità . Ma spesso questo processo non è visto come sufficientemente agile, flessibileo aperto, soprattutto se paragonato a quanto accade per altre comunità open source: occorre fare meglio.
• Una strategia possibile per migliorare il processo di sviluppo e di rilascio di Java EE potrebbe consistere nel trasferire le tecnologie Java EE, comprensive delle implementazioni di riferimento e del kit per testare la compatibilità, a una fondazione open source. Questo consentirebbe di adottare processi più agili, implementare delle licenze più flessibili e, in definitiva, cambiare il modello di governance.
• Questa possibilità sarà discussa con la comunità, i licenziatari dei prodotti e alcune fondazioni che si candidino a raccogliere questo impegno. Si ritiene che un processo più aperto, che non sia dipendente da un singolo produttore in qualità di decisore primario per quel che riguarda la piattaforma, possa avere un positivo impatto sull’innovazione grazie a una maggiore partecipazione, negli interessi di tutti gli attori coinvolti.

Il comunicato si concludeva poi con un riferimento all’impatto che una tale scelta potrebbe avere per quel che riguarda WebLogic Server [4]. È chiaro come, per quanto si intenda procedere verso una maggiore apertura della piattaforma, occorra anche tutelare gli aspetti commerciali legati alla politica sulle licenze, nonché agli aspetti tecnologici, dell’Application Server per Java EE di casa Oracle. Ossia: avanti, ma con prudenza, perché nessuno deve “spaventarsi” per ciò che potrebbe accadere in futuro.

Qualche considerazione

Il contenuto di questo comunicato non necessita certo di una raffinata opera di interpretazione. Ci sono però alcuni aspetti su cui fare la pena di soffermarsi.

Anzitutto, in più passaggi, viene utilizzato il termine agile, si parla di “rispondere al cambiamento”, si evoca la flessibilità, a dimostrazione del fatto che certe istanze e certe idee, chiaramente ispirate al Manifesto Agile, a poco a poco, si sono fatte largo anche in aziende tradizionalmente “rigide” come Oracle.

Poi si fa comprendere che la soluzione possibile è proprio quella, da molte parti auspicata, di passare il processo di evoluzione di Java EE a una fondazione open source da scegliere, insieme alla comunità, tra varie candidate. E su questo aspetto, si approfondirà più avanti.

Ma, probabilmente, il passaggio più interessante è quello in cui si ricorda che, almeno da un punto di vista formale, il processo di sviluppo di Java EE è già “aperto” ed ha già una community a cui fare riferimento. E riconoscerlo significa almeno due cose: da un lato, Oracle si prende le sue responsabilità e ammette che il suo ruolo di decisore primario ha finito per sclerotizzare l’intero avanzamento di Java EE e le possibilità di innovazione, perché di fatto ha ridotto al minino lo spazio per questa community e ha reso un prodotto, formalmente aperto, sempre più proprietario nel concreto.

Ma, dall’altro, si prende anche atto che un programma come il Java Community Process [5] è tuttora ancorato a certi stilemi degli anni Novanta — in cui Java muoveva i suoi primi passi — e ha probabilmente fatto il suo tempo; necessita quindi esso stesso di una buona dose di innovazione organizzativa per adattarsi agli scenari mutati non solo in termini tecnologici, ma soprattutto organizzativi e metodologici.

I perché di una scelta

Prima di andare a vedere gli ultimi sviluppi, cerchiamo di capire i diversi motivi per queste scelte. Quanto appena detto spiega in parte il perché: gli scenari mutano, l’accentramento e il micromanagement non sono la risposta giusta, un processo più agile e aperto potrebbe essere la via da seguire.

Ma in tutto questo pesano probabilmente anche delle componenti tecnologiche che hanno a che fare anch’esse con i mutati scenari a livello architetturale.

Cloud e microservizi

Ciò che negli ultimissimi anni è avvenuto nell’ambito delle architetture per i sistemi enterprise — vale a dire l’affermazione dei servizi cloud, la diffusione di container potenti e affidabili, la comune accettazione del paradigma dei microservizi — ha avuto ovviamente dei riflessi anche sulla piattaforma Java EE che resta uno degli elementi fondamentali per realizzare sistemi grandi e affidabili.

Questo ha portato anche alla nascita, ad esempio, di soluzioni quali l’Eclipse MicroProfile [6] che punta a ottimizzare la piattaforma enterprise Java per le architetture a microservizi. Si tratta di una definizione di piattaforma che intende rendere migliore l’utilizzo di Java EE in un’architettura a microservizi, favorendo la portabilità delle applicazioni attraverso svariati runtime MicroProfile. La definizione iniziale di questa piattaforma prevede JAX-RS + CDI + JSON-P e contempla un ruolo attivo della community Eclipse nello sviluppo del MicroProfile.

Attualmente è stata annunciata la versione 1.1 ed è da notare come il rilascio delle varie versioni sia scadenzato su un modello time-boxed invece che su un modello content-based. In pratica, si fa la release con quello che è disponibile in quel momento, sottraendosi in questo modo al meccanismo di ritardi che tanto ha inficiato l’avanzamento dei lavori per Java EE negli ultimi anni.

Gli ultimi sviluppi, per ora

E a confermare l’importanza anche di questi aspetti tecnologici, è arrivato un recente comunicato di Oracle [8], che chiarisce alcuni aspetti rimasti in sospeso nel precedente annuncio, a partire dalla individuazione di chi porterà avanti lo sviluppo di Java EE. E, con quello che si è appena detto a proposito del MicroProfile, non stupisce che la Fondazione prescelta sia la Eclipse Foundation [9].

Riassumendo, per punti, il nuovo comunicato — come al solito il grassetto è nostro — si apprende quanto segue.

• Dopo aver consultato vari vendor, è stato raggiunto un accordo con IBM e Red Hat — che sono poi i maggiori contributori alla piattaforma Java Enterprise —per collaborare al processo di transizione che attende Java.
• Le licenze in capo a Oracle relative alle tecnologie Java EE e GlassFish saranno trasferite alla fondazione, comprensive di Reference Implementation (RI) e Technology Compatibility Kit (TCK).
• Si definirà una strategia di branding insieme alla fondazione, che porterà al cambiamento di nome di Java EE. Allo scopo di garantire continuità e compatibiità, i nomi dei vari pacchetti e componenti e JSR esistenti non cambieranno.
• Si definirà il processo con cui far evolvere le specifiche esistenti e quelle nuove.
• Sviluppatori e altri membri delle community, nonché produttori vari, saranno messi nelle condizioni di contribuire alla piattaforma nell’ambito della fondazione. Questo potrebbe portare anche alla possibile incorporazione delle tecnologie Eclipse MicroProfile nella piattaforma enterprise.
• Dopo incontri con varie fondazioni e attenta riflessione, è stato deciso che a prendere in carico Java EE sarà la Eclipse Foundation anche in virtù della grande esperienza con le tecnologie Java.

Nel comunicato non mancano poi da un lato i prudenti richiami al fatto che questo è quanto progettato, ma si dovranno poi fare i conti con tutti i possibili problemi che emergeranno; ma c’è anche l’esortazione a cominciare questa transizione al più presto, non appena Java EE 8 sarà stata completata. Chiaramente, Oracle continuerà a supportare i licenziatari delle tecnologie precedenti alla transizione, compreso Java EE 8 e il suo funzionamento in una futura versione di WebLogic Server.

Conclusioni

Lo dicevamo all’inizio: per Java EE nel giro di un anno si è passati dalla stasi all’annuncio di un nuovo processo che ne garantirà l’evoluzione, con un nuovo garante che non sarà più Oracle, ma la Eclipse Foundation. È troppo presto per capire tutti i dettagli, visto che si comincerà a lavoare a questo nuovo capitolo dopo il rilascio di Java EE 8, presumibilmente in concomitanza con la conferenza JavaOne dei primi di ottobre. Ma non si tratta solo di vaghi annunci, dal momento che molti degli aspetti fondamentali di questa transizione sono già stati delineati. Seguiremo gli sviluppi.