Tuesday, November 08, 2005

String <-> InputStream

In questi giorni mi sono concentrato sugli Stream, ma ho ancora qualche difficoltà a gestirli efficientemente. In particolare qualora questi non supportano il reset.

Cercando un po' di informazioni in internet mi sono trovato davanti a del codice che implementa una cosa che non ero mai riuscito a fare in modo efficiente (se non utilizzando classi deprecate).

Conversione da InputStream a String:
  public String parseISToString(java.io.InputStream is){
java.io.DataInputStream din = new java.io.DataInputStream(is);
StringBuffer sb = new StringBuffer();
try{
String line = null;
while((line=din.readLine()) != null){
sb.append(line+"\n");
}
}catch(Exception ex){
ex.getMessage();
}finally{
try{
is.close();
}catch(Exception ex){}
}
return sb.toString();
}


Conversione da String ad InputStream:

  public java.io.InputStream parseStringToIS(String str){
if(str==null) return null;
str = str.trim();
java.io.InputStream in = null;
try{
in = new java.io.ByteArrayInputStream(str.getBytes("UTF-8"));
}catch(Exception ex){}
return in;
}

Commenti sulla qualità di queste due funzioni? Alternative migliori?

Wednesday, November 02, 2005

Primi test su IBM Java 1.5 Beta

Alla fine sono riuscito a ottenere e testare la beta del jdk di IBM.
Il primo test è semplicemente l'avvio di Eclipse, abbastanza grosso per verificare che in effetti tutto funzioni a dovere.

La nota positiva è che in effetti tutto parte e funziona correttamente, quella negativa invece sono i tempi:

  • Avvio di Eclipse (Java5): 55 secondi
  • Avvio di Eclipse (Java1.4): 45 secondi
  • Avvio SWTHelloWorld da Eclipse (Java5): 7 secondi
  • Avvio SWTHelloWorld da Eclipse (Java1.4): 4 secondi
  • Avvio SwingHelloWorld da Eclipse (Java 5): 7 secondi
  • Avvio SwingHelloWorld da Eclipse (Java1.4): 6 secondi
Ho poi effettuato una serie di test (array sort, test numeri primi, divisioni floating point). I tempi sono espressi in millisecondi:

IBM Java5:
  • Array sort: 5551
  • Test numeri primi: 25086
  • Divisioni floating point: 14063

IBM Java1.4
  • Array sort: 4279
  • Test numeri primi: 1049
  • Divisioni floating point: 458
Il codice utilizzato per questi test è lo stesso utilizzato in Introduzione a Gcj nella sezione Conclusioni.

In conclusione un paio di note positive: in questa vesione di Java, IBM ha incluso anche un plugin per mozilla e Java Web Start. Ho effettuato qualche semplice test su entrambi:
  • 2 chat basate su java per il plugin per mozilla
  • jlGui web start installer
Speriamo che per il rilascio finale IBM risolva i problemi di velocità e fornisca a tutti i possessori di architetture PowerPC una Java5 degna di questo nome.

Tuesday, November 01, 2005

IBM Java 1.5 Beta

IBM ha rilasciato (abbastanza silenziosamente a dire il vero) la beta della sua implementazione di Java 5.

Al momento non sono ancora riuscito a provarla, dopo la richiesta di download mi viene detto:
This product is subject to strict US export control laws. Prior to providing access, we must validate whether you are eligible to receive it under an available US export authorization.
Your request is being reviewed.
Upon completion of this review, you will be contacted if we are able to give access. We apologize for any inconvenience.

La cosa veramente positiva di questo annuncio è che finalmente i possessori di PPC hanno a disposizione una implementazione di Java 1.5 con tanto di plugin per mozilla.


Appena riuscirò a provarla, pubblicherò qualche benchmark.

Monday, October 24, 2005

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.

Tuesday, October 18, 2005

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.

Thursday, October 13, 2005

GNU Classpathx

GNU Classpathx è un progetto che mira ad un implementazione libera delle librerie aggiuntive della Sun. Al momento la lista contiene:
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.

Tuesday, October 11, 2005

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.

Sunday, October 09, 2005

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.

Saturday, October 08, 2005

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: