Per la serie “Un paese senza”, vengo a sapere che ad oggi non è pos­sibile sviluppare applicazioni basate su Android in Italia.

Altre info in questo post.

Sto cercando di farmi un’idea sulle caratteristiche di Android, in particolare sulla virtual machine(VM)  usata per le applicazioni Java.

La particolarità ruota intorno al fatto che la VM per i cellulari non è rilasciata in open source quella standard e Google, essendo quello che è, ha trovato la sua soluzione: Davik. 

Davik è una VM che usa un suo bytecode e può anche usare le librerie di Java SE ma, grazie ad Android, permette agli sviluppatori di continuare ad usare la sintassi di Java. Il sorgente viene prima compilato nel bytecode Java e poi convertito. Dire che è brillante è dir poco, anche se certo un approccio così invasivo ha anche le sue controindicazioni.

Infine, una nota “personale” sul tema Android vs iPhone. Nella maggior parte dei blog che ho letto prima o poi salta fuori il confronto con l’iPhone; tipicamente seguendo un’equazione del tipo: “Adroid = aperto = bene” “iPhone = chiuso = male”. C’è del vero, anzi molto. Tuttavia bisogna notare due cose: 1) sono i risultati che contano. Il primo cellulare su Android uscirà a metà del pros­simo anno e voglio vedere come sarà e quali vantaggi tangibili per l’utente finale ci saranno. 2) Non è detto che ci sia una qualche forma di “porting” verso l’iPhone che, non dimentichiamolo, è prodotto completo e non “solo” una piattaforma software – lo so, lo so: una piattaforma è più importante di un prodotto ma voglio enfatizzare il fatto che gli utenti vedono e comprano il secondo e non la prima; questo può avere un suo peso, resta da capire quanto. References:

• Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME;
• Google’s Android — Architected for Participation;
• Dalvik — Google’s tweaked, non-standard JVM for Andriod!!!!
  

Anche se sono mesi che non apro Eclipse, le novità dell’ultima versione di JUnit sono benvenute. Ad es. adesso, al pari di altri frameworks – JMock, se non ricordo male – è pos­sibile scrivere cose del tipo:

assertThat(x, is(3));
assertThat(x, is(not(4)));
assertThat(responseString, either(containsString("color"))
    .or(containsString("colour")));
assertThat(myList, hasItem("3"));

Altra aggiunta utile e, soprattutto, che può cambiare l’approccio ad alcuni scenari di test è la pos­sibilità di esplicitare gli assunti ritenuti validi durante lo sviluppo:

assertThat(x, is(3));
@Test public void filenameIncludesUsername() {
       assumeThat(File.separatorChar, is('/'));
       assertThat(new User("optimus").configFileName(),
           is("configfiles/optimus.cfg"));
}

Ad oggi questi assunti non fanno fallire il test se si rivelano falsi.

Per estensione sono state introdotte le teorie. Ad es:

assertThat(x, is(3));
@RunWith(Theories.class)
public class UserTest {
  @DataPoint public static String GOOD_USERNAME = "optimus";
  @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";

  @Theory public void filenameIncludesUsername(String username) {
    assumeThat(username, not(containsString("/")));
    assertThat(new User(username).configFileName(),
        containsString(username));
  }
}

La teoria espressa da filenameIncludesUsername viene verificata per ogni @DataPoint e il test fallisce se, per un @DataPoint che conferma l’assunto, l’asserzione è falsa.

Grazie ai data point è ora pos­sibile scrivere test su insiemi in maniera più naturale; TestNG rimane ancora avanti in questo settore ma la distanza si è accorciata.

Una macchina virtuale dei processi (PVM, Process Virtual Machine) definisce un’astrazione per modellare dei flussi di lavoro, in modo indipendente dal linguaggio usato. La PVM permette di valorizzare quelle astrazioni che i flussi di lavoro hanno in comune tra di loro, sia quelli più comuni, legati mondo aziendale, sia quelli legati allo sviluppo software.

In questo modo si pos­sono risolvere alcune limitazioni degli attuali sistemi per la gestione dei flussi di lavoro: focalizzazione esclusiva sull’ambiente aziendale, frammentazione dell’offerta, integrazione difficoltosa nell’ambiente di sviluppo.

Le astrazioni principali di una PVM sono: nodi, transizioni, esecuzioni. Un nodo rappresenta uno dei pos­sibili passi compiuti durante il processo ed è associato ad un’interfaccia:


public interface Executable {
void execute(Execution execution) throws Exception;
}

