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!

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.