Un pomeriggio per conoscere e riflettere
Lo scorso 11 giugno abbiamo partecipato a un evento svoltosi a Firenze nel pomeriggio, organizzato da Francesca Tosi e Alberto Mancini, e denominato Eclipse Demo Camp. Si è trattato di una serie di riflessioni dedicate a tecnologie e progetti della Eclipse Foundation.
Inutile dire che c’era una certa curiosità anche per capire in che direzione la Eclipse Foundation si stia muovendo dopo i noti problemi legati alla denominazione dei pacchetti javax.* all’interno delle nuove versioni di ciò che un tempo fu Java EE e adesso è diventato Jakarta EE.
Oracle vs. Eclipse
La controversia tra Oracle ed Eclipse è stata trattata diffusamente nel precedente numero di MokaByte e a quell’articolo rimandiamo per approfondimenti.
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” — anche qui, 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.
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.
C’era quindi curiosità per ascoltare, dalla voce di Gaël Blondelle, managing director di Eclipse per l’Europa, quali siano stati gli ultimissimi sviluppi della questione.
Gaël Blondelle e la panoramica su Eclipse
Nella sua presentazione, il direttore europeo della Eclipse Foundation ha fatto una disamina degli scopi e delle attività della fondazione, spiegando come le varie componenti siano coinvolte nei diversi progetti: 360 iniziative, collaborazioni con leader di alcuni settori industriali come Bosch, IBM e Red Hat, e quattro aree strategiche di intervento:
- Native Java Cloud
- Eclipse IoT
- Automotive, con particolare attenzione alla guida autonoma
- Tools, tra cui Eclipse IDE e Capella
Eclipse è oggi anzitutto la produttrice di ottimi strumenti software, in un’ottica di ambiente business friendly.
Si è quindi arrivati a parlare del progetto Jakarta EE, a proposito del quale è stato messo anzitutto in luce come ci sia una differenza tra il vecchio Java Community Process (JCP) e il nuovo processo di raccolta delle specifiche denominato Eclipse Foundation Specification Process (EFSP). In cosa consiste il cambiamento? Si è passati da un approccio “specification first” a uno “code first” in cui, a guidare lo sviluppo, non sono più delle lunghissime e burocratiche procedure di definizione e accettazione delle specifiche, ma un processo di validazione di software funzionante. È stato reso più facile e diretto anche il processo che certifica la compatibilità da parte dei vari produttori.
Per quanto riguarda il problema del passaggio da javax. a jakarta., la comunità sembra orientata alla soluzione drastica: un Big Bang che dia una sterzata brusca una volta per tutte con il cambiamento verso jakarta.*. Da un punto di vista meramente tecnologico, si tratta di un lavoro imponente ma sicuramente fattibile in tempi non troppo lunghi.
Il problema, casomai, sarà quello di vedere che cosa accadrà con le applicazioni vecchie che dovranno essere rifattorizzate e reimpacchettate per funzionare con il nuovo namespace. Su questo secondo aspetto, ed è un commento di chi scrive, è parso che l’approccio di Gaël sia stato fin troppo ottimista.
Molto interessante è stata anche la panoramica sul futuro, ossia sui vari progetti che riguarderanno Jakarta EE 9: cloud native, microservizi con Eclipse MicroProfile e le notevoli promesse riposte nel progetto Vert.x.
Passando poi a parlare di OpenJ9, è stato mostrato come esso funzioni piuttosto bene a partire dai sistemi embedded fino a dimensioni notevolmente più grandi, con un’ottima capacità di scalare e prestazioni veramente notevoli.
L’intervento si è chiuso con un invito a partecipare alla conferenza EclipseCon Europe 2019, che si sarebbe svolta a fine ottobre nell’area di Stoccarda, in Germania, e a inviare proposte di interventi e workshop.
Luca Cesari e i microservizi
Luca Cesari di RCPvision ha effettuato una dimostrazione live di come sia possibile scrivere un’applicazione monolitica trasformandola in un’applicazione a microservizi. Ovviamente, per le esigenze di velocità e di didattica, l’applicazione scelta come esempio non poteva che essere molto semplice. Si è quindi ipotizzato di avere un’applicazione in grado di catalogare e valutare i film e le serie TV viste da determinati utenti.
Le applicazioni monolitiche hanno degli indubbi vantaggi: progettazione meno articolata e deployment più semplice. Ma ci sono anche delle criticità: la difficoltà di sviluppo e di test, e l’impossibilità di scalare solo un aspetto dell’applicazione.
Sono state quindi passate in rassegna tutte le buone cose legate allo stile architetturale a microservizi, tenendo però presente il fatto che questo implica un netto cambiamento di mentalità in chi sviluppa e in chi mantiene il sistema: si va obbligatoriamente verso la Continuous Integration, il Continuous Development e il DevOps. Se la flessibilità e la versatilità dei microservizi sono innegabili, è anche vero che essi aumentano la complessità del sistema: nulla di cui aver paura, ma qualcosa da tenere sicuramente presente come approccio.
L’intervento è risultato convincente, anche con qualche momento di sana ilarità. Il fatto di aver scelto l’approccio live ha convinto sicuramente molti dei presenti della bontà della soluzione MicroProfile.
Luca Masini e Quarkus
A Luca Masini è toccato il compito di dimostrare, sempre dal vivo, le notevoli funzionalità di Quarkus: Supersonic, Subatomic, Java, Cloud Native, Microservices, Serverless.
Al di là dell’interessante sessione tutta basata su istruzioni da riga di comando a terminale aperto, concedeteci una nota divertente: il relatore utilizzava come ambiente di sviluppo IntelliJ IDEA, ma ha voluto rassicurare tutta la platea che stava usando Eclipse IDE con una speciale skin. Il primo a ridere di gusto, cogliendo la battuta, è stato proprio il direttore europeo di Eclipse.
Venendo agli aspetti più tecnici, ciò che ha colpito maggiormente sono state le prestazioni davvero notevoli di Quarkus, grazie al quale il codice Java riesce a raggiungere prestazioni sovrapponibili a quelle del linguaggio Go.
Se a questo aggiungiamo anche che tutte le funzionalità possono essere utilizzate a caldo senza la necessità di dover continuamente riavviare il container, ci rendiamo conto di avere fra le mani un prodotto di sicuro livello.
Quarkus utilizza la Virtual Machine GraalVM, che ha prestazioni elevatissime, ma non è solo questa la ragione delle ottime performance. Con Quarkus, infatti, si riducono le dipendenze esterne, passando dal classico modello a dipendenze a quello a “estensioni”: le extension in Quarkus si occupano di configurare, avviare e integrare una tecnologia o un framework all’interno dell’applicazione realizzata con Quarkus. Le extension provvedono inoltre a fare il lavoro pesante, fornendo alla GraalVM tutte le informazioni affinché la nostra applicazione compili nativamente.
C’è un apposito tool che consente di realizzare extension per le varie tecnologie e i diversi framework. Con una rassegna dei risultati ottenuti con i vari container Java EE, il relatore arriva alla conclusione: per quanto ancora occorra migliorare l’integrazione con alcune piattaforme, a conti fatti conviene sicuramente passare alle extension, che riducono le dipendenze e garantiscono notevoli prestazioni.
Quarkus è una tecnologia da tenere d’occhio e che potrebbe riservare grandi e positive sorprese agli sviluppatori a mano a mano che procederà nella sua evoluzione.
Alberto Mancini e Java lato client
Ad Alberto Mancini, Software Architect a K-Teq, spetta l’ultimo intervento della giornata, incentrato su una riflessione quasi “filosofica” relativa al rapporto tra i linguaggi che si usano lato back end e il codice che si utilizza front end nel nostro browser.
Il ragionamento prende le mosse da questa semplice constatazione: in tutto il mondo Java EE, e dovremo cominciare a parlare ormai sempre più di Jakarta EE, quel che vediamo sono degli standard. Java EE è un insieme di standard e, se pensiamo a MicroProfile e ai microservizi, essi stessi sono “semplicemente”, si fa per dire, un insieme di standard.
Due API fondamentali, come CDI (Contexts and Dependency Injection) e JAX-RS (Java API for RESTful Web Services), possono essere utilizzate sia per lo sviluppo back end sia per quello front end: la parte client-side si può scrivere in Java proprio come la parte server-side. Alla fine, ciò che conta è ottenere da questo codice Java un codice eseguibile nelle pagine web, per il quale esiste anche uno standard, ossia il WebAssembly.
E quindi, potendo passare da Java a JavaScript a WebAssembly, tutto sembrerebbe risolto.
In realtà proprio qui arrivano i problemi. Se è vero che esiste uno standard finale, il modo in cui si arriva al risultato finale non è affatto standard. Ci sono ottimi strumenti e librerie di “traduzione”, ma ognuno di questi strumenti ha pregi e difetti e, in ogni caso, lavora in modo diverso, non sulla base di uno standard più ampio.
Errai JAX-RS, una libreria per GWT, JSweet, JWebAssembly e JSInterop consentono la trasformazione di Java in JavaScript utilizzabile dal browser, ma nessuno di questi funziona sulla base degli stessi meccanismi. In tal senso, ad esempio, certi oggetti sono più facili da trattare e tradurre rispetto ad altri.
L’obiettivo della ricerca in questo campo deve essere trovare un modo analogo e standardizzato per fare queste “traduzioni”, senza che ogni trascrittore faccia a modo suo. Il punto di arrivo è WebAssembly, ma occorre standardizzare come si interagisce con i tipi primitivi del browser. Un lavoro di questo tipo è stato fatto per TypeScript e Closure Compiler e andrà fatto anche per Java.
Conclusioni
La formula rapida e le tematiche ben concentrate hanno avuto il merito di lasciare nei numerosi presenti la consapevolezza di aver appreso qualcosa. Certo, resta aperta una serie di interrogativi che riguardano gli sviluppi futuri di Jakarta EE, ma i prossimi mesi sapranno darci chiare indicazioni sulla bontà della strada intrapresa.
Quanto all’idea dell’Eclipse Demo Camp, si è trattato di un evento “veloce” sicuramente replicabile, sempre all’insegna del focus su pochi e chiari argomenti.