Il nodo ha accesso allo stato corrente attraverso l’esecuzione, pas­sata come para­metro, ed è responsabile della transizione che risulterà dal completamento dell’esecuzione nonché dell’aggiornamento dello stato dell’esecuzione.

Link: The Process Virtual Machine

Con hotpatching si intende la pos­sibilità di sostituire una classe già caricata nel runtime con una nuova versione. In questo articolo, Jack Shirazi dimostra come sia pos­sibile modificare un’applicazione in esecuzione usando le nuove API messe a disposizione in Mustang (Java 6).

Elliotte Rusty Harold parte da una proposta di sintassi per le closures in Java e finisce per domandarsi come mai così spesso il loop di for diventa il bersaglio di così tante critiche e, di conseguenza, di così tante alternative. In effetti, nemmeno io ci sono molto affezionato… :-/

Il punto più importante, però, riguarda il fatto che i loop senza indice – ma in particolare si parla di closures – pos­sono anche non essere sequenziali e questo potrebbe portare ad un’esecuzione parallela. Viceversa, il for è strettamente sequenziale. Ovviamente, in alcune situazioni è pre­feribile il primo, in altre il secondo.

Ma questo vuol dire che il for e la versione con la closures non sono equivalenti.

Spinto dalla neces­sità di testare delle procedure di migrazione di un database, ho pensato bene di fare una smanettata con  TestNG. Beh, direi che è una manna dal cielo!!

Ci sono diverse cose che a mio parere rendono TestNG nettamente migliore di JUnit:

• Un set di annotazioni più esteso
• È molto più fles­sibile nel clas­sificare i test
• È pos­sibile stabilire delle dipendendenze fra i test
• È configurabile tramite file
• È pos­sibile ripetere lo stesso test con un set di dati a piacere. I dati pos­sono essere pas­sati dalle configurazioni o dai @DataProvider. Con questa annotazione ho potuto automatizzare i test in modo molto più esaustivo.
• Di default, TestNG ri-esegue solo i test falliti dal lancio precedente

Credo che basti a far venire un po’ di appetito… Altri links:

• JUnit vs TestNG: un confronto fra i due frameworks
• Statistical testing: uso di TestNG in scenari difficilmente testabili da JUnit

Al posto di usare synchronized:
private static Singleton _INSTANCE;
public static synchronized Singleton getInstance() {
if(_INSTANCE == null) {
//initialize...
}
return _INSTANCE;
}

O, ancora peggio, il Double Checked Locking, è meglio usare un idioma del tipo:

static class SingletonHolder {
static Singleton INSTANCE = new Singleton();
}


public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}

Links:

• Lazy Loading Singletons
• Effective Java

Bruce Eckel rompe gli indugi e dice senza mezzi termini che Java a livello del client è sostanzialmente un fallimento. Cita anche la ormai famosa frase di Jobs sul perché Java non sarà inclusa nell’iPhone. Jobs ha ragione, ma ha semplicemente detto quello che tutti sanno e comunque la frase va messa nel contesto di un telefono cellulare: una JVM solo per far girare un applet è un prezzo un troppo da pagare.

Il post di Eckel, tuttavia, non parla di cellulari; il suo discorso è molto più generale. ora, sono d’accordo con lui che le applet sono state un fallimento, anche se per questo non ci voleva Bruce Eckel: come dicevo prima, il re dal quel lato è nudo da un pezzo.

Non concordo nel dire che il web sia un casino solo perché le pagine sono diverse a causa dei font diversi. Sarebbe come dire che la televisione è un disastro perché io vedo lo stesso programma in bianco e nero e il mio vicino in alta definizione. È vero, Ajax è già troppo abusato e spinto oltre i limiti del ragionevole ma il punto fondamentale è che cercare di controllare in maniera assoluta la GUI, su web, è futile. Il web funziona perché è un casino: è semplicemente irrealistico pensare che tutti i client vedano esattamente la stessa cosa, allo stesso modo.

Il web, anche prima di Ajax e compagnia bella, ha dimostrato di essere un medium estremamente fles­sibile e agli utenti non importava poi molto se l’interfaccia era legnosa e poco fles­sibile. Anzi, la GUI spartana rende più semplice agli utenti pas­sare da un sito/applicazione ad un altro.

Questo non vuol dire che sistemi come flex non abbiano meriti, tutt’altro. Ma forse è il caso di contestualizzare un po’ di più il discorso.

Altri links:

• http://www.flex.org/
• f3

L’ultima newsletter di Java Performance Tuning è uno speciale sui miglioramenti apportati alla versione 6 della JVM.