Chi mi conosce sa bene il mio rapporto di amore-odio con Java. Amore perché Java è un linguaggio performante, di alto livello e soprattutto portabile. L’ho usato spesso, lo uso tutt’ora e ci ho fatto addirittura del game development. Odio perché, proprio perché ci ho combattuto tanto, ne conosco tutti i difetti, i limiti e le idiosincrasie. Java è sintatticamente prolisso e ha qualche problema di “vecchiaia” che andrebbe risolto (ed il confronto con C# è impietoso).

Giusto per fare un esempio in Java è abitudine leggere (o scrivere) codice raccapricciante quale

che in C# si risolve con un semplice

Qualcuno considererà questa caratteristica (tecnicamente si parla di Accessor e Mutators) un puro vezzo sintattico, ma quando si lavora con decine e decine di classi vi posso assicurare che questo facilita di un fattore dieci la produttività e la manutenibilità del codice. Problemi come questo ed altri più “concreti” sono ciò che mi hanno spinto a passare al lato oscuro della forza ogni qualvolta mi è possibile.

In attesa che Java venga riformato (sperando nella rivoluzionaria (?) versione 8 e 9 del linguaggio) la comunità si è messa in moto in modo autonomo. Uno dei progetti a mio avviso più interessanti è senza dubbio Ceylon, di Red-Hat.

Ceylon è un linguaggio JVM-based, ovvero che viene compilato generando byte-code compatibile con la Java Virtual Machine. Questo garantisce due vantaggi: il linguaggio sfrutta la portabilità e le ottime performance della JVM ed è potenzialmente compatibile con le librerie Java esistenti.

Ceylon è un linguaggio molto interessante perché non solo alleggerisce Java da tutti gli inutili orpelli sintattici di cui è infestato ma aggiunge anche una sorta di dinamismo opzionale nella gestione delle variabili (tramite il tipo jolly value). Ma facciamo qualche esempio.

Come non partire dal mitico “Hello, World!”? In realtà non è un “Hello, World!” semplice perché ci mostra due nuove caratteristiche del linguaggio. La prima è il modo con cui vengono documentati metodi e classi: niente commenti, ma una sintassi specifica che può essere letta dal generatore di documentazione integrato di Ceylon. La seconda è il tipo variabile value che può essere usato per simulare una certa dinamicità del linguaggio. Da notare però che nessuno ci obbliga ad usarlo: se siamo sicuri che la variabile message sia una stringa possiamo direttamente dichiararla come tale tramite String message.

Un’altra funzionalità molto utile è l’operatore di null check. Vediamolo in azione:

In questo esempio troviamo i due operatori in azione. Il primo è l’operatore “?”. Considerando il codice precedente, tale operatore restituisce name.uppercased se e solo se quest’ultimo è diverso da null, altrimenti restituisce il valore che lo segue (in questo caso la stringa “WORLD”). L’altro operatore nell’esempio è “?.”. Quest’ultimo fa in modo che si acceda alla funzione/attributo uppercased se e solo se name è diverso da null. Questi due operatori ci risparmiano quindi tutta una serie di noiosi “if” annidati!

Le caratteristiche di Ceylon sono numerosissime e per maggiori informazioni vi rimando alla loro pagina ufficiale. Ceylon è ancora in fase di sviluppo ma è già possibile scaricare delle versioni preliminari!

Come se non bastasse è in progetto lo sviluppo di un backend che compili Ceylon in JavaScript rendendone possibile l’uso anche per lo sviluppo di applicazioni web.

Insomma, Ceylon è un progetto che vi consiglio caldamente di tenere d’occhio!

La notizie e le informazioni in internet vanno sempre verificate. Molte cose infatti si tramandano di bocca in bocca (o di tastiera in tastiera) fino a confondersi. Le senti ripetere talmente tante volte che alla fine te ne convinci e le accetti acriticamente.

Arriva poi il giorno che ti informi e scopri che le cose non sono proprio così o che, in fondo, sono molto più complesse. Fra questo ricade anche l’asserzione Android è scritto in Java.

Android non è scritto in Java?

Si e no. Intendiamoci, il titolo dell’articolo è volutamente provocatorio e non dobbiamo pensare che Java non c’entri nulla con Android, piuttosto dobbiamo capire dove si ferma Java e dove comincia il resto.

Per prima cosa Android è scritto in C. Il kernel è Linux e tutti i ricami sovrastanti sono scritti ovviamente in C. Sembra banale ma ho sentito dire che il kernel di Android è scritto in Java… quindi meglio essere puntuali.

Seconda cosa. La gran parte dello strato applicativo poggia su Dalvik.

Ovvero la nota Java Virtual Machine. Giusto?

Si e no. Anche qui dobbiamo essere precisi. Quando uno dice “le applicazioni di Android sono in Java” apre un mondo di se e di ma.

Quando pensiamo a un applicazione in Java pensiamo alle applicazioni Java che girano sul mattone delle Java VM standard. Quando facciamo questa affermazione diamo l’idea che anche le applicazioni di Android siano dello stesso tipo e girino su una VM equivalente. Ma questo è completamente falso!

Dalvik non esegue codice Java?

NO! Questo ci tengo a specificarlo perché è la chiave di tutto il discorso. Dalvik non esegue e compila il codice Java! Dalvik compila il Java bytecode ed esegue il Dalvik Bytecode! La differenza è abissale, enorme, è come la differenza fra il codice Morse e il Dolce Stil Novo. Basti pensare che il Java Bytecode (quello dei file .class) esegue istruzioni codificate in 8-bit invece dei 16-bit delle istruzioni di Dalvik (nei file eseguibili .dex).

In ogni caso se Dalvik compila il Java ByteCode non è la stessa cosa?

Assolutamente No. Sarebbe come dire che io so il giapponese perché so tradurre in italiano le scritte giapponesi che qualcuno mi traduce in inglese.

Inoltre questa caratteristica permette (in teoria) di utilizzare linguaggi alternativi a Java in modo piuttosto semplice. Ad esempio possiamo scrivere applicazioni per Dalvik anche in Python a patto di compilare il codice Python in Java ByteCode (ad esempio usando Jython ). Il codice compilato in questo modo può quindi passare per Dalvik che lo convertirà in file .dex.

Usare Python (o altri linguaggi) per programmare in Android è tuttavia attualmente impossibile. Tutte le librerie di sistema Android (le API che scarichiamo quando configuriamo l’ambiente) sono scritte in Java, tuttavia se qualcuno avesse pazienza e voglia di convertire tali librerie in Python (compatibile con Jython) si potrebbe usare questo linguaggio in modo quasi trasparente.

Quindi Dalvik non è una Java VM?

Dalvik è una VM che interpreta il Java ByteCode. La differenza è molto sottile concettualmente ma importante per non fare confusione.

Inoltre ci sono numerosissime altre differenze con la Java VM di cui molte incentrate all’ottimizzazione del sistema su dispositivi mobili e con risorse limitate che potete scoprire cercando Dalvik su uno qualsiasi dei motori di ricerca.

A me, sviluppatore, cosa cambia?

Nulla. Tu sviluppatore scriverai applicazioni per Android in Java. Di chi compila ed esegue il tuo codice non ti interessa. Quindi per te le applicazioni Android sono in Java.

Ora però sai che la situazione è più complessa di così e la consapevolezza di come funzionano le cose in realtà le cose è l’arma più potente di ogni sviluppatore.

Tutti conoscono Firefox. Tutti conoscono l’infinito numerabile dei suoi plugin. Pochi sanno però come cominciare a sviluppare tali plugin. E a questo serve questo piccolo tutorial. Non vedremo ora quali sono i passi per sviluppare un plugin ma vi mostrerò i passi e gli strumenti preliminari che servono a semplificare lo sviluppo. Ma cominciamo subito senza perderci in chiacchiere.

CONFIGURARE L’AMBIENTE

La prima cosa da fare, per evitare di incasinare le configurazioni originali, è quello di creare un nostro profilo di sviluppo. Possiamo lanciarlo semplicemente con:

/usr/bin/firefox -no-remote -P dev

In questo modo avvieremeno un’altro profilo di firefox chiamato dev.

Adesso dobbiamo impostare alcune opzioni che ci permetteranno di ottenere un maggior numero di informazioni sulle attività di firefox e un maggior controllo su di esse. Apriamo il classico about:config e all’interno impostiamo le seguenti variabili:

• javascript.options.showInConsole = true. Abilita il Log di molti errori.
• nglayout.debug.disable_xul_cache = true. Disabilita la cache XUL in modo tale che modifiche alla finestra e ai messaggi di dialogo non necessitino di un riavvio dell’applicazione.
• browser.dom.window.dump.enabled = true. Abilita l’uso di dump() per stampare messaggi sulla standard consol.
• javascript.options.strict = true. Abilita i warning JavaScript nella Error Console.
• extensions.logging.enabled = true. Questo invia una valanga di informazioni sulle estensioni alla Error Console.

E’ anche molto utile questa estensione. Essa offre una comoda interfaccia grafica per accedere ad alcune impostazioni nascoste di Firefox.

STRUMENTI UTILI

• DOM Inspector: Questo strumento ci permette di navigare e modificare strutture XML-Based come lo XUL delle interfaccie di Firefox.
• Venkman: Un semplice debugger per JavaScript.
• Console: Una potente console JavaScript.
• ChromeList: Tool per navigare nei file in chrome://
• ViewAbout: Permette l’accesso ai vari about: tramite una comoda interfaccia grafica.
• CrashMe!: Uno strumento per analizzare i report di debug dei chrash di firefox.

Aaaaaargh!

PROTOCOLLO DI TRASFERIMENTO IN PRATICA – INVIO

Per questo punto abbiamo visto che è necessario serializzare il documento XML in uno stream secondario che useremo per calcolare la dimensione dei dati inviati e che poi riverseremo direttamente nello stream di output del socket.

Per fare questo estendiamo ByteArrayOutputStream, in questo modo sfrutteremo tutti i metodi di questa classe, fra i quali, quello che ci fornisce la dimensione dei dati contenuti. Tale classe dovrà avere inoltre:

1. Un attributo che memorizza lo stream di output reale. Nel nostro caso memorizzerà lo stream di output del socket.
2. Un metodo send che fa quello che vogliamo. Prende i dati memorizzati e li invia nel canale di output preceduti da un intero che indica la quantità di dati inviati.

Per il canale di output ho scelto DataOutputStream poiché fornisce in modo nativo molte funzioni a cui siamo interessati, fra cui l’invio diretto di un Int.

La classe risultante è:

public class XMLOutputStream extends  ByteArrayOutputStream {

 private DataOutputStream outchannel;

 public XMLOutputStream(OutputStream outchannel) {
     super();
     this.outchannel = new DataOutputStream(outchannel);
 }

 public void send() throws IOException {
     byte[] data = toByteArray();
     outchannel.writeInt(data.length);
     outchannel.write(data);
     reset();
 }
}

Ora però vogliamo che tale classe sia gestibile in modo più semplice. Vogliamo infatti un metodo in cui noi inseriamo un documento XML e lo stream di uscita del socket e lui faccia tutto il lavoro di serializzazione e invio.

public class XMLSender {

 public static void send(Document tosend, OutputStream channel) throws TransformerConfigurationException, IOException {
     XMLOutputStream out = new XMLOutputStream(channel);

     StreamResult sr = new StreamResult(out);
     DOMSource ds = new DOMSource(tosend);
     Transformer tf = TransformerFactory.newInstance().newTransformer();

     try {
         tf.transform(ds, sr);
     } catch (TransformerException ex) {
         Logger.getLogger(XMLSender.class.getName()).log(Level.SEVERE, null, ex);
     }

     out.send();
 }
}

Questa classe fa proprio ciò che vogliamo. Contiene un unico metodo statico che prende come parametri documento XML e canale di uscita e si occupa di serializzare e inviare il tutto in modo corretto sfruttando il nostro XMLOutputStream.

PROTOCOLLO DI TRASFERIMENTO IN PRATICA – INVIO

Per la ricezione sfruttiamo un meccanismo simile anche se, per mantenere una certa linearità di funzionamento sono stato costretto ad usare in modo piuttosto sporco la classe ByteArrayInputStream ma al momento era l’unica soluzione coerente che mi veniva in mente. Funziona a patto di tollerare il mio intervento brutale sugli attributi della classe.

public class XMLInputStream extends ByteArrayInputStream {

private DataInputStream inchannel;

public class XMLInputStream extends ByteArrayInputStream {

 private DataInputStream inchannel;

 public XMLInputStream(InputStream inchannel) {
     super(new byte[2]); //MOLTO BRUTTO.
     this.inchannel = new DataInputStream(inchannel);
 }

 public void recive() throws IOException {
     int i = inchannel.readInt(); //Legge l'int con il numero di byte.
     byte[] data = new byte[i];
     inchannel.read(data, 0, i); //Legge esattamente quel numero di byte.
     this.buf = data; //BRUTTO ANCHE QUESTO.
     this.count = i;
     this.mark = 0;
     this.pos = 0;
 }

}

Come potete vedere rispetta esattamente il nostro protocollo. Anche in questo caso vogliamo una classe involucro che ci permetta, dato lo stream di input del socket di restituire il documento corrispondente.

public class XMLReceiver {

 public static Document receive(InputStream channel) throws ParserConfigurationException, TransformerConfigurationException, IOException, SAXException {
     //Inizializza il DOM per la ricezione del pacchetto.
     DocumentBuilderFactory docBuilderFact = DocumentBuilderFactory.newInstance();
     DocumentBuilder docBuilder = docBuilderFact.newDocumentBuilder();
     Document request = null;

     //Inizializza il canale.
     XMLInputStream xmlin = new XMLInputStream(channel);

     xmlin.recive();

     request = docBuilder.parse(xmlin);

     return request;
 }
}

Anche in questo caso eccovi accontentati. Lascio qui di seguito un archivio contenente tutte le classi di cui abbiamo parlato.

DOWNLOAD XMLTRANSFER

LICENZA:

Tutte le classi sono estratte dal progetto Enea. Come tali ereditano la sua licenza GPLv3. Nonostante ciò non è che per 10 righe di codice mi straccerò i vestiti se la licenza non è applicata. E’ solo premura citare me e questo. A questo ci terrei.

Grazie ad andbin del forum di HTML.it per il supporto.

Perché!? Perché!?

Ho perso settimane alla ricerca di un modo elegante e pulito di trasferire informazioni fra server e client tramite un protocollo basato su XML. Possibile che nessuno abbia fatto una classe nelle librerie standard in grado di trasferire facilmente una manciata di tag XML? Non lo so. Fatto sta che il web non conteneva nessuna risposta alla mia domanda, così, domandando in giro sono arrivato a sviluppare 4 classi in grado di trasferire con un solo comando pacchetti XML attraverso un Socket.

SERIALIZZAZIONE E PARSING

Quando si lavora con un documento che contiene dati bisogna, innanzitutto, essere in grado di leggerlo. L’azione che compie un programma quando legge un documento/file e ne interpreta il contenuto si chiama parsing. Il parsing di un file consiste, quindi, nell’estrarre da una sequenza di caratteri le informazioni da noi desiderate ed organizzarle in una struttura logica all’interno della memoria.

La serializzazione, invece, è esattamente il contrario del parsing. Serializzare un oggetto consiste nel trasformare tale struttura dati in una sequenza lineare di caratteri.

Questi due passaggi sono essenziali per lavorare con i file in modo avanzato: il computer gestisce nativamente solo sequenza di byte (e quindi caratteri) e quindi tutto ciò che non risiede in memoria deve poter essere memorizzato in questo formato.

LIMITI DEL TRASFERIMENTO XML NATIVO

Le classi che gestiscono XML sia secondo metodologia SAX che DOM permettono di serializzare e di parsare un documento XML direttamente in/da uno Stream dati. Possiamo cioè serializzare un documento XML direttamente in un OutputStream e analogamente possiamo parsare un file XML attingendo direttamente da un InputStream. Questa è l’interfaccia che ci offrono gli strumenti base.

Il problema è che questo meccanismo non funziona attraverso un Socket. Supponiamo che un client voglia inviare una richiesta ad un server. Il client crea il suo documento XML con la richiesta e la serializza nell’OutputStream del socket. A questo punto il server riceve questi dati effettuando direttamente il parsing dall’InputStream del socket.

Qui avviente l’intoppo. XML non prevede un terminatore esplicito. Il server rimane quindi in attesa perenne che il flusso dati provenienti dal client si interrompa (inviando un EOF, Endo-Of-File).

Questo però non può avvenire in nessun caso. Infatti:

1. Se il client forza l’invio di un EOF (inviando un byte contenente 0×00) il parser del server lancia eccezione. Tale terminatore non può essere parsato!
2. Se il client chiude lo stream, automaticamente il socket viene disconnesso e la connessione viene interrotta. Il server quindi non può più rispondere, a meno di non instaurare una nuova connessione.

La soluzione non può essere risolta in questo modo. Bisogna escogitare soluzioni alternative.

TROVIAMO UNA SOLUZIONE

Il problema ci appare subito chiaro. Dobbiamo indicare al server che il documento è finito così che lui possa interrompere l’attesa e proseguire con l’esecuzione. Per fare ciò abbiamo due modi:

1. Inviare alla fine del documento qualcosa che segnali al server che non verrà inviato più nulla.
2. Istruire il server a leggere solo un TOT di byte corrispondendi alla lunghezza del messaggio.

Il primo metodo lo abbiamo già scartato: qualunque cosa inviamo alla fine del documento verrà parsata generando l’eccezione del server. Ci rimane la seconda soluzione.

Questa presuppone la conoscenza a priori della dimensione del documento. Ma di questo non siamo affatto sicuri. Come potremmo esserlo? Anche per questa cosa abbiamo fondamentalmente due soluzioni:

1. Dare una dimensione fissata ad ogni pacchetto riempendo lo spazio non usato di dati casuali (inseriti in un campo CDATA).
2. Inviare prima del documento il numero di byte che verranno inviati.

La prima soluzione è ovviamente uno spreco enorme di memoria. E’ utile nel caso la dimensione di ogni pacchetto sia più o meno sempre la stessa poiché questa soluzione ha il vantaggio di essere trasparente al client.

La seconda soluzione invece è molto più scalabile ed “elegante”. Il problema è: come facciamo a sapere quanti byte verranno inviati? La soluzione è ancora più semplice: invece di serializzare il documento direttamente sullo stream del socket lo serializziamo su un nostro stream privato, valutiamo la sua dimensione e dopodiché la inviamo seguita dal contenuto del nostro stream temporaneo.

Nel lato di ricezione invece leggiamo in questo modo: prima leggiamo il numero di byte (contenuto nei primi 4byte del messaggio) e poi trasferiamo questo esatto numero di byte provenienti dal socket in un nostro stream che poi faremo parsare.

La soluzione non fa una grinza. Ci manca solo di integrarla al meglio per rendere il più semplice possibile l’uso di questo protocollo all’interno della nostra applicazione.

Per oggi è tutto. Vedremo fra poco come fare tutto questo in pratica.

Il Java penso sia il linguaggio che più odio. Lo trovo un affarone sconclusionato che unisce la complessità di un linguaggio compilato alla pesantezza di un linguaggio di scripting.

Dopo questa premessa che sa molto di sfogo possiamo arrivare al dunque. Mi è capitato in questi giorni di avere bisogno di gestire dei singoli byte. Il Java ha il tipo byte al suo interno ma li gestisce con il segno, il che è abbastanza stupido dato che di solito uno che lavora con i byte li vuole unsigned. Dire che i byte sono interpretati come signed significa che degli 8bit che costituiscono un byte ne vengono usati 7 per rappresentare il numero e 1 per il segno. Questo causa fondamentalmente due problemi:

1. Il massimo numero positivo rappresentabile non è più 255 ma 127.
2. Bisogna stare attenti al segno. Ad esempio non si può fare un ciclo da 0 a 255 che scandisca tutti i possibili byte ma bisogna farlo da -128 a 127. Insomma, una rottura.

In tutti gli altri linguaggi esiste la parola chiave unsigned che permette con facilità di passare da interpretazioni con segno a interpretazioni senza segno. Nel Java NO. In Java tutti i tipi di dato sono sempre considerati signed ad eccezione del tipo char.

Abbiamo quindi bisogno di un modo per utilizzare dati unsigned.

La soluzione consiste nel promuovere il tipo di dato a quello più grande e passarlo in una maschera. Un esempio chiarirà il concetto:

Passare da byte signed a unsigned:

public static int unsignedByte(byte b) {
    int result = b & 0xFF;
    return result;
}

Come vedete basta inserire il byte in un int e fare un and bit-a-bit per annullare tutto all’infuori del byte.

Questo può sembrarvi uno spreco di memoria in quanto memorizzate 1 byte in un int (4 byte).  Invace no. In Java, per questioni prestazionali, il tipo byte occupa comunque 4 byte. Quindi lo spazio utilizzato è sempre lo stesso.

Analogamente potete creare un unsigned int inserendo un int in un long e mettendo in and con 0xFFFFFFFF. Questa volta però un po di spazio lo buttate.

Passare da int signed a unsigned:

public static long unsignedInt(int b) {
    long result = b & 0xFFFFFFFF;
    return result;
}

E’ bene tenere presente però che per molte operazioni l’uso di byte signed o unsigned è del tutto equivalente come ad esempio l’operazione di divisione intera o di modulo.

Ora non vi resta che divertirvi a giocare con i segni nella speranza che vi divertiate più di quanto mi sia divertito io a trovare la soluzione a questo problema.

Sto scrivendo la tesi. O almeno ci provo. Vado a rilento anche per colpa del caldo afoso, del condizionatore che si è rotto (in pieno Agosto e con tutti i condizionatorologi in ferie) e del pellegrinaggio continuo che faccio da casa mia a casa della mia ragazza (70km di distanza).

Però cerco di sfruttare a pieno ogni 5 minuti di “concentrazione” che spremo dal giorno.

Per fare questo ho due fidati strumenti: NetBeans 6.7 e Git.

NetBeans è il famoso IDE di sviluppo made in Sun che è una vera manna per gli sviluppatori Java (ma anche C/C++ e Ruby). Molto potente ed estendibile e che mi piacerebbe tanto iniziasse a potenziare anche l’attuale minimale supporto a Python.

Git è invece uno dei tanti sistemi di versioning che popolano il mondo e che ho provato (vi giuro, li ho provati tutti). Ha il pregio di essere dannatamente veloce anche se il prezzo da pagare è una piccola maggiore difficoltà di utilizzo. In realtà non è poi così difficile ma rispetto agli altri (Subversion, Mercurial e Bazar per esempio) si comporta diversamente e può un attimo spiazzare i nuovi arrivati.

Il problema principale è far dialogare NetBeans con Git.

Nei plugin “ufficiali” non c’è nulla: NetBeans supporta tutto tranne Git. Ma esiste la soluzione!

La soluzione è: http://nbgit.org/

NBGit è un plugin che integra Git in NetBeans risolvendoci tutti i problemi e rendendo NB l’IDE che supporta il maggior numero di sistemi di versioning.

Purtroppo almeno a me non funziona molto bene e lo devo “arrangiare” con qualche comando impartito da terminale.

Ma dopotutto è solo alla versione 0.2… diamogli tempo e diventerà essenziale!

EDIT: E’ uscita la versione 0.3. Adesso il plugin è veramente completo!

ENEA

Ho scelto il progetto di reti che porterò come “tesi” della triennale. A dire il vero l’ho scelto già qualche settimana fa ma poichè il suo sviluppo si sta rilevando più interessante e istruttivo del previsto ho deciso, come mio solito, di condividere gran parte del mio lavoro. Come mio solito, inoltre, ho complicato la traccia del progetto per renderlo “più divertente” o quantomeno renderlo qualcosa che possa uscire al dilà della fredda sessione di laurea.

ENEA è l’acronimo di Environmento for Network Applications, ovvero un infrastruttura per l’esecuzioni di applicazioni basate sul Grid Computing e specialmente il Calcolo Distribuito.

L’intera applicazione è scritta in Java (come da buona tradizione universitaria) e fa uso di librerie standard (quindi portabili e multipiattaforma). Per ora non c’è nulla di funzionante in quanto mi sono dedicato per lo più alla fase di analisi e progettazione.

Presto metterò altre informazioni.