L‘azienda dal cappello rosso sta lavorando all‘implementazione di Java su Linux. La strada non è però quella dinamica e basata su Virtual Machine indicata da SUN, ma un approccio legato maggiormente alla storia di C e C++, basato sulla compilazione in codice nativo. Sarà una strada vincente?

Il supporto di Java su Linux è stato un problema aperto per anni. Grazie alle implementazioni di Blackdown (www.blackdown.org) gli sviluppatori che utilizzavano il sistema operativo del pinguino hanno potuto utilizzare il linguaggio di SUN Microsystems anche sul loro sistema operativo preferito. Anche chi scrive, diversi anni fa, provò una delle prime versioni dell‘implementazione di Blackdown su un sistema Red Hat. Il risultato non fu esaltante: le prestazioni sembravano inferiori alla corrispondente accoppiata Windows+JVM SUN, utilizzando sempre lo stesso PC.
D‘altra parte, probabilmente il numero di ingegneri che SUN impiega per ottimizzare la propria implementazione è decisamente superiore a quelli disposti a lavorare al progetto open source di Blackdown. Inoltre, il supporto alle API era incompleto. Si pensi a cosa vuol dire reimplementare da zero tutta la libreria di base del linguaggio. Ad ogni modo, oggi Blackdown ha completato diversi porting di Java: 1.2.2, 1.3, 14.2. Oggi sta lavorando alla versione 1.5. Il bello è che il codice nativo sarà  disponibile per X86, AMD64, SPARC e PPC. (Per inciso Blackdown ha anche realizzato il porting di Java3D, JAI e JMF, tutte API che contengono codice nativo).
Ma da qualche anno Blackdown ha cominciato ad avere un peso inferiore: SUN ha infatti deciso di supportare pienamente la piattaforma Linux, insieme a Windows e Solaris. Questo nonostante il fatto che solo pochi mesi prima James Goslig, parlando per l‘azienda, si ponesse molti problemi (di Linux non c‘è ne è uno solo, bisogna far attenzione a come lo si implementa, è difficile, e così via).
Oggi Java 5.0 di SUN è disponibile per Windows (x86 e SPARC), Solaris (x86 e SPARC), Linux (x86 e AMD64).
Con il supporto ufficiale dell‘azienda che produce il linguaggio, la situazione per gli sviluppatori Linux è decisamente migliorata. Ma oggi c‘è una possibilità  in più.

GNU e compilazione

Vi ricordate GCC? È il compilatore GNU per C, C++, Objective-C, Fortran e Ada. E da qualche tempo anche per Java. Questo compilatore, chiamato gcj, è il cuore della soluzione di Red Hat.
Scrivere un compilatore per il linguaggio Java che, invece di produrre bytecode, generi del codice oggetto trasformabile da un normale linker in un eseguibile, non è un affare troppo complesso. Un compilatore ad alte prestazioni, che produce però bytecode, lo ha realizzato anche IBM, ed ora è un progetto open source (Jikes, http://jikes.sourceforge.net/). L‘obiettivo dei due progetti non è lo stesso, ma il punto è che la compilazione di un linguaggio non è la parte più complessa, soprattutto se stiamo parlando della piattaforma Java.
La parte più impegnativa è infatti la libreria di base. Il compilatore gcj si basa appunto su GNU Classpath (http://www.gnu.org/software/classpath/), un progetto nato da diversi anni con lo scopo di fornire una completa implementazione libera di tutte le classi della piattaforma Java. La libreria non è completa al 100%, ma contiene gli elementi essenziali per eseguire alcune applicazioni.

L‘importante è il software

Ad oggi gcj è in grado di compilare le proprie librerie in codice nativo e produrre delle librerie condivise in grado di sostituire i JAR. I programmi a riga di comando di supporto permettono di costruire un database globale (a cui si accede in scrittura solo come root) di tutte le librerie condivise. Ad esempio, i seguenti comandi compilano il package mypackage.jar, lo inseriscono nel database e poi eseguono la classe principale:

gcj -shared -findirect-dispatch -fjni -fPIC -Wl,-Bsymbolic mypackage.jar  -o mypackage.jar.sogcj-dbtool -a `gcj-dbtool -p` mypackage.jar mypackage.jar.sojava -cp mypackage.jar com.mypackage.Main

L‘ultimo comando avvia il programma ed utilizza in automatico la libreria condivisa .so creata al primo passaggio.
Bello, ma quali programmi è possibile compilare? A parte nel nostre “innocue” librerie di classi, che non facciano un uso troppo avanzato delle API Java, gcj è in grado di compilare (e sono inclusi in Fedora Core):

• Eclipse completo di plugin per la programmazione C/C++, Python e Bugzilla;

• Tomcat;

• Ant;

• Le parti Java di OpenOffice.

Pochi nomi, ma illustri. E sicuramente non software “facile”. Ci sono dunque buone speranze, ma ancora tanti problemi.

Molte limitazioni

Uno dei problemi principali di questo approccio è che non è possibile effettuare il debug delle applicazioni con gli strumenti a cui siamo abituati. In poche parole, non è possibile utilizzare il debug di Eclipse e l‘unica possibilità  è quella di utilizzare gdb. Chi scrive, francamente, ha preferito rinunciare ad impararlo, anche se non ci sono dubbi che sia un ottimo strumento. È forse solo un po‘ ostico da utilizzare.
Il problema grosso è poi l‘aggiornamento. La libreria di base non è completa (al 95% in confronto al JDK 1.4, all‘85% in confronto all‘1.5). Il compilatore poi è fermo alla versione 1.4: non supporta le nuove caratteristiche della versione 1.5.

Cosa riserva il futuro?

Pare che il lavoro per agguantare quell‘ultimo 15% sia in corso. Ed onestamente, in determinati ambienti (quelli lavorativi), molti sono ancora fermi alla versione 1.3 o alla 1.4. Forse inseguire l‘ultima versione non è poi il requisito più importante; forse è più rilevante che il software sia stabile e privo di bug. Oltre alle migliorie alla libreria ed al compilatore, Red Hat sta lavorando all‘inclusione di ulteriori librerie e software a Fedora Core. In particolare, JOnAS, Azureus, RSSOwl.

Conclusioni

Siamo dunque vicini ad una piccola rivoluzione? In realtà  la strada dalla compilazione nativa è già  stata tentata in passato [2], ma è sostanzialmente miseramente fallita. Dai primi anni di introduzione del linguaggio in molti si sono prodigati per la realizzazione di un compilatore Java, ma con poco successo. Abbiamo visto quali sono gli elementi di complessità  relativi ad una infrastruttura del genere, e per un‘azienda significa investire molto per poter ottenere un prodotto stabile e performante. Oggi molte di queste aziende non offrono più VM con caratteristiche di compilazione. Ne è rimasta solo una e non è chiaro se il motivo è che semplicemente ha sbaragliato il mercato del “Java nativo”, oppure se questo mercato, semplicemente, non c‘è.

Riferimenti bibliografici

[1] Tom Tromey “The State of Java on Linux” RedHat Magazine
http://www.redhat.com/magazine/012oct05/features/java/

[2] Ian Kaplan “Web Pages related to Compiling the Java Programming Language” http://www.bearcave.com/software/java/comp_java.html