Java e le interfacce grafiche: una storia da conoscere

Cari lettori, questo articolo ha a che fare con JavaFX e il suo futuro, alla luce di recenti annunci di Oracle. Ma, anche per creare un po’ di suspence, permettetemi prima di inquadrare storicamente le cose; anche perché è una storia ben nota a quelli della mia generazione — che ormai… lasciamo perdere — ma potrebbe non essere così nota ai più giovani. Ed è una storia su cui è possibile innestare molte riflessioni e considerazioni, di tipo tecnico e commerciale.

Interfacce grafiche desktop

Quando a metà degli anni Novanta nacque Java, il desktop — ossia la realizzazione di applicazioni stand-alone, con interfaccia grafica autonoma — era centrale nel nuovo runtime. Né poteva essere diversamente, visto che i browser esistevano solo da pochi anni e HTML era primitivo.

Tanto era importante il tema interfacce grafiche desktop, che Sun Microsystem — solo molti anni dopo Java sarà incorporata in Oracle — lanciò pure una linea di workstation “native Java”. Si chiamavano JavaStation ed erano basate su idee per l’epoca innovative, come la capacità di fare boot da rete e scaricare on demand il software necessario, senza installazione.

Ricordo che ne comprai una per la mia azienda, per sperimentazione. In tutta onestà… era una ciofeca, con un processore lentissimo e un Java appena nato, senza neanche la compilazione Just-In-Time. La guardavo ed ero perplesso: possibile che Sun avesse preso un granchio così grosso? Sì, possibile: le JavaStation caddero subito nell’oblio. Forse era solo troppo presto per un prodotto del genere, basato su concetti e tecnologie che avrebbero raggiunto la maturità almeno un decennio dopo.

I sottosistemi grafici di Java

Le soluzioni proprie di Java per garantire delle interfacce utente grafiche di buon livello hanno visto avvicendarsi diversi sottosistemi grafici.

Abstract Window Toolkit

Il primo sottosistema grafico di Java si chiamava AWT (Abstract Window Toolkit) e girava sui tre sistemi operativi principali: era estremamente elementare, tanto che si potevano fare solo cose banali. Ed era massimamente brutto.

All’epoca, la mia azienda vinse un premio per un’applicazione presentata a una fiera, e ricordo i mal di testa per riscrivere praticamente tutto il codice di gestione dei widget necessari con lo scopo di presentarli decentemente.

Swing

Ma Sun investiva con perseveranza, e arrivò Swing: finalmente si iniziava a ragionare. Fu lento per qualche anno, finché vari miglioramenti, specialmente nella Virtual Machine, lo resero utilizzabile. Questo permise di realizzare applicazioni desktop anche molto complesse.

Il problema era che il mondo non stava a guardare: si evolvevano HTML, JavaScript e anche altre tecnologie, oggi tramontate, che godettero di un certo successo, come Flash. Apple e Adobe davano lezioni di stile, si dava importanza sempre più alla forma oltre che alla sostanza, e Swing era indietro: mediocre rendering dei font, difficoltà ad applicare stili, niente animazioni — che andavano sempre più di moda con i primi l’iPhone – e, di nuovo, bisognava riscriversi molte cose, oppure aggiungere librerie su librerie, con problemi di interoperabilità.

Alla fine del primo decennio del nuovo Millennio scrissi un applicativo per la gestione di immagini, che purtroppo rimase dimostrativo — fu presentato a conferenze come la JavaOne [1] — ma che in qualche modo stava dietro alla concorrenza: però si doveva impiegare troppo tempo per le raffinatezze, e sottrarlo allo sviluppo delle funzionalità “paganti”.

JavaFX

E infine, allo scadere del 2008, arrivò JavaFX: praticamente uno Swing riscritto, una nuova architettura con dentro tutto quello che serviva, alla pari con la concorrenza.

L’avvento di JavaFX

Alla pari, però, come specifiche e performance; e anzi, all’inizio, le performance erano decisamente superiori). Ma non come popolarità, perché purtroppo Sun era in clamoroso ritardo. HTML5 e tutta la pletora di popolari framework JavaScript erano diventati molto popolari, come anche Android che, partendo dai cellulari, dove aveva scalzato Java Micro Edition, iniziava a dirigersi verso i tablet, ossia su territori più vicini al desktop.

Molti “campi di battaglia” erano ormai persi, ma ne rimanevano ancora di ben presidiati: per esempio, un gran numero di applicazioni industriali, dal controllo di processo all’automazione, che non sono così visibili alle masse come i social, ma grazie alle quali girano i servizi non virtuali che ci fanno vivere, come treni, grande distribuzione, industria manifatturiera etc.

IoT e JVM

