Category Archives: java

Oltre java.util.Random

Daniel Dyer sta pubblicando sul suo blog una serie di articoli dedicati alla generazione di numeri casuali con Java. Tutti i programmatori Java prima o poi utilizzano la classe java.util.Random, che però va bene solo per semplici casi: necessità di una distribuzione uniforme e nessun requisito di sicurezza.

Per la crittografia usare java.util.Random è un peccato mortale: la classe da utilizzare in questo caso è java.security.SecureRandom. Per verificare quanto siano poco casuali i bit generati da java.util.Random fate riferimento a questa pagina: http://www.alife.co.uk/nonrandom/index.html.

Dyer coglie l’occasione per fare “pubblicità” al suo progetto opensource uncommons-maths, rilasciato sotto licenza Apache, che utilizza diversi motori casuali (Marsenne Twister, un generatore basato sugli automi cellulari che piacerebbe a Stephen Wolfram e un generatore basato su AES) e può generare numeri secondo diverse distribuzioni: uniforme, gaussiana, di Poisson, binomiale e esponenziale. È disponibile un demo che mostra in modo sensibile le diverse distribuzioni, basta eseguire sul proprio terminale preferito:

javaws https://uncommons-maths.dev.java.net/demo/demo.jnlp

Gli articoli pubblicati da mentre scrivo sono i seguenti:

Nei prossimi post della serie Dyer parlerà dei gradi di libertà nel mischiare un mazzo di carte e dei problemi da gestire quando si usano numeri casuali nella crittografia.

Nel suo profilo su LinkedIn Dyer scrive di avere esperienza nella programmazione di giochi online relativi a giochi d’azzardo: nessuna meraviglia che sia interessato alla generazione efficiente di numeri casuali (gli algoritmi random utilizzati da un programma che simuli la roulette può essere perfettamente corretto e “fair”: sono le regole del gioco a far sì che alla fine della giornata il vincitore sia sempre il banco).

Creare un jar con dipendenze con Maven

Maven è un strumento molto utilizzato per gestire il ciclo di vita delle applicazioni sviluppate in Java. Per compilare tutti i sorgenti è sufficiente lanciare il comando:

mvn compile

Una cosa che all’inizio dell’uso di Maven mi era sembrata sorprendentemente ardua era creare un unico .jar contenente tutte le dipendenze necessarie per l’esecuzione del programma. La soluzione è molto semplice. Aprite il pom.xml del vostro progetto e aggiungete il maven-assembly-plugin:

    <build>
        <plugins>

            ...

            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <configuration>
                    <descriptorRefs>
                        <descriptorRef>
                            jar-with-dependencies
                        </descriptorRef>
                    </descriptorRefs>
                    <archive>
                        <manifest>
                            <mainClass>
                                com.application.MainClass
                            </mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>

            ...

        </plugins>
    </build>

Sostituite com.application.MainClass con il nome della classe contenente il main (compreso il package) e salvate il pom. Per generare il file jar eseguite:

mvn assembly:assembly

Implementare correttamente il pattern singleton in Java

Un pattern usatissimo (e soprattutto abusatissimo) nei linguaggi object oriented è il pattern Singleton, il quale in breve viene utilizzato quando si vuole essere sicuri che di una certa classe esista un’unica istanza. Lasciando da parte le discussioni sul perché sarebbe bene limitare al massimo l’uso di questo pattern, sul come sia sbagliato usarlo per raggruppare un insieme di funzioni “utility” e così via, occupiamoci della sua implementazione. Il metodo più ingenuo per implementarlo è il seguente:

// Implementazione lazy non thread safe
public class MySingleton {
  private static MySingleton instance;

  private MySingleton() {}

  public static MySingleton getInstance() {
    if (instance==null) {
      instance = new MySingleton();
    }
    return instance;
  }
}

Questa implementazione va benissimo finché l’applicazione è formata rigorosamente da un singolo thread. Nel caso in cui più thread possano richiamare il metodo getInstance() c’è una race condition: potrebbero entrambi superare il test dell’if e ottenere due istanze diverse della classe MySingleton.

La prima idea che viene per risolvere il problema è:

// Implementazione lazy corretta ma lenta
public class MySingleton {
  private static MySingleton instance;

  private MySingleton() {}

  public synchronized MySingleton getInstance() {
    if (instance==null) {
      instance = new MySingleton();
    }
    return instance;
  }
}

Questa implementazione è effetivamente thread safe, ma rende il metodo getInstance() sincronizzato, il che ha un certo impatto prestazionale, per cui sarebbe preferibile evitarla. C’è una soluzione semplice che però manca in laziness:

// Implementazione corretta non lazy
public class MySingleton {
  private final static MySingleton instance = new MySingleton();

  private MySingleton() {}

  public static MySingleton getInstance() {
    return instance;
  }
}

