Feeds:
Posts
Comments

Posts Tagged ‘Java’

Era da parecchio che non scrivevo più un post tecnico, e forse nemmeno questo sarà così tecnico, quanto più una rapida riflessione.

Nel paio di settimane di ripresa del lavoro dopo le vacanze estive, ho avuto occasione/necessità di scrivere un paio di utility da usare su un paio di sistemi embedded, essenzialmente per scaricare dati usando un po’ di protocolli (modbus, messaggistica di TinyOS). La scelta del linguaggio un po’ di tempo fa sarebbe ricaduta su un banale Java, ora invece è ricaduta su Scala.

Premessa: tendo a non prendere in considerazione linguaggi di scripting per cose che non siano uno script scritto al volo e da usare due volte in croce; questo perchè, per quanto apprezzi linguaggi come Python quando serve,

  1. la struttura del programma tende a degenerare rapidamente: se non sei costretto dal linguaggio a mantenere un minimo di struttura, e non hai tanto tempo da perdere (una delle utility è stata scritta in una giornata, per poterla testare sul campo il giorno successivo), non fai nulla per dare almeno quel minimo di struttura
  2. se il linguaggio non è compilato, tendo ad evitarlo: il lavorare solo a runtime ti costringe ad intercettare la classica quantità di ca***tine solo eseguendo il programma n volte, mentre se compili quegli stessi problemi li risolvi molto prima (se penso a tutte le volte in cui ti accorgi di aver sbagliato la ricezione di un messaggio in Erlang per aver invertito due parametri in una tupla…).

Dicevo: la scelta ormai ricade su Scala, dato che:

  • ha un build system tutto sommato decente (per quanto sotto ci sia Ivy ed i repository di Maven): salvo trovare incompatibilità tra versioni di Scala e versioni di libreria, funziona abbastanza bene e si configura con un semplice file di testo
  • ha il sistema di classi e quant’altro di Java
  • è compatibile con Java (fondamentale: per modbus avevo già testato tempo fa una libreria che funzionava sui miei apparecchi, e TinyOS ha una versione Java delle sue librerie)
  • è (anche) funzionale: se un linguaggio non mi supporta lambda, liste ed il trittico filter/map/fold, per quanto mi riguarda è un linguaggio che non considero
  • posso scegliere quando fare le cose immutabili e quando no (quest’ultima cosa praticamente mai, dato che la mutabilità è il male, ma in alcuni sporadici casi è un male necessario).

Tutto qui 🙂 a breve penso di scrivere un post un po’ più tecnico su un altro progetto più a lungo termine, fatto sempre in Scala, con cui ho potuto sperimentare con un po’ di tecnologie divertenti (tra cui Akka, Play e RabbitMQ).

Read Full Post »

Ebbene sì: il titolo che vedete non è per nulla inventato. Ma andiamo con ordine.

Esiste un sistema operativo: TinyOS. E’ pensato per reti di sensori, le quali sono costituite da devices che si interfacciano con i computer tramite porta seriale (travestita da USB, ma poco importa in questo contesto). Di conseguenza, tale OS viene distribuito con un set di librerie in alcuni linguaggi per leggere e deserializzare il più comodamente possibile i messaggi trattati all’interno del sistema stesso, così da poter ricevere i dati ed elaborarli in qualche modo. La struttura standard di una WSN, infatti, prevede che uno dei devices funga da sink e riceva le comunicazioni dell’intera rete, per poi trasferire queste informazioni in un computer (che le salverà in qualche formato). I linguaggi di questo piccolo SDK sono C, C++, Java e Python.

Per poter interfacciare un device di una WSN con un computer a bassa potenza come una Carambola, è necessario utilizzare le versioni C o C++, dato che sia Python che Java non sono tendenzialmente supportati su quel tipo di schede. Ora, mentre sfogliate i sorgenti che leggono le porte seriali, potreste imbattervi nella seguente riga:

#include “../../java/net/tinyos/packet/BaudRate.java”

Tah-da! Un file sorgente C include un file Java al suo interno! Vi lascio qualche momento per rabbrividire adeguatamente della cosa…

Ok, l’idea di fondo è la seguente: esiste una lista riempita in un file Java strutturata come segue:

package net.tinyos.packet;

class BaudRate {
static void init() throws Exception {
Platform.add(Platform.x, “mica”, 19200);
Platform.add(Platform.x, “mica2”, 57600);

}
}

Il problema è che tale lista è necessaria anche nella versione C (che deduco essere arrivata dopo quella Java), e anzichè replicare le informazioni, gli sviluppatori hanno deciso di includere il file Java dentro quello C.