Nel frattempo prendevano piede gli oggetti di Internet of Things, come per esempio le piattaforme Raspberry PI basate su processore ARM. Quasi da subito fu possibile farci girare sopra una JVM aggiornata, con tanto di JavaFX, persino con accelerazioni hardware, pur nei limiti delle performance di un oggetto così piccolo.

Nel frattempo Oracle era subentrato a Sun ed era stato superato il periodo di incertezza sulle tecnologie che sarebbero state mantenute. Insomma, si pensava di aver raggiunto una certa stabilità e il mondo dei micro-device era del tutto nuovo: ci si poteva battere alla pari con le tecnologie concorrenti.

Ma durò poco, perché improvvisamente apparve una nuova versione di JVM per ARM senza JavaFX; però poteva essere installato senza troppe difficoltà come libreria esterna, pur se non più mantenuta da Oracle, ma dalla community. Tutta roba funzionante, con la quale mi sono scritto un media-center attaccato alla televisione di casa. Il segnale, però, era preoccupante. Seguì l’abbandono di WebStart, il meccanismo di deployment dei rich client e… OK, finito l’excursus, credo non ci sia più molta suspence, avrete capito qual è la notizia di cui vi voglio parlare.

L’abbandondo di JavaFX

La notizia è che JavaFX non sarà più nativamente disponibile integrato nella JVM a partire da Java 11; che è dietro l’angolo, visto che arriverà a settembre 2018 [2]. Ora, niente panico: si ripete ciò che è successo per la piattaforma ARM, e cioè JavaFX si potrà scaricare come libreria indipendente; ma quello che preoccupa è il trend. Sembrava, dopo tanti anni e scelte sbagliate, che finalmente ci fosse del vero amore da parte di Oracle per il desktop; ma, come nella canzone Se telefonando, si potrebbe dire che “il nostro amore appena nato… è già finito”.

L’impatto delle architetture web

Cosa sta succedendo? Che tutti i grandi produttori vogliono spingerci a deployare sul cloud, e anche se sarebbe perfettamente possibile farlo con un front-end in JavaFX, evidentemente si punta tutto su HTML5, per unificare le architetture con quelle web. HTML5, nel frattempo, ha molto colmato il gap prestazionale con i rich client, pur rimanendo ancora indietro specialmente dove grandi quantità di dati devono essere manipolati contemporaneamente.

OpenJFX

JavaFX verrà dunque ceduto alle community (OpenJFX) entro la data di rilascio di Java 11: chi vorrà, potrà continuare a sviluppare con questa tecnologia; ma il problema è che Oracle non punta più su JavaFX e questo, decisamente, gli darà una mazzata anche nei contesti dove oggi ancora se la cava alla grande.

Considerazioni tecnologiche… e non solo

Ora, con grande franchezza, vi dirò quello che penso. È evidente che il cloud ha senso per tantissime cose, ma non per tutto. Ci sono applicazioni che non solo non hanno vantaggi a essere distribuite nella nuvola, ma che un utente può non volere che siano distribuite, per poterle usare disconnesso e non fare uscire i dati dal proprio computer: penso a un word processor, o a un programma di grafica o di manipolazione di immagini.

Ne sono tanto convinto che mi sono imbarcato in una migrazione che mi sarei tranquillamente evitato, ossia abbandonare Adobe Lightroom — lo usavo da circa dieci anni — perché Adobe ha chiaramente imboccato la linea del “o cloud, o niente!”, e sostituirlo con un prodotto concorrente che ancora mantiene una versione tradizionale da desktop.

Ora, per chi vuole sviluppare in Java sul desktop con queste idee, si creano dei potenziali problemi, casomai la community non riuscisse a mantenere OpenJFX vivo e popolare: sono passati i tempi del mito di onnipotenza delle community open source…

Il peso dei big player

Quello che vedo è che siamo soggetti a imposizioni da parte dei padroni delle tecnologie che, nonostante a parole dicano di voler soddisfare tutte le nostre esigenze di sviluppo — aahh… “divertitevi di qui”, “enjoyatevi di là”, “date spazio alle vostre idee”…—, poi nei fatti ci impongono i loro piani.

Faccio mio un commento letto su una mailing list: è veramente frustrante essere forzati a “cambiare cavallo” ogni volta, ad abbandonare una tecnologia che è appena maturata, e a dover ricominciare tutto daccapo con una nuova. Onestamente, mi verrebbe voglia di cambiar mestiere e, se sapessi fare altro, forse l’avrei già fatto…

Rich Desktop Application in Java: ancora possibile?

Detto questo, e chiusa la parentesi polemica, rimane la domanda: ma se io dunque voglio sviluppare un’applicazione desktop ricca in Java, e nutro qualche dubbio sul destino a lungo termine di JavaFX, che alternative ho?