Questo codice è thread safe senza usare alcun costrutto particolare del linguaggio. L’unica sua pecca è che il riferimento all’istanza è inizializzato staticamente, per cui potrebbe istanziato anche molto prima della chiamata a getInstance() (basterebbe una chiamata a qualunque metodo statico di MySingleton per istanziarlo). Se nel programma considerato non interessa la laziness, questa può essere una buona soluzione, che ha anche il pregio di funzionare su tutte le versioni della JVM.

C’è una soluzione lazy apparentemente corretta detta double checked locking, molto in voga in passato, che però ha un subdolo bug che di fatto la rende thread unsafe:

// Implementazione non thread safe
public class MySingleton {
  private static MySingleton instance;

  private MySingleton() {}

  public static MySingleton getInstance() {
    if (instance==null) {
      synchronized(MySingleton.class) {
        if (instance==null) {
          instance = new MySingleton();
        }
      }
    return instance;
  }
}

Supponiamo di avere due thread, thread1 e thread2 che richiamano il metodogetInstance(): thread1 passa il test per entrambi gliif e inizia l’istanziazione di MySingleton, a questo punto thread2 esegue il primo if. Poiché non è entrato nella sezione sincronizzata non c’è una relazione “happens before” tra i due thread, e il comportamento del codice non è definito: thread1 potrebbe ricevere una istanza corretta, una non correttamente inizializzata o null (e istanzierebbe dunque un altro oggetto MySingleton, e il pattern è distrutto).

Con Java 5 è stato formalizzato il modello di memoria di Java, e è possibile modificare il codice precedente in modo che sia corretto anche se richiamato da più thread:

// Implementazione lazy thread safe *solo* per Java 5 e successivi
public class MySingleton {
  private volatile static MySingleton instance;

  private MySingleton() {}

  public static MySingleton getInstance() {
    if (instance==null) {
      synchronized(MySingleton.class) {
        if (instance==null) {
          instance = new MySingleton();
        }
      }
    return instance;
  }
}

La differenza è nella keyword volatile davanti alla variabile instance. Dichiarare una istanza come volatile significa che un aggiornamento della variabile stabilisce una relazione “happens before”. In un certo senso è come se i lettori e gli scrittori della variabile utilizzassero blocchi sincronizzati per cui il lettore ha la garanzia di vedere il valore correttamente aggiornato dallo scrittore.

Questo tipo di double checked locking è thread safe e probabilmente più veloce della versione che utilizza il metodo dichiarato come synchronized, anche se la differenza è probabilmente molto piccola. Questa versione non è garantito che funzioni correttamente con versioni di Java dalla 1.4 e precedenti (questo perché il memory model è stato formalizzato con Java 5), mentre è garantito funzionante dalla versione 5 in poi. Inoltre le variabili volatile danno delle penalizzazioni prestazionali su sistemi multi-CPU paragonabili a quelli della sincronizzazione.

Esiste una versione ancora più elegante, lazy, thread safe e funzionante su tutte le versioni di Java ideata da William Pugh:

// Implementazione lazy thread safe
public class MySingleton {
  private MySingleton() {}

  private static class MySingletonHolder {
    private final static MySingleton instance = new MySingleton();
  }

  public static MySingleton getInstance() {
    return MySingletonHolder.instance;
  }
}

Il “trucco” è nel fatto che la classe interna MySingletonHolder viene caricata dal class loader la prima volta che c’e n’è bisogno, vale a dire quando viene usata dal metodo getInstance(), per cui questo codice è thread safe senza usare costrutti particolari, è lazy perché non anticipa l’istanziazione del singleton e funziona su tutte le versioni di Java.

Il singleton è un pattern molto semplice, ma è sorprendentemente poco intuitivo realizzarne una implementazione corretta. A questo proposito Jon Bentley in Programming Pearls ricorda come la prima descrizione dell’algoritmo di ricerca binario (il binary search) sia stata pubblicata nel 1946, ma la sua prima implementazione corretta solo nel 1962. Come scriveva Donald Knuth:

Beware of bugs in the above code; I have only proved it correct, not tried it.

Una libreria per visualizzare i PDF con Java

Java icon by everaldo.comJoshua Marinacci ha annunciato il rilascio da parte di Sun Microsystem di pdf-renderer, una libreria in puro Java per il rendering di documenti PDF. Questa libreria, derivante dallo sviluppo di OpenOffice, permette di visualizzare sullo schermo i documenti, ma può anche essere usata per effettuarne il rendering su immagini .png. pdf-renderer è in grado solo di visualizzare i PDF e effettuarne il rendering, ma non di crearli, per questo può essere utilmente affiancato a iText. Lo standard PDF 1.4 è supportato in modo pressoché completo, a parte le trasparenze, i form e alcuni encoding.

pdf-renderer è rilasciato sotto licenza LGPL e quindi può essere utilizzato gratuitamente senza eccessivi problemi anche in applicazioni commerciali o closed source, al contrario dell’incumbent JPedal, che viene rilasciato con licenza duale commerciale/GPL (e vanta una maggiore aderenza allo standard come specificato da Adobe).

Trovate una raccolta di librerie per creare, visualizzare e gestire PDF con Java all’indirizzo http://java-source.net/open-source/pdf-libraries.