Java e l'Open Source

Ennesimo balletto di dichiarazioni che Java diventerà Open Source... seguita dalla puntuale smentita: no non è vero. Sarà il quinto o il sesto che io ricordi.

In verità a Sun di rendere Java Open Source non gliene può fregare di meno. Il prodotto ha già un successo commerciale rilevante, e quindi a che pro "regalare la mucca che fa il latte"? Poi Sun ha già abbastanza problemi economici, figuriamoci se pensa di mettersi pure a regalare uno dei pochi elementi di valore che gli sono rimasti, dopo che Linux da un lato e Windows Server dall'altro hanno massacrato il suo mercato dei server Internet "di lusso".

E se a Sun non interessa regalare Java, allora perché se ne parla tanto? Perché Java vive in un ecosistema in cui altri, molti altri, ne traggono giovamento. Per esempio due nomi a caso: IBM e Oracle.

Il problema è che, così com'è Java NON può essere incluso per default in una distribuzione Linux. Quindi Java, a differenza di PHP, Python, Perl, C++ o Ruby, non è un componente STANDARD di Linux, pur essendo DI FATTO uno dei linguaggi più usato per lo sviluppo di applicazioni Linux.

Facciamo un esempio: normalmente io lavoro esclusivamente in un desktop Linux, oramai da 6 anni, e prima di Open Office ne ho patiti di dolori, specie per scrivere il mio primo libro (tutto HTML digitato A MANO in Emacs dopo aver scartato WordPerfect per crash misteriosi). Ma che volete: ho scelto l'Open Source e credevo di dover fare qualche sacrificio per avere la necessaria manualità con il sistema. E in questo ho trascinato tutta la mia azienda: perfino la segretaria usa Linux. Credo pertanto di avere molta esperienza nell'uso del Desktop Linux.

Ebbene, nel nostro ambiente, Linux è estremamente normale usare programmi Java. Per esempio gli editor che usamo quasi tutti sono jEdit, Eclipse o Idea: programmi in Java. Ma la lista non finisce qui. Tralasciando Tomcat e JBoss (visto che faccio sviluppo in Java, non conta molto) ci sono numerosi programmi Java che risultano utili: chessò, il JZip, l'indicizzatore personale di mailbox Zoe, eccetera eccetera.

Inoltre pressochè TUTTI gli strumenti per Java escono "di fabbrica" con gli script ".bat" per funzioana sotto Windows e i ".sh" per funzionare sotto Unix. In breve, Java fa parte in maniera quasi ufficiale del mio ambiente Linux (più di quanto non lo faccia per esempio con Windows) tanto è vero che la prima cosa che di solito scarichiamo dopo una installazione è proprio il JDK.

Ecco, il nocciolo del problema è proprio questo: scaricare dopo l'installazione, invece di avercelo già. Java non è un default per Linux come non lo è per Windows. Nonostante tutti i tentativi della prima ora di renderlo un default per tutti i sistemi operativi e integrarlo nel browser, adesso invece Java resiste a diventare un default per l'unico sistema che sarebbe felicissimo di accoglierlo: Linux.

Il duopolio Linux/Java avrebbe tutte le carte in regola per dominare almeno sui server, e consentirebbe una increbidile quantità di sviluppi che oggi non si vedono. Per esempio la comparsa di applicazioni GNOME o KDE in Java! Non sto parlando di applicazioni con la gui Swing, sto parlando di applicazioni che usano la GUI nativa di Linux.

Tecnicamente è possibilissimo: esistono già i binding diretti a GTK, lo strato intermedio SWT che permette di sviluppare applicazione con GUI nativa per Linux e Windows, il porting wxJava che permette di usare Java con la libreria multipiattaforma nativa wxWindows eccetera.

Solo che nessuno sviluppa applicazioni GUI in Java con GUI semi-nativa proprio perché Java non è Open Source! Ma, direte voi, CHE C'ENTRA? Non si fanno già applicazioni Web in Java, con Java non Open Source? Perché non dovrebbero fanno applicazioni GUI in Java per lo stesso motivo? La risposta è semplice e complessa nello stesso tempo, ma seguite il ragionamento, considerando il problema dell'installazione di una applicazione GUI e di una Web.

Una applicazione Web viene installata in un server su Internet. Generalmente quindi innanzitutto si comprano macchine sofisticate e la banda, e poi l'installazione la va a fare quasi sempre un tecnico esperto, che deve per esempio come minimo creare il database e configurare il web server perché tutto funzioni. Dopodiché, se l'installatore è serio, come minimo fa l'hardening (la mette in sicurezza), scarica gli aggiornamenti e crea un sistema di ripristino.

