|
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.so
gcj-dbtool -a `gcj-dbtool -p` mypackage.jar mypackage.jar.so
java -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'è.
Bibliografia
[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
|