La sintassi è adeguatamente simile, e per far funzionare il giochino (come spiegano alcuni commenti del file C) è necessario:

  1. definire alcune define (perdonate il gioco di parole), affinchè la dichiarazione di package, di classe e di metodo non interferiscano in alcun modo con il codice C; tali definizioni si trovano in fondo al file C, dato che (mi è stato fatto notare) probabilmente scrivere qualcosa come “#define void” e ridefinire parole chiave che esistono in C creerebbe troppi problemi in altri punti del codice (ma non sono certo di questo)
  2. definire alcune struct con puntatori a tipi e funzioni, così che le chiamate del tipo “Platform.add” vengano interpretate correttamente e, come conseguenza, la variabile “args” alla fine contenga esattamente il secondo e terzo parametro della linea corretta tra le varie “add” (il secondo parametro è riempito dai sorgenti, tutto questo sistema serve per fare una sorta di lookup tra le linee “add” e ricavare il numero che indica il baudrate da utilizzare nella comunicazione con la seriale).

Chiaro, no? Non sono sicuro di riuscire a scendere ulteriormente nel dettaglio delle struct stesse, dato che sono un tantino convolute ed io non scrivo codice C da un po’, ma sono certo che un’occhiata ai sorgenti permetterà ai nerdoni tra voi di capire al volo come funziona il meccanismo!

Read Full Post »

(Edit: lo davo per scontato, ma meglio chiarirlo: nel grafico sottostante l’asse Y è misurato in millisecondi di esecuzione per ciascun test, quindi un valore inferiore è preferibile)

Uno dei punti di forza da sempre declamati di Erlang è la capacità del runtime di gestire la concorrenza anche di migliaia di processi leggeri, grazie alle capacità del runtime, sviluppato appositamente attorno (tra le altre cose) a questa caratteristica. E’ anche il motivo per cui si dice che linguaggi concorrenti implementati su altre macchine virtuali (ad esempio, Scala sulla JVM) non potranno mai avere le medesime prestazioni.

Ebbene, dopo un post intrigante in una mailing list, ho esplorato le prestazioni del progetto Erjang (Erlang sulla JVM) versus Erlang stesso, utilizzando un programma di test distribuito direttamente con i sorgenti di quel progetto: gli autori di Erjang stesso dichiarano che le performance sono, in media, in linea con quelle del runtime originario; il mio test è stato fatto sull’Atom N270 dell’Eeepc, ed è interessante vedere come in alcuni punti la versione Java riesca ad avere le performances più alte.

Grafico del confronto

Grafico del confronto

Ammetto di non aver fatto i test in modo eccessivamente scientifico, in ogni caso i valori sono stati presi alla seconda esecuzione del test stesso, supponendo che la prima possa essere inficiata dal caricamento o dalla compilazione del codice.

Read Full Post »

Tradimenti di Java

Il codice incriminato:


public class Test {
    public static void main(String[] args) {
        String a1 = "test";
        String a2 = "test";
        System.out.println(a1 == a2);
        a2 = new String("test");
        System.out.println(a1 == a2);
    }
}

Il primo confronto ritorna true, mentre il secondo false: ora, io avevo sempre pensato che una stringa inizializzata nel primo modo fosse semplicemente una scorciatoia al posto di new, invece a quanto pare sono due cose profondamente diverse. Il primo confronto dovrebbe, a norma di legge, confrontare i riferimenti, non i contenuti, ed invece non è così (nonostante i due oggetti siano dichiarati separatamente).

Perchè l’ho chiamato tradimento? Bè, perchè questo viola chiaramente il presupposto degli oggetti in Java: per quanto le stringhe siano un tipo base, sono comunque oggetti a tutti gli effetti, o almeno lo erano prima di questa scoperta… inutile dire che vale lo stesso fattaccio anche per gli oggetti che incorporano i tipi base (Integer vs. int). Questo dimostra comunque che conviene usare equals, dato che se una stringa viene ricreata l’== non funziona più, ma resta un notevole pacco.

Un ringraziamento a Maintux, che ha insinuato il seme del dubbio, ed a Sante che ha condiviso un’istanza di Eclipse all’uopo.

Read Full Post »

Brevissimo update del mio ultimo post su Arduino & Java: ho verificato un sospetto che avevo, ed in effetti il codice di test funziona, il problema era dovuto ad una differenza di baud rate: il default dello sketch è 57600, mentre quello della classe Java Arduino è 115200; sovrascritto quest’ultimo valore (usando un costruttore diverso), la demo funziona correttamente.

In allegato, il codice aggiornato (con tanto di script Ant, se non volete usare Eclipse; dovrete comunque passare il path della libreria nativa all’interprete, temo): Arduino – Eclipse.

Read Full Post »

Ieri ho avuto il piacere di giocare con la seguente guida, che di fatto è un’unione di altre due guide, e permette di programmare l’Arduino in Java.

