Articolo sullo stato di gcj

Tom Tromey ha scritto per Red Hat Magazine "The state of Java on Linux": un interessante articolo sullo stato di gcj che fa il punto sulle cose funzionanti e su quelle da implementare.

Introduzione a Gcj

Preso da una smania di condividere quello che ho appreso in questi giorni di test con gcj e per fare in modo che anche altri si avvicinino a questa piattaforma ho scritto una breve introduzione (sentra troppo pretese) a gcj/gij.

Potete trovare l'articolo qui.

Se nel leggere trovate errori (...ma anche orrori...) fatemelo sapere e provvederò a correggere.

Prossimamente scriverò anche un breve howto sulla compilazione di applicazione basate sulle SWT con gcj.

GNU Classpathx

GNU Classpathx è un progetto che mira ad un implementazione libera delle librerie aggiuntive della Sun. Al momento la lista contiene:

• JavaBeans™ Activation Framework
• JavaBean infobus
• Java cryptography (diventato GNU Crypto)
• JavaMail
• JAXP (Java API per la manipolazione di XML)
• net extensions
• servlet API

In particolare l'implementazione di JavaMail è compatibile con le specifiche 1.3 (al momento in cui scrivo la versione disponibile sul sito della sun è 1.3.3) e dispone di provider per i protocolli: smtp, imap, pop3, nntp, mbox, maildir.

In the end...

Dopo alcuni giorni di prove finalmente ieri sono riuscito a risolvere il problema del linking a swt. Devo ringraziare Tom Tromey di Red Hat e sviluppatore di gcj per avermi assistito.

Gli "undefined reference" erano causati dal fatto che non compilavo il .jar, ma lo includevo solo nel classpath. In particolare il primo "undefined reference" riferito a Test::Class era causato dal fatto che l'opzione --main di gcj deve contenere l'intero percorso della classe(test.swt.Test).

Il passo successivo è stato quindi di procedere alla compilazione come segue:

nivox@host:~/Test/$gcj --main=test.swt.Test --classpath $SWT_HOME/swt.jar test/swt/Test.java $SWT_HOME/swt.jar -lswt-gtk-3138
org/eclipse/swt/graphics/ImageLoader.java: In class 'org.eclipse.swt.graphics.ImageLoader':
org/eclipse/swt/graphics/ImageLoader.java: In method 'org.eclipse.swt.graphics.ImageLoader.load(java.lang.String)':
org/eclipse/swt/graphics/ImageLoader.java:149: error: verification error at PC=40
org/eclipse/swt/graphics/ImageLoader.java:149: error: label part of different subroutines

Questo altro problema è invece meno banale del primo: è causato dal fatto che alcune applicazioni utilizzano del codice loro per leggere stream di bytecode e caricarli come classi utilizzando ClassLoader.defineClass().
Una spiegazione dettagliata del problema è della sua soluzione si trova sul wiki di gcc: How to BC compile with GCJ.

Per farla breve è necessario utilizzare i flag -findirect-dispath e -fjni (poichè le swt utilizzano la Java Native Interface per accedere a librerie native):

nivox@host:~/Test/$gcj -fjni -findirect-dispatch --main=test.swt.Test --classpath $SWT_HOME/swt.jar test/swt/Test.java $SWT_HOME/swt.jar -lswt-gtk-3138
nivox@host:~/Test/$ls
test a.out

Insomma in conclusione la compilazione di un applicazione basata sulle SWT tramite gcj non è stata così semplice come predicato dai vari articoli che si trovano su internet.

Un passo alla volta...

Dopo un iniziale sconforto per non riuscire a risolvere il problema riguardo alla compilazione nativa con gcj preso da una smania di free-java ho provato a cambiare momentaneamente rotta tentando la strada di gij.

Gij è l'interprete java che va a braccetto con gcj. Infatti il compilatore permette si di compilare in codice macchina (comportamente di default) ma prevede anche la possibilità di compilare in bytecode che verrà poi interpreta da gij appunto.

Con mia grande soddisfazione con gij sono riuscito a far funzionare la mia demo in swt, ma la cosa che mi ha lasciato davvero a bocca aperta è stato il fatto che, senza fare assolutamente nulla, eclipse è partito al primo colpo.

