lunedì 10 novembre 2008

Un tuffo in un'altra quintalata di framework

Ho avuto la felice idea di approfondire il tema delle applicazioni client (sì, proprio quelle che non richiedono un browser per girare) su Java, perchè voglio scrivere una semplice applicazione per uso personale. Nonostante le mie competenze attuali si siano spostate sui sistemi backend, ho da sempre una passione per le interfacce utente e la loro usabilità.
Da studente realizzavo qualche semplice applicazione usando Delphi di Borland, e oggi mi viene un pò da sorridere leggendo di discussioni su come realizzare bind, action, riusabilità delle interfacce, roba che già 10 anni fa Delphi gestiva in maniera egregia.
Ormai uso Java e mi trovo bene, ma la ricerca di un framework per applicazioni client non è tanto diversa che per le applicazioni web. Si trovano decine di alternative, se ne scartano altrettante per manifesto abbandono del creatore, e quelle che rimangono fanno tante cose benino, ma poche benone.
Uno dei miei punti fermi è stata la produttività: posso anche rinunciare all'editor visuale, ma il tool che cerco non si perdere in inizializzazioni inutili, o paginate XML nel tentativo di essere sempre sufficientemente generico. Ormai i pattern tipici delle interfacce utente sono assodati, al limite il lavoro in più dovrebbe essere legato a particolari esigenze.
Intanto ho dovuto affrontare la scelta ideologica tra Swing e SWT: il primo è il framework storico di Sun, da qualche anno rinnovato dall'introduzione di Swing Application Framework, che completa la creazione di interfacce con un modello MVC. Il suo punto di forza è sicuramente Netbeans, con Matisse, un editor visuale che spacca. La sua debolezza (ma per molti è un punto di forza) è il fatto di essere renderizzato in maniera indipendente dal sistema ospite. Io la considero una debolezza perché è più pesante, ma sopratutto perchè risulta alieno nel sistema ospite, anche se JGoodies ha dimostrato che non è necessariamente così.

SWT è invece la libreria su cui è basato Eclipse. E' Java, ma è un wrap sulle API native del sistema ospite per cui, da un certo momento in poi, il rendering è affidato al sistema operativo, e la resa grafica è esattamente quella nativa. Ne beneficiano anche le performance, basta confrontarne lo stack delle chiamate con uno Swing.
C'è da dire che però SWT è molto meno usato di Swing, e questo si riflette nella qualità e quantità di codice. Swing ha, oltre al citato Netbeans/Matisse, anche Spring RCP, un'altra delle perle di Spring Framework, che però mi pare stia languendo. Bene, una scelta in meno :-)
Poi ci sarebbe Groovy SwingBuilder, un'aggeggino molto interessante, oppure Griffon che promette molto bene ma è ancora alla versione 0.0.1(!!).
Sul lato SWT c'è Groovy SWTBuilder ma caliamo un velo pietoso, e JFace. Basta.
JFace non è un vero e proprio framework, ma più che altro una serie di helper class per sveltire i lavori ripetitivi con SWT. Inoltre ha JFace Databinding, per legare in maniera bidirezionale modelli e UI, che sembra fatto molto bene.

Tutti gli indizi portano a scegliere razionalmente Swing. Così ho scelto JFace/SWT :-)
I miei primi esperimenti non mi stanno deludendo, anche se la mancanza di un editor visuale si fa sentire. Però c'è MigLayout, e la sensazione è che forse un tool visuale fa più danni che altro. Basta dare un'occhiata al codice generato da Matisse (non per la qualità, ma per la quantità).
All'inizio si risparmia molto tempo, a lungo andare il codice diventa un papocchio.

Non è finita: per chi ha voglia di emozioni forti ci sono Netbeans Platform e Eclipse RCP. In pratica si prendono gli scheletri base dei due ambienti (concepiti alla base per essere contenitori generici di plugin di vario tipo, per capirci l'intero Java IDE di Eclipse è un grosso insieme di plugin) e si arricchiscono con i vari plugin forniti assieme per creare software di qualsiasi livello (non certo i gestionali per la pizzeria, comunque). Entrambi gli ambienti snocciolano esempi di tutto rispetto.

Dietro i già molti prodotti che ho citato ne ho visto almeno altrettanti, alcuni interessanti (Java Builders, UFace) alcuni decaduti.
Non voglio fare il classico reazionario informatico (ah! il Clipper...ah! il Commodore 64...ah! l'Assembler), ma un pò mi manca il buon vecchio Delphi...

8 commenti:

Francesco Pasqualini ha detto...

Condivido la necessità di un linguagio di scripting, di riferimento per il mondo Java.

Groovy e' sicuramente papabile.

Tuttavia ci sono alcune cose di Groovy che non mi convincono.

Per esempio l'uso estensivo delle closures e un'implementazione non convincente delle stesse.

L'idea però che possa compilarsi in .class e la sintassi che e' un'estensione di quella Java (chi conosce Java non deve fare sforzi) sono dei punti di forza.

Pietro Bonanno ha detto...

Secondo me attualmente Groovy ha un solo vero difetto: non ha nessun supporto da parte dei big. Sun è orientata su JRuby (o era, a giudicare dal supporto Groovy nell'ultimo Netbeans), e su JavaFX che, se non cambia strategia, si avvia a diventare la killer application di Java (nel senso che lo ucciderà).

Groovy ha purtroppo i difetti che citi, e probabilmente anche altri (nei test di prestazione non brilla), ma se avesse + risorse potrebbe realmente diventare il successore di Java.

Anonimo ha detto...

ma avete mai provato il framework qt? nasce per il c++, ma un suo fork sempre ufficiale è qt-jambi, che si propone di esportare tutto il framework qt per java. le qt sono multipiattaforma. sotto mac e windows sono dei wrapper alle librerie grafiche di sistema, e quindi molto performanti. usando le api jambi quindi si ha lo stesso risultato delle swt, più performanti ma meno cross-platform dal punto di vista della filosofia java. però secondo me c'è un vantaggio nell'usare le api jambi: il qt-designer è un ambiente rad niente male, specialmente per quello che siamo abituati a vedere sotto java. inoltre è tutto free anche per uso commerciale, e patrocinato dalla nokia che ci mette un bel po' d soldini nel suo sviluppo...

date un'occhiata:

http://www.ossblog.it/post/2662/release-finale-per-qt-jambi

http://www.qtsoftware.com/developer

Anonimo ha detto...

dimenticavo di dire che il designer, se non lo si vuole usare a parte, è disponibile anche come plugin per eclipse...

Pietro Bonanno ha detto...

effettivamente non avevo ancora visto questo qt-jambi e mi sembra interessante, visto anche l'editor visuale.
L'unica cosa che vorrei approfondire è se e come gestisce il data binding. Ho letto di bind con le tabelle di un DB, ma io preferirei un bind con i miei business object. Approfondirò un pò...

Grazie mille per il suggerimento :)

Anonimo ha detto...

provata la applet di esempio qua

http://dist.trolltech.com/developer/download/webstart/index.html

?

Pietro Bonanno ha detto...

Sì ho provato e non sono male come esempi. Ma c'era anche il data binding?

Anonimo ha detto...

nn saprei nn ho visto con calma...