“Eh?”, diranno i puristi. Ebbene sì: caricando nel microprocessore uno sketch incluso tra gli esempi del PDE di Arduino (StandardFirmata), e creando un progetto Java sotto Eclipse (ma non siete obbligati ad usare un IDE, vi basta anche una mano di Vim) con giusto un paio di jar di Processing, una sorta di sottolinguaggio costruito per fare arte e programmare (non chiedetemi una definizione migliore, non saprei darvela, nemmeno io ho le idee chiarissime su cosa diavolo sia), è possibile di fatto impiegare l’Arduino come un oggetto remoto.

Ora, non vorrei che l’ultima definizione spaventasse qualcuno, ma il corso di sistemi distribuiti ha avuto i suoi effetti: nel codice Java diviene possibile, con questa modalità, creare un oggetto della classe Arduino (che trovate linkata nell’articolo di cui sopra), e su di esso chiamare i metodi corrispondenti alle API C++ che normalmente si usano per programmare la piattaforma; la classe stessa si occupa di comunicare via seriale con l’hardware Arduino e, tramite lo sketch caricato in precedenza, di eseguire in remoto i comandi e restituire il risultato direttamente in Java.

Ora, questo potrà sembrare una bella sega mentale e basta, ma in realtà apre alcune prospettive decisamente interessanti: per quanto, così facendo, si perda la caratteristica di standalone del circuito elettrico, dato che la comunicazione seriale diventa obbligatoria (tenete presente che il programma che caricate nel microprocessore si limita ad eseguire comandi remoti, non li memorizza), resta il fatto che trattare Arduino come un semplice oggetto, come tutte le altre cose in Java, permette una certa flessibilità sicuramente interessante, ed evita al programmatore di dover mettere le mani direttamente nel protocollo seriale per gestire la comunicazione stessa (oltre al fatto che si utilizza un linguaggio serio(TM), per quanto comunque il PDE di Arduino nasconda una parte del codice C++ necessario a far funzionare i vostri circuiti).

Insomma, non ho ancora fatto grossi esperimenti in merito, ma sicuramente è una modalità stimolante e da approfondire.

P.S.: rispetto all’articolo linkato in alto, è necessario aggiungere che deve essere importato anche il jar di RxTx, la libreria seriale, che trovate nella stessa cartella di Processing dove si trova Serial.jar; all’archivio Java va inoltre aggiunta la libreria librxtx.so, sempre dalla stessa cartella, che potete settare nelle proprietà del Build Path in Eclipse come nativa per rxtx.jar.

P.S.S.: includo anche uno zip del progetto di esempio dell’articolo, così com’è, con incluse anche le librerie richieste, già impostate nel progetto di Eclipse; resta il fatto che, ad un primo test, il led incluso nell’Arduino non si sia acceso, nonostante io abbia usato il pin 13, ma potrei aver cannato qualcosa (e, d’altro canto, l’autore dice di usare un led esterno, che io non ho). Arduino – Eclipse

Read Full Post »

Ho appena letto due articoli molto interessanti da IBM DeveloperWorks: dato che si sta ormai festeggiando il ventennale di Java, è d’uopo un’analisi dello stato del linguaggio di programmazione (ormai vicino alla sua settima major release) e del mondo che lo circonda, specie a seguito del passaggio di proprietà da Sun ad Oracle (e prima ancora, del suo rilascio sotto licenza libera), per vedere se e quale futuro ci può essere. Penso che tutti i miei 10 lettori sappiano che Java è il mio linguaggio di programmazione preferito in assoluto, e quindi non posso esimermi dal riportare alcuni dettagli interessanti (per quanto vi consigli comunque la lettura perlomeno del primo dei due articoli stessi).

Riflessioni dagli utilizzatori