Quindi l'installazione di una applicazione Java Web è sempre abbastanza complesso, legata alla costruzione del sistema, e l'elemento in più di dover scaricare il J2SDK esplicitamente è un elemento non molto rilevante nell'economia dell'intera procedura. Comunque ci deve andare uno specialista, proprio perché solitamente ci sono numerosi componenti da configurare.

L'installazione di una applicazione GUI invece è una cosa completamente diversa. L'utente di una applicazione GUI è generalmente un utente di basso profilo tecnico, ovvero un utente finale. Generalmente l'utente desktop usa innanzitutto i componenti che trova preinstallati nel sistema; inoltre le varie applicazioni che vengono sviluppate per Gnome e KDE vengono via via integrate nel sistema. E quindi qui il fatto che Java non sia OpenSouce è un ostacolo devastante.

In questi casi, ve lo immaginate un utente finale che vuole usare, per esempio, un programma come Jedit che deve scaricare prima java, poi lanciare l'installer da riga di comando come root ? Eppure questo è l'unico modo di installare, ad oggi, una applicazione Java sotto Linux.

L'installazione di una applicazione di altro genere, già pacchettizzata, invece è ad oggi più semplice per l'utente desktop Linux. Consideriamo il caso di RedHat/Fedora: si può effettuare in maniera grafica, scaricando per esempio un rpm sul desktop e facendo "doppio click". Et voilà, parte l'installer.

Esiste per la verità un sito, chiamato JPackage, che comprende una vasta collezione di rpm per Java. Sfortunatamente, se uno vuole usare per esempio il Java di Sun, gli tocca COSTRUIRSI L'RPM LOCALMENTE partendo dal src.rpm! Ve lo immaginate un utente finale, fare una cosa del genere?

Ancora una volta, la mancanza di integrazione con il Desktop di Java è figlia del fatto che Java non è percepito come un elemento standard del sistema Linux, conseguenza ulteriore del fatto che Java non è Open Source, anche se è distribuito gratuitamente.

Allora, se avere Java Open Source darebbe tutti questi vantaggi, perché Sun si ostina a non renderlo Open Source? La ragione in verità è presto detta, ed è abbastanza diversa dalle dichiarazioni ufficiali (timore di un fork, innanzitutto). La ragione è che ne beneficerebbero tutti TRANNE Sun. Infatti:

Primo motivo: rendere Open Source Java darebbe un ulteriore impulso allo sviluppo di server basati su Linux, che sta massacrando il mercato di Solaris.

Secondo motivo: la distribuzione Linux di Sun è orientata proprio al Desktop (per i server ovviamente Sun propone ancora principalmente Solaris), e si chiama, guarda un po', JAVA Desktop System. Che poi è nei fatti è proprio Linux+Gnome e una JRE integrata...

Come dire: volete Java nei server? Comprate i nostri sistemi. Volete Java nei desktop? Comprate la nostra distribuzione. Ora non dimentichiamo che Sun è una azienda commerciale, che deve fare profitto. E non ci trovo niente di male in questo, né niente di strano nel loro comportamento.

Purtroppo per motivi puramente di interesse, per non fagocitare ulteriormente il proprio mercato, Sun sta rallentando un processo che alla fine sarà necessario. Personalmente penso che questo avverrà solo quando la Sun verrà acquisita...

L'amara conclusione è che come Java ha perso le applet (per colpa di Microsoft, per la verità), sostituite da Flash, Java sta perdendo lo sviluppo GUI multipiattaforma (per colpa sua, stavolta). E secondo me è oramai troppo tardi. L'astro nascente, e oramai inarrestabile, è oramai wxPython. Io ho già fatto il salto.

Nota: Java e Slackware

Un visitatore dei forum di Wup ha fatto notare che il J2SDK è incluso in slackware.

Bene. La cosa è illegale. La licenza di J2SDK dice testualmente:

B.  Redistribution.  This Agreement does not grant you the
right to redistribute Software.  Please refer to the
following URL for information regarding the redistribution
of Software if you are interested in redistribution:
http://sun.com/software/products/appsrvr/appsrvr_oem.html

Questo a meno che Slackware non abbia ottenuto un esplicito consenso alla ridistribuzione. La cosa sarebbe strana visto che IBM ha ampiamento discusso il fatto che la licenza di Java non permette l'inclusione di Java come componente standard delle distribuzioni Linux.