HTML5

Be’, il punto di partenza è accettare l’imposizione di HTML5. Per la verità, questa tecnologia ha anche aspetti positivi: che si usi un markup con fogli di stile per il layout è cosa buona e giusta; JavaFX l’aveva copiata, ma usava vocabolari e semantiche diverse, e le versioni più recenti hanno ragionevolmente risolto storici problemi di formattazione.

Per chi non ha problemi a prendere tutto dalle architetture web, la via più semplice è sviluppare tutto come se fosse un’applicazione web che gira in localhost: quindi usare framework come JQuery o Angular che parla con API REST esposte da Java.

WebKit

Quello che ora si sta discutendo in alcune comunità è la seguente idea: estrarre il componente WebKit da JavaFX e renderlo indipendente, in modo che possa essere integrato in una JVM con il minimo carico possibile; in questo modo, l’applicazione desktop praticamente diventa una coppia browser-server integrati, e l’utente finale in definitiva non si accorge di niente.

Sono cose che certi sviluppatori Java, che già apprezzavano HTML5, hanno implementato da molti anni, specialmente nel mondo SWT, dove da tempo, molto prima che in JavaFX, fu reso disponibile un browser integrato serio; se non avete mai preso questa strada perché non vi piaceva, sarebbe il caso di rivalutarla. In attesa che il componente WebKit indipendente sia disponibile, si può iniziare con l’analogo componente di JavaFX; lo switch richiederà di cambiare solo poche righe di codice, per inizializzare e visualizzare il browser integrato.

Framework tipo Vaadin

Se — come al sottoscritto — proprio non vi piace il mondo JavaScript, potete implementare la stessa idea con framework tipo Vaadin, che se la cava benissimo da anni: vi fa creare il modello della GUI in Java, così come si faceva con JavaFX, e provvede autonomamente a pilotare un’interfaccia in HTML5, senza che dobbiate conoscere troppi dettagli sul suo funzionamento, tranne che nel troubleshooting… questo è sempre il dente dolente.

Conclusioni

Questi approcci sono più pesanti del necessario, essendo pensati per applicazioni che sono realmente distribuite su una rete. Nelle community ora si stanno discutendo nuove API che permettano di fare le stesse cose, ma senza usare infrastrutture non necessarie (come socket o websocket) in modo che tutto sia più leggero. Magari di queste tecnologie torneremo a parlare in un prossimo articolo.

Arrivati in fondo, concedetemi un ultimo commento critico: stiamo andando verso un mondo sempre più barocco e, francamente, inutilmente complesso. Su questa strada, le nostre applicazioni avranno due virtual machine integrate: quella Java e quella JavaScript. Vorrei tanto scendere. Ma, intanto, per i miei pet-project casalinghi continuo a usare JavaFX…

Fabrizio Giudici

Fabrizio Giudici ha iniziato a occuparsi di Java durante il suo dottorato di ricerca, concluso nel 1998 presso l‘Università di Genova e focalizzato sulle applicazioni industriali della tecnologia di Sun.
In quegli anni ha iniziato la collaborazione con MokaByte, scrivendo articoli tecnici e partecipando al gruppo di consulenti che iniziavano a tenere i primi seminari su Java in Italia.

Sempre nel 1998, insieme a due amici, ha fondato un‘azienda di consulenza e progettazione, iniziando tra l‘altro la collaborazione con Sun Microsystems Educational Services. A partire dallo stesso periodo, si è occupato, tra l‘altro, di docenza qualificata sull‘area Java, in particolare su Java 2 Enterprise Edition e sui metodi di Analisi e Progettazione a Oggetti.

Dal 2001 Fabrizio ha iniziato a lavorare come libero professionista, sia nel campo della formazione che della progettazione di sistemi informatici (J2EE in particolare, ma con frequenti incursioni in area J2ME), avendo tra i propri clienti un gran numero di piccole e medie aziende italiane. Nel 2003 è iniziata la colalborazione con Sun Microsystems Professional Services per le attività di progettazione, in qualità di Senior Architect e Project Leader.

Dalla fine del 2005 Fabrizio opera di nuovo con una piccola azienda da lui fondata, la Tidalwave, che si occupa di consulenza, formazione, progettazione e project management.

Dall‘inizio della sua carriera Fabrizio ha progettato e realizzato un gran numero di applicazioni software e servizi — inizialmente in C/C++ e successivamente in Java — in varie aree industriali, dal settore finanziario alle telecomunicazioni alle competizioni automobilistiche. Nel 2004 ha diretto per conto di Sun Microsystems e Magneti Marelli il team che ha progettato e realizzato un sistema di telemetria in tempo reale per la Formula Uno, basato su tecnologia Jini.