Nel primo articolo, l’autore convoca una sorta di tavola rotonda digitale, in cui chiede ad alcuni sviluppatori vicini al mondo DeveloperWorks il loro parere sulle questioni sul piatto di Java in questo 2010; in linea generale, l’aspetto positivo che emerge è la varietà di approcci, framework e librerie che si sono sviluppate non tanto e non solo intorno a Java, ma intorno alla sua Virtual Machine, in modo tale che alcuni dei difetti che emergono per Java stesso sono magari già superati da altri approcci compatibili (da un punto di vista di API) ma allo stesso tempo molto diversi (come produttività); alcune risposte emerse degne di osservazione:

  • il primo difetto di Java è l’ammontare di codice necessario per fare qualunque cosa (assolutamente sperimentato anche da me, nel mio piccolo, specie nelle tecnologie usate quest’anno a Sistemi Distribuiti (vero, Sante?)): il futuro inevitabilmente si sposta verso quei framework che sono in grado di sviluppare rapidamente (Agile alla fin fine, Rails in altre parole) e che permettano all’informatico di concentrarsi sulle (famigerate) parti funzionali del prodotto, ed ignorare il più possibile le non funzionali (vedi i behaviour di Erlang); da questo punto di vista, alcuni passi avanti sono già presenti in Java 7 (vedi secondo paragrafo), altri erano già nati in librerie collaterali, altri già sono usabili sulla JVM.
  • Le preoccupazioni verso Oracle sembrano essere venute meno, anche se si teme un po’ per il mondo Open Source (e già c’è stato l’esempio di OpenSolaris, su cui non approfondisco ulteriormente per non uscire dal tema) e sul fatto che alcune delle cose, che sono sempre state libere, di punto in bianco possano non esserlo più (ma nessun esempio viene fatto in merito); fortunatamente, aggiungo io, Java è ora sotto GPL, il che non è male, senza contare il fatto che gli autori sembrano a tratti sottovalutare il potere del Free Software, che invece io ritengo discretamente rilevante.
  • La modularizzazione che verrà introdotta con Java 7 (hopefully, aggiungo io) non sembra riscontrare i favori della tavola rotonda, in particolare si criticano gli approcci, forse troppo teorici o comunque troppo lontani dalla realtà.
  • Non mi soffermo sul problema di “Java è morto”: premesso che lo si dice da anni (e non succede, per ora), il fatto che la Virtual Machine supporti molti altri approcci diversi (funzionali piuttosto che “a la Rails“) fa supporre che il “mondo Java” non sia così facilmente abbattibile.
  • Il cloud computing (parafrasando gli Iron Maiden: “Cloud, cloud everywhere / Cloud, cloud everywhere“): per quanto tutti ritengano il cloud soprattutto una buzzword del momento, l’idea è che le tecnologie sottostanti restino interessanti, ed in particolare l’acquisizione di SpringSource da parte di VMWare fa pensare ad uno sviluppo in quella direzione del famoso framework Spring.
  • Java nelle nuove industrie: tolto il discorso cloud, il discorso mobile (Android in particolare) è assolutamente interessante, sottostando tuttavia alla risoluzione positiva della modularizzazione, ed al contempo all’affrontare e risolvere in maniera decente Java ed il multimedia (da sempre tallone d’Achille, per usare un eufemismo).

Da notare, a margine, come il campo dell’informatizzazione nel no-profit sia ritenuto assolutamente redditizio e colonizzabile, ed è interessante dato che è un discorso emerso anche tra di noi in altre sedi e con altre persone.

Java 7

Il secondo articolo si concentra invece sulle innovazioni che Java 7 (previsto entro l’anno) dovrebbe portare con sè; integro i punti seguenti anche con un paio di riflessioni del primo articolo (per evitare di ripetere le cose due volte), sottolineando come ho ignorato la seconda parte di questo articolo, dato che si parla della VM di IBM, che io non uso (e che peraltro credo sia a pagamento):

  • semplificazione della scrittura di linguaggi “di scripting” sulla JVM: ne avevo già sentito parlare l’anno scorso, dato che avevo fatto una ricerca in merito per l’articolo del corso di “Argomenti avanzati di Ingegneria del Software” (e, se vi interessa, leggetevi l’articolo tra le mie pubblicazioni), e di fatto sono introdotte cose (che io non voglio sapere…) per rendere semplice la resa di linguaggi dinamici in bytecode, velocizzandone anche le prestazioni.
  • Le stringhe nei costrutti switch: sono quasi commosso, dato che è una cosa di una utilità tremenda, che ho sempre invidiato a PHP.
  • Le chiusure: alcuni autori nella tavola rotonda sottolineavano come la popolarità di linguaggi su JVM come Groovy indichi che il popolo richiede a gran voce le chiusure, e queste atterreranno nei nostri computer molto presto; la sintassi definitiva è ancora in fase di sistemazione, ma restano sicuramente interessanti soprattutto per la dinamicità del codice che risulta.
  • La concorrenza tra processi e thread: mi viene di nuovo in mente Erlang, quando viene citato il framework Kilim (con cui devo assolutamente curiosare) ed il paradigma fork-join che verrà portato con Java 7, che di fatto è l’idea che sta dietro anche all’algoritmo di map-reduce; l’applicazione forzata del buon vecchio Divide et impera non può che essere importante all’alba dei multicore.

In conclusione (mia, non degli articoli)

Insomma, tirate le fila di queste riflessioni, direi che di carne al fuoco ce n’è parecchia ancora: sono sinceramente curioso di provare qualcuno dei linguaggi costruiti sulla JVM (ad esempio Scala, cui avevo assistito ad una presentazione lo scorso JavaDay), e di vedere come sarà la versione finale delle closure (dato che, ormai, con il mio lavoro di tesi su Erlang ne uso a palate); non credo che Java sia morto, o quantomeno non credo che morirà senza combattere.

Read Full Post »

Older Posts »