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 [1] 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 sono stati gli ultimissimi sviluppi della questione.
Gaël Blondelle e la panoramica su Eclipse
Nella sua presentazione, il direttore europeo della Eclipse Foundation [2], Gaël Blondelle ha fatto una disamina degli scopi e delle attività della fondazione, spiegando come le varie componenti siano coinvolte nei vari progetti: 360 iniziative, collaborazioni con leader di alcuni settori industriali (Bosch, IBM, RedHat), 4 aree strategiche di intervento:
- Native Java Cloud
- Eclipse IoT
- Automotive (guida autonoma)
- Tools (Eclipse IDE, Capella, etc.)
Eclipse è oggi anzitutto la produttrice di ottimi strumenti software [3] in un’ottica di ambiente business friendly.
E 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 “compliancy” 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.* In effetti, da un punto di vista meramente tecnologico, si tratta di un lavoro imponente ma sicuramente fattibile con tempi neanche lunghissimi.
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 — ci è 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 il Microprofile Eclipse, 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 delle prestazioni veramente notevoli.
L’intervento si è chiuso con un invito a partecipare alla conferenza EclipseCon Europe 2019 [4] che si svolgerà 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 dimostrazone 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 che fosse 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 crititicità: la difficoltà di sviluppo e di test, 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, DevOps. Se la flessibilità e la versatilità dei micro servizi sono innegabili, e anche vero che essi aumentano la complessità del sistema: nulla di cui aver paura ma qualcosa da tenere sicuramente presente come approccio.
Luca Masini. Quarkus: un framework nuovo e potente
A Luca Masini è toccato il compito di dimostrare, sempre in live, le notevoli funzionalità di Quarkus [5]: 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 gli 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 delle 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 [6] 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 qualche tecnologia o un qualche framework all’interno dell’applicazione realizzata con Quarkus. Le extension provvedono inoltre a fare il lavoro pesante che consiste nel fornire 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 e differenti container Java EE, il relatore arriva alla conclusione: per quanto ancora occorra migliorare la “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 il Java lato client
Ad Alberto Mancini, Software Architect a K-Teq [8], spetta l’ultimo intervento della giornata che sarà 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 — 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 al Microprofile e ai microservizi, essi stessi sono “semplicemente” — si fa per dire — un insieme di standard.
Due API fondamentali, come CDI (Content Dependency Injection) e JAX-RS (Java API for RESTful Web Services) possono essere utilizzate sia per lo sviluppo back end che 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 anche esiste uno standard, ossia il Web Assembly [7].
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, in realtà 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 dei pregi e dei 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, JSinterop consentono la trasformazione di Java in JavaScript “potabile” per il browser, ma il fatto è che nessuno di questi funziona sulla base degli stessi meccanismi e, 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 di trovare un modo analogo e standardizzato per fare fare queste “traduzioni”, senza che ogni “trascrittore” faccia a modo suo. Il punto di arrivo è il 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 delle chiare indicazioni della bontà della strada intrapresa.
Quanto all’idea dell’Eclipse Demo Camp, si è trattato di un evento “veloce” che è sicuramente replicabile, sempre all’insegna del focus su pochi e chiari argomenti.