Non tutto funziona ovviamente (Swing/AWT) ma la maggior parte delle cose sembrano funzionare egregiamente anche se ho l'impressione che sia un po' più lento.

Qesta scoperta mi ha sollevato di molto il morale! Adesso non mi resta che riuscire a compilare nativamente. Una volta che sarò riuscito a far funzionare tutto come dovrebbe e mi sarò studiato un po' più a fondo gcj penso che scriverò un qualche tutorial/howto per aiutare quelli che come me si vogliono affacciare ad un uso libero di java.

Java... goes free

In questi giorni ho guardato con maggiore attenzione gcj. Dopo essermi documentato un po' e aver focalizzato i pregi maggiori (risparmio di memoria, amento in velocità, è free-software!) nonchè i difetti più visibili (Non tutte le classi di J2SE sono implementate: in particolare c'è uno scarso supporto per AWT e SWING) mi sono messo a giocarci un po'.

Un primo test di compilazione nativa su un programmino abbastanza stupido (connessioni http ed un minimo di parsing) ha dato esito positivo senza apparenti problemi. Galvanizzato da questo successo ho subito provato con qualcosa di più complesso: un HelloWorld grafico utilizzando le SWT.

Qui le cose non sono andate altrettanto bene, infatti mi sono bloccato alla fase di compilazione:

nivox@host:~/Test/$gcj --classpath $SWT_HOME/swt.jar -c test/swt/Test.java

nivox@host:~/Test/$ ls
test Test.o

nivox@host:~/Test/$gcj --main=Test -lswt-gtk-3138
ccDiLjH7.i:(.text+0x2e): undefined reference to `Test::class$'
ccDiLjH7.i:(.text+0x32): undefined reference to `Test::class$'
Test.o: In function `test::swt::Test::main(JArray*)':
Test.java:(.text+0x2e): undefined reference to `org::eclipse::swt::widgets::Display::class$'
Test.java:(.text+0x32): undefined reference to `org::eclipse::swt::widgets::Display::class$'
Test.java:(.text+0x44): undefined reference to `org::eclipse::swt::widgets::Display::Display()'
Test.java:(.text+0x52): undefined reference to `org::eclipse::swt::widgets::Shell::class$'
Test.java:(.text+0x56): undefined reference to `org::eclipse::swt::widgets::Shell::class$'
Test.java:(.text+0x70): undefined reference to `org::eclipse::swt::widgets::Shell::Shell(org::eclipse::swt::widgets::Display*)'
...

Tutto ciò è molto frustrante... stò sbagliando qualcosa, ma non capisco cosa... e purtroppo anche google non mi è stato d'aiuto. Nei prossimi giorni vedrò di andare a fondo in questa faccienda.

Sono rimasto impressionato dalle potenzialità di GNU gcj e di altri progetti come GNU Classpath e Kaffe. E molto fiducioso per Apache Harmony: un progetto non ancora ufficiale della Apache Foundation (E' stato proposto a Maggio) che mira ad una implementazione libera di J2SE concentrando gli sforzi dei tre porgetti di cui sopra. Qui il blog non ufficiale del progetto: l'ultimo post è di Giugno... ma spero di avere presto buone nuove da parte di questo promettente progetto.

JavaMail API

Platform/Protocol-independent framework per integrare all'interno di un'applicazione la gestione della posta elettronica. E' molto semplice aggiungere protocolli alla dotazione di default (imap, imaps, pop3, pop3s, smtp), si tratta fondamentalmente di estendere 3 classi: Store/Transport, Folder, Message.

Il pacchetto fa parte di Java2EnterpriseEdition ma è scaricabile come pacchetto stand-alone da qui: http://java.sun.com/javamail.

Mokabyte.it ha realizzato una serie di articoli illustrativi sulle funzioni delle API:

• JavaMail Parte I: gestire la posta elettronica in Java.
• JavaMail Parte II: eventi e messaggi multipart.
• JavaMail Parte III: eventi e messaggi multipart.
  
• JavaMail ParteIV: approfondimento sulla gestione dei messagi.