Flavio CDC - software developer

Test di Wilcoxon per due campioni

2013-07-18T11:14:00.002-07:00

Il contenuto di questo sito è rilasciato sotto licenza se non specificato diversamente

Test di Wilcoxon per due campioni

Per eseguire in R il test di Wilcoxon per due campioni è necesario utilizzare la funzione wilcox.test.
Vediamo un esempio di applicazione del test a due code su due campioni da (66 elementi) e db (40 elementi) non appaiati

wilcox.test(da,db,alternative="two.sided",paired=FALSE)

il risultato sarà nel nostro caso

 Wilcoxon rank sum test with continuity correction
 
data:  da and db 
W = 1142.5, p-value = 0.2482
alternative hypothesis: true location shift is not equal to 0

Da notare che vengno restituiti sia il P-value che il valore della statistica test W. La funzione wilcox.test prende in input molti parametri, alcuni dei quali opzionali; nell'esempio ne abbiamo utilizzati due:

paired: true o false–> Indica se i due campioni sono appaiati o meno
alternative: “two.sided”, “greater” o “less” –> indica se l'ipotesi alternativa è a due code o se è ad una coda (destra o sinistra)

Se inseriamo il risultato del test in una variabile invece che stamparlo a video otteniamo una struttura come la seguente

structure(list(statistic = structure(1142.5, .Names = "W"), parameter = NULL, 
    p.value = 0.248158967552218, null.value = structure(0, .Names = "location shift"), 
    alternative = "two.sided", method = "Wilcoxon rank sum test with continuity correction", 
    data.name = "da and db"), .Names = c("statistic", "parameter", 
"p.value", "null.value", "alternative", "method", "data.name"
), class = "htest")

Introduzione a java e generics parte 6 - Reificazione

2012-03-11T04:07:00.001-07:00

Reificazione, si è una parola Italiana …

PREV Evoluzione, non rivoluzione

Defnizioni di reifcazione

Processo mentale mediante il quale a concetti astratti viene assegnata consistenza di cose concrete

Nella flosofa di Marx, processo secondo cui nell'economia capitalistica l'uomo e il suo lavoro sono ridotti al valore della merce che producono

La reifcazione è una fallacia o un'ambiguità quando un'astrazione (una credenza astratta o un costrutto ipotetico) viene trattata come se fosse un concreto evento reale o un'entità fsica

Nell'ambito dell'Ingegneria della conoscenza, e in particolare della defnizione di ontologie, la reifcazione è una rappresentazione indiretta che prevede l'utilizzo di determinate espressioni del linguaggio per descrivere entità del mondo reale intuitivamente associate a espressioni di tipo diverso. L'esempio tipico di reifcazione è costituito dall'utilizzo di individui per rappresentare classi.

Nel contesto della programmazione orientata agli oggetti si defnisce reifcazione il procedimento di creazione di un modello di dati basato su un concetto astratto predefnito. Mediante la reifcazione, un computer può compiere elaborazioni riguardanti un'entità astratta come se si trattasse di un insieme qualsiasi di dati di altro tipo

Unchecked cast

Non sempre il compilatore è in grado di capire se un cast verso un tipo non reifcabile avrà successo I sistemi di tipi (dei linguaggi di programmazione orientati agli oggetti) non sono perfetti e non possono individuare situazioni di successo come può fare un (buon) programmatore Per questo motivo un cast verso un tipo non reifcabile non genera un errore ma un warning

In java

In java un tipo è reifcabile se il tipo è completamente identifcabile a runtime, ovvero se la type erasure non rimuove informazioni utili

Tipi reifcabili

Primitivi es: int
Classi o interfacce non parametriche es: String, Comparable
Tipi parametrici in cui tutti gli argomenti di tipo sono wildcard non limitati es: List<?> o Map<?,?>
Raw type es: List, Map Array di elementi di tipo reifcabile es: int[] , List<?>[]

Tipi non riefcabili

Variabili di tipo es: T in Xxxx<T>
Tipi parametrici con parametri attuali es: List<String>, Comparable<Integer>
Tipi parametrici con un limite es: List<? extends String> , Comparable <? super Number>

Note

In java il tipo di un array viene reifcato con il tipo dei suoi componenti Un tipo parametrico non viene reifcato con il suo parametro di tipo List<?> è equivalente a List<? extends Object> (nel senso di passaggio di parametri) ma il primo è reifcabile il secondo no

Instance test e cast

I test instanceof ed i cast dipendono dall'esame a runtime dei tipi degli oggetti coinvolti e quindi dalla reifcazione Test di istanza verso un tipo non reifcabile → errore (di compilazione) Cast ad un tipo non reifcabile → genera (di norma) un warning

public class Myinteger {
  private final int value; public boolean equals(Object o) {
 
Myinteger è reificabile → il cast non genere warning
if (o instanceof Myinteger){  // ynteger è reificabile → compila
 
return this.value ==
((Myinteger)o).value; } else return false; // Myinteger è reificabile → il cast non genere warning
} ...
}
</code java>
 
===== Equals su liste =====
<code>
public abstract class MiaLista<E> extends AbstractCollection<E> implements List<E>{
public boolean equals(Object o){ if ( o instanceof List<E>){
Iterator<E> it1 = iterator(); Iterator<E> it2 = ((List<E>)o ).iterator(); while (it1.hasNext() && it2.hasNext()){
E e1 = it1.next(); E e2 = it2.next(); if (! ( e1 == null ? e2== null: e1.equals(e2) ) ){
return false; }
}
} }
return !it1.hasNext() && !it2.hasNext(); } else return false;

Equals su liste: analisi

public abstract class MiaLista<E> extends AbstractCollection<E> implements List<E>{
public boolean equals(Object o){ if ( o instanceof List<E>){ Iterator<E> it1 = iterator();  // Errore di compilazione! List<E> non è reificabile
Iterator<E> it2 =
((List<E>)o ).iterator(); while (it1.hasNext() // Unchecked cast warning!
&& it2.hasNext()){ ...

Equals su liste: versione fxata

public abstract class MiaListaOK<E> extends AbstractCollection<E> implements List<E>{
Iterator<E> it1 = iterator(); Iterator<?> it2 = ((List<?>)o ).iterator(); while (it1.hasNext() && it2.hasNext()){
return false; }
}
}
return !it1.hasNext() && !it2.hasNext(); } else return false;

Analisi

public abstract class MiaListaOK<E> extends AbstractCollection<E> implements List<E>{ public boolean equals(Object o){
if ( o instanceof List<?>){ Iterator<E> it1 = iterator(); // OK List<?> è reificabile
 Iterator<?> it2 = (
(List<?>)o ).iterator(); // List<?> è reificbaile e non vengono generati warning
while (....
Object e2 = it2.next(); // Da una List<?> posso prelevare Object senza problemi

Cast non reifcabili

Test di istanza verso tipi non reifcabili generano sempre errore In alcune circostanze un cast ad un tipo non reifcabile può non generare warning

Nessun warning

public static <T> List<T> asList(Collection<T> c )
throws IllegalArgumentException { 
 if ( c instanceof List<?>){ // List<?> è reificabile → compila
return (List<T>)c; } else throw new // Il cast non genera waring in quanto la sorgente del cast ha tipo Collection<T> 
                                    // e ogni oggetto di questo tipo che implementa List deve avere come tipo List<T>
 
IllegalArgumentException("Il parametro passato non e' un sottotipo di List<T>");

public static List<String> converti(List<?> oggetti){ for (Object obj: oggetti){ //Il cast “a logica” non fallirà mai
if (!( obj instanceof String)){ throw new IllegalArgumentException( ... // OK String è reificabile
}}
return
(List<String>)(List<?>)oggetti; } // Unchecked Cast ← il compilatore non è in grado di capire se il cast avrà successo o meno

Nota: è illegare “castare” una lista di oggetti ad una lista di stringhe, quindi serve il doppio cast

Array e reifcazione

Gli array reifcano i loro componenti ovvero conservano a runtime i tipi dei loro componenti

Un vecchio esempio

Integer[] interi = new Integer[] {1,2,3}; // OK, gli array sono covarianti
Number[] numeri = interi;
numeri[2] = 3.14; // ArrayStoreException Double non è compatibile con il tipo reificato dell'array

Creazione di array

public static <T> T[] toArray(Collection<T> c){
 
T[] ret= new T[c.size()];  // NO! errore di compilazione
int i = 0 ; for (T x :c){ret[i++] = x;} return ret;
}

Le variabili di tipo non sono reificabili → viene generato un generic array creation error

Cannot create a generic array of T

Difetti ...

Non poter creare array di generics è una limitazione di java Array generici sono problematici a causa della erasure (tuttavia) erasure facilita l'evoluzione

In generale … dire “no!” ad array ed utilizzare il Collection Framework

Refection ...

Tramite refection è possibile ovviare al problema della creazione di array generici

Dont' try this at home

public static <T> T[]toArray(Collection<T> coll){
T[] ret = (T[]) new Object[coll.size()];  // Unchecked Cast!
int i = 0 ;
 for (T x :coll){ret[i++] = x;} 
return ret;
} --- 
List<String> stringhe = ... String[] a = toArray(stringhe); // Class Cast Exception

Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;
at generics.cap6.Ex1.main(Ex1.java:23)

Messaggio oscuro

Exception in thread "main" java.lang.ClassCastException: 
[Ljava.lang.Object; cannot be cast to [Ljava.lang.String;
at generics.cap6.Ex1.main(Ex1.java:23)

L signifca array di reference type
[LObject signifca array di Object, Object è il component type dell'array
L'errore non viene segnalato nel punto in cui viene generato (!) ma in un altro punto (!!!) ovvero nel main

Versione generata dall'erasure: analisi

public static Object[] toArray1( Collection coll){
Object[] ret = (Object[]) new Object[coll.size()]; // Unchecked Cast sparito! --> Erasure: converte il cast a T[] in un Cast a Object[]
int i = 0 ; 
for (Object x :coll){
ret[i++] = x;} 
return ret; }
 --- List<String> stringhe =
Arrays.asList("ciao","mondo"); 
String[] a = (String[])toArray(stringhe); //ClassCastError --> Erasure: inserisce il cast a String[]

Attenzione! Nonostante l'array contenga solamente stringhe, il suo tipo reifcato è un array di Object!

Cast iron guarantee (ancora)

I cast inseriti dall'erasure non falliscono mai a parte quando viene generato un unchecked cast warning Quando viene generato un unchecked cast warning allora i cast inseriti dalla erasure

Possono fallire
Possono essere segnalati in parti del codice diferenti da quella che ha generato l'errore

Adoro i soldi che generano i soldi

A volte un modo per fare soldi è tramite altri soldi. Lo stesso si può applicare agli array: generare array tramite un altro array

public static <T>
 T[] toArray( Collection<T> coll, T[] arr){
 T[] ret = null; ret = (T[])java.lang.reflect.Array.newInstance
(arr.getClass().getComponentType(), // unchecked cast
coll.size());
int i = 0; for (T elem: coll) ret[i++] = elem; return ret; }
}

Esecuzione del codice

List<String> a= Arrays.asList("ciao","a");
String[] st = toArray(a, new String[0]);
for (String s: st) System.out.println(s);

Ok! Funziona!
Il metodo getCoponentType() restituisce un “Class Object” che rappresente il tipo dei componenti dell'Array T
Class<?> ctype = arr.getClass().getComponentType(); Nel nostro caso è String

La versione "di classe"

public static <T> T[] toArray( 
Collection<T> coll, Class<T> classse){
 T[] ret = null; 
 ret = (T[])java.lang.reflect.Array.newInstance (
   Classse, coll.size() ); 
 int i = 0; for (T elem: coll) ret[i++] = elem; 
return ret; }

List<String> a= Arrays.asList("ciao","a");
String[] st2 = toArray(a, String.class);

Introduzione a java e generics parte 5 - Evoluzione, non rivoluzione

2012-03-05T02:15:00.001-08:00

Migrare gradualmente il codice all'utilizzo dei generics (evoluzione) senza modifche radicali (rivoluzione)

Evoluzione

L'implementazione dei generics permette che il vecchio codice venga compilato ed eseguito anche con l'utilizzo delle nuove librerie L'evoluzione è più forte della retro compatibilità: non esistono più versioni delle classi e delle librerie ma una sola versione (grazie alla type erasure) compatibile
Non sempre è possibile mettere mano a tutto il codice

È costoso
Non abbiamo accesso ai sorgenti
Possiamo mettere le mani solo sul client o sulla libreria
…

E' quindi necessario procedere per passi

Raw type e generic type

I raw types sono la controparte legacy dei generic types

Generic	Raw
Stack<E>	Stack
List<E>	List
ArrayStack<E>	ArrayStack

Casi di evoluzione

Dovendo utilizzare client con librerie abbiamo 4 casi

Client / Libreria	Libreria Generic	Libreria Legacy
Client Generic	CG,LG	CG,LL
Client Legacy	CL,LG	CL,LL

Client Generic, Libreria Generic

Non pone grossi problemi (è il punto di arrivo). Per arrivare a questo punto di norma tutte le occorrenze di Object vengono sostituite con opportuni parametri di tipo (solo dove ha senso)

Client Legacy, Libreria Legacy

Di norma è il punto di partenza dell'evoluzione in cui sono presenti solo raw type

public static void fai(List l) { ...}

questo codice genera un warning:

List is a raw type. References to generic type List<E> should be parametrized

Client Legacy, Libreria generica

E' il caso più importante di retro compatibilità: il Collection framework di java 5 deve funzionare con i client di java 1.4. Per supportare l'evoluzione, per ogni parametro generico java riconosce anche il suo raw type
Ogni tipo parametrico è sottotipo del corrispondente raw type
Un oggetto “parametrico” può quindi essere utilizzato quando ci si aspetta un raw type

Unchecked conversion warning

Di norma è un errore utilizzare un supertipo di T quando ci si aspetta un oggetto di tipo T.
Eccezione alla regola: è possibile utilizzare un raw type al posto di uno dei corrispondenti tipi parametrici
Viene tuttavia generato un unchecked conversion warning

List a = new ArrayList<String>(); // OK, normale sottotipizzazione
List<String> x = new ArrayList(); // OK ... ma genera un Unchecked Conversion Warning

Type safety: the expression of type ArrayList needs unchecked conversion to conform to List<String>

Unchecked conversion warning indica che il compilatore non è in grado di ofrire le stesse garanzie che sono possibili quando i generics vengono utilizzati in maniera uniforme.
Vengono comunque assicurate le stesse (???) garanzie di quando non si utilizzano per niente i generics (!!!)

Non vale la cast iron guarantee

Client generico, Libreria Legacy

List l
= new ArrayList<String>();
l.add(elem);

Il codice compila ma viene generato un Unchecked Call Warning

Pippo.java:7: warning: [unchecked] unchecked call to add(E) as a member of the raw
type java.util.List
l.add(elem);

Se i warning vi danno doia …

@SuppressWarnings("unchecked")

(a vostro rischio e pericolo)

Mysql e date con tutti ZERO

2012-02-13T03:40:00.000-08:00

Leggi l'articolo completo su flaviocdc.net

Premetto che non capirò mai a cosa serva la data 0000-00-00 in quanto se una data non è definita è meglio usare null, premetto inoltre che ho una certa antipatia per MySQL … purtroppo non posso scegliere io la tecnologia da usare quindi mi tocca usare anche MySQL.

Detto ciò, mi sono imbattuto nel problema di come gestire la data 0000-00-00 presente in un db MySQL all'interno di codeice java, ad esempio per recuperara la data da una colonna di una tabella.
Chiaramente il metodo getDate() lancia un'eccezione se trova una data del tipo 0000-00-00 in quanto non è una data (i progettisti di MySQL sanno che i giorni vanno da 1 a 31 ed i mesi da 1 a 12???); a me non piace neanche usare getString() e/o usare vari try/catch quindi cercando su internet ho trovato un'altra soluzione: modificare la URL JDBC in modo da passare null al posto delle date 0000-00-00 Tale URL è simile alla seguente

jdbc:mysql://myhost.mydomain/mydb?zeroDateTimeBehavior=convertToNull

da notare il parametro zeroDateTimeBehavior=convertToNull

Floating point da riga di comando

2012-02-02T02:21:00.000-08:00

Leggi l'articolo completo su flaviocdc.net

A volte, ma non troppo spesso, mi capita di dover inserire dei calcoli in virgola mobile in uno script bash; il problema è che (per quanto ne so io) bash non supporta i numeri in virgola mobile, è quindi necessario utilizzare una calcolatrice da riga di comando da integrare nello script bash. La calcolatrice che utilizzo è bc che si trova su molte distribuzioni linux e su Mac OS X Vediamo un esempio di funzionamento

miohost:~ miouser$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
11 / 3
3

c'è qualcosa che non torna …

compaiono degli “header” inutili –> questi possono essere messi a tacere con il flag -q (lanciare il comando bc -q al posto di bc)
i numeri non sono a virgola mobile –> per farli a virgola mobile è necessario impostare nello script bc il parametro scale=…

miohost:~ miouser$ bc -q
scale=5
11 / 3
3.66666

Per il resto … RTFM … ovvero man bc

Introduzione a java e generics parte 4 - Dichiarazioni di variabili

2012-01-31T11:44:00.001-08:00

PREV Confronti tra elementi

Costruttori

public class Coppia<P,S> {
 private final P primo; 
 private final S secondo; 
 public P getPrimo() {
  return primo; } 
 public S getSecondo() {
  return secondo; } 
 public Coppia(P primo, S secondo) {
  this.primo = primo;
  this.secondo = secondo; }}

In una classe generica i parametri di tipo appaiono nell'intestazione che dichiara la classe non nel costruttore!

Coppia<String, Integer> c = new Coppia<String, Integer>("Ciao", 1);
assert c.getPrimo().equals("Ciao") && c.getSecondo().equals(1);

Coppia<String,Integer> c = new Coppia("Ciao",1);

Warning! UncheckedWarning L'istruzione è legale ma genera un warning (non è detto che valga la Cast Iron Guarantee)

Static

List<Integer> interi = Arrays.asList(1,2,3);
List<String> stringhe = Arrays.asList("ciao","mondo");
assert interi.getClass() == stringhe.getClass();

I generics sono implementati tramite type erasure List<String> e List<Integer> a tempo di compilazione sono List

Type erasure →

variabili e metodi statici di classi generiche sono condivise tra tutte le istanze della classe
le variabili e metodi statici di una classe generica non possono far riferimento ai parametri di tipo della classe accedendo ad un metodo statico di una classe generica il nome della classe non deve essere parametrizzato (con la variabile di tipo)

Esempio static

public class Cella<T> { 
 private final int id; 
 private final T valore; 
 public static int count = 0;
 public static synchronized int getCount() { return count;} 
 public static synchronized int nextId() { return count++;} 
 public int getId() { return id; }
 public T getValore() { return valore;} 
 public Cella( T valore) { this.id = nextId(); this.valore = valore;}
...

Vediamo la classe all'opera

Cella<String>cs = new Cella<String>("ciao");
Cella<Integer> ci = new Cella<Integer>(1);
assert cs.getId() == 0 && ci.getId() == 1
       && Cella.getCount() == 2;

Il contatore è condiviso tra tutte le istanze della classe Cella

Utilizzo di metodi static

Cella.getCount() OK
Cella<Integer>.getCount() NO
Cella<?>.getCount() NO

Inner class

Java permette di annidare una classe dentro un'altra Se la classe esterna ha un parametro di tipo T:

Classe interna non statica → può accedere direttamente al parametro di tipo T
Classe interna statica→ non può accedere (direttamente) al parametro di tipo T ma esiste un escamotage …

Inner class non statica

public class Esterna<G> { ...
 private class Interna1{ 
  Gg =null; ...
 } ...
}

Inner class statica: escamotage

public class Esterna<G> { ...
public G getPippo() { return new Interna2<G>().getPippo();
} public static class Interna2<H>{
public H getPippo() { ...
} ...

Check than act

2012-01-31T02:03:00.001-08:00

A cura di Flavio Casadei Della Chiesa
Leggi l'articolo completo su flaviocdc.net
Chect then Act, schema di codice nel quale si effettua un controllo prima di eseguire un'azione.

// Check then act
.....
    if (test) {
        azione();
    } else  {
        altraAzione();
    }
.....

utilizzare questo codice in un ambiente concorrente può avere risultati inaspettati. E' infatti possibile che dopo aver eseguito il test la condizione sia cambiata, in questo caso potrebbe venir invocata l'azione sbagliata.

Java Memory Model

2012-01-31T02:02:00.001-08:00

Leggi l'articolo completo su flaviocdc.net

Java Memory Model è il capitolo 17 di Java Language Specification.
Un memory model definisce i possibili scenari e regole che governano più Thread all'interno di uno stesso sistena. In memory model determina se alla JVM è permessa una particolare esecuzione di un programma. Le specifiche Java non forzano le implementazioni delle JVM a seguire qualche particolare regola per l'esecuzione di un programma; questo da agli implementatori della JVM una grande flessibilità spesso utilizzata per permettere al compilatore ottimizzazioni aggressive basate spesso sul riordino delle istruzioni. Comunque sia il memory model di Java spcifica che tutte le implementazioni devono produrre risultati predicibili da parte del programmatore (se vengono da lui/lei seguite certe regole).
Il memory model definisce regole per l'utilizzo dei Thread ed il comportamento atteso di programmi multithread così da permettere agli sviluppatori di impostare di conseguenza i propri programmi. La responsabilità di evitare RaceCondition, deadlock ed altro sta tutta nel lavoro dello sviluppatore.

Triade della morte

2012-01-31T02:01:00.002-08:00

Leggi l'articolo completo su flaviocdc.net

Per “Triade della morte” in ambiente multuthread mi riferisco alle tre maggiori cause di problemi derivanti da una scorretta gestione della concorrenza.
La triade è composta da

RaceCondition
Riordino delle istruzioni da partedi JVM, CPU, Memoria, ….
Problemi di visibilità delle modifiche effettuate da un Thread (Quando il Thread B può vedere il valore corretto della variabile X scritta dal Thread A?)

Il più famoso antipattern nel quale è presente anche se molto nascosta questa triade è il Double checked locking idiom

Put if absent, variante del CheckThenAct

2012-01-31T02:01:00.000-08:00

A cura di Flavio Casadei Della Chiesa
Leggi l'articolo completo su flaviocdc.net

In questo schema si provvede ed inserire un elemento (di solito) in una collezione solo se questa già non lo contiene.

 
// schema generico di put-if-absent
private HashMap<K,V> hm .....
    public void putIfAbsent(K k , V v) {
        if (!hm.containsKey(k)) {
                hm.put(k,v);
        }
    }

i problemi sono i soliti derivanti dal CheckThenAct. Nota, come in tutte le azioni composte non basta limitarsi ad aggiungere un synchronized per risolvere il problema.
Per eliminare ogni sorta di problema è necessario rendere atomica l'operazione. Per far questo solo un Thread deve essere in grado di controllare la presenza o meno della chiave nella mappa e di effettuare un'eventuale sostituzione.
Un esempio di soluzione può essere il seguente nel quale si istanzia una HashMap all'interno di una classe contenitrice

public class InnerPIA<K,V>  {
 private final HashMap<K,V>  delegate = new HashMap<K,V>();
 public synchronized V get(K k)  {return delegate.get(k);}
 public synchronized void put(K k, V v)  { delegate.put(k,v);}
 public synchronized  boolean containsKey(K k) {return delegate.containsKey(k);}
public synchronized void putIfAbsent(K k, V v)  {
 if (!delegate.containsKey(k) {
     delegate.put(k,v);
 }
}
.....
 }

Nel caso in cui la HashMap sia condivisa e non confinata in una classe contenitrice è necessario utilizzare un altro tipo di ClientSideLocking. In questo modo però tutte le classi che condividono la solita istanza della mappa devono utilizzare il solito protocollo.

public class DelegatePIAPIA<K,V>  {
 private final Map<K,V>  delegate ;
 public DelegatePIA(Map<K,V> m) {
  this.delegate = m;
 }
 public  V get(K k)  {
  synchronized(delegate) {
   return delegate.get(k);
  }
 }
 public  void put(K k, V v)  {
  synchronized(delegate) {
   delegate.put(k,v);
  }
 }
 public   boolean containsKey(K k) {
  synchronized(delegate) {
   return delegate.containsKey(k);
  }
 }
public  void putIfAbsent(K k, V v)  {
  synchronized(delegate) {
   if (!delegate.containsKey(k) {
    delegate.put(k,v);
   }
  }
}
.....
 }

In Java5, precisamente nella concurrent API, esiste un modo più immediato: utilizzare una implemantazione di una ConcurrentMap come ad esempio la classe ConcurrentHashMap.
Queste dispongono di un metodo chiamato appunto putIfAbsent la cui firma è simile alla precedente; l'unica differenza è che il metodo non è void ma ritorna n elemento di tipo V. Invocare il metodo

pippo = mappa.putIfAbsent(key,value);

è equivalente a

 if (!mappa.containsKey(key)) 
      return mappa.put(key, value);
   else
      return mappa.get(key);

Se la mappa conteneva un valore precedente per la chiave key il metodo ritorna tale valore, altrimenti restituisce null.

Read Write Lock

2012-01-31T02:00:00.000-08:00

Leggi l'articolo completo su flaviocdc.net
BOZZA! Sono un meccanismo per una gestione ottimale dell'accesso a risorse condivise basato sul principio che se molte azioni possono avvenire senza problemi in modo concorrente e solo poche in modo esclusivo allora non c'è alcuna necessità di forzare un accersso in mutua esclusione alla risorsa condivisa.

Double checked locking idiom

2012-01-31T01:54:00.000-08:00

Leggi l'articolo completo su flaviocdc.net

A cura di Flavio Casadei Della Chiesa

Copyright (c)  2006  Flavio Casadei Della Chiesa.
     è garantito il permesso di copiare, distribuire e/o modificare
     questo documento seguendo i termini della Licenza per
     Documentazione Libera GNU, Versione 1.1 o ogni versione
     successiva pubblicata dalla Free Software Foundation.

Il Double Checked Locking Idiom è uno dei più subdoli Antipattern della programmazione concorrente in Java. A prima vista sembra un utile strumento per migliorare le performance, tuttavia sotto le regole dell'attuale Java Memory Model questo schema non funziona

public class DoubleCheckedLocking {
    private static Resource _instance
    public static Resource getInstance() {
        if (_instance == null) {
            synchronized (DoubleCheckedLocking.class) {
                if (_instance == null)
                    _instance = new Resource();
                }
            }
       }
       return _instance;
    }
}

Inizializzare un oggetto comporta la scrittura di alcune variabili (stato dell'oggetto), pubblicare un oggetto riguarda la scrittura di altre variabili (il reference). Se non si assicura che pubblicare l'oggetto accada prima che un Thread possa leggerne il reference la scrittura del reference può essere riordinata con le scritture dello stato dell'oggetto.
In tale caso un Thread può vedere un valore aggiornato per il reference, ma un valore non aggiornato per alcune delle variabili che compongono lo stato dell'oggetto. Si ottiene quindi il reference ad un oggetto parzialmente costruito.
Senza utilizzare tecniche troppo elaborate e spesso inutili è possibile risolvere il problema con il seguente codice

public class EagerInstantiation {
 private static final Resource _instance = new Resource();
 public static Resource getResource() {
  return _instance; // :-)
 }
}

Alcuni riferimenti

Double Checked Locking Idiom is broken [http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html declaration]
http://www.javaworld.com/jw-02-2001/jw-0209-double.html
http://forum.java.sun.com/thread.jspa?threadID=519106&messageID=2479149
http://www-128.ibm.com/developerworks/java/library/j-dcl.html

Nested Monitor Problem

2012-01-31T01:53:00.001-08:00

Leggi l'articolo completo su flaviocdc.net

' Versione da riguardare '
' A cura di Flavio Casadei Della Chiesa '
Il Nested Monitor Problem (NMP) si ha in genere quando un Thread entrando nella coda di wait di un oggetto “mette a dormire con se” il lock dell'unico oggetto che può “risvegliare” tale Thread tramite una notify*().
In generale è buona norma 'non' mettere un Thread in una coda di wait se non si è sicuri che quancun altro Thread sia in grado di eseguire una notify* su di essa (e quindi liberare i Thread in attesa). A volte nonostante sia stato predisposto un adeguato sistema di metodi di notifica e attesa può accadere che il metodo di notifica non possa essere eseguito in quanto il suo accesso è “sbarrato” da un lock che non potrà mai essere acquisito. Vediamo un esempio di NMP

class Inner {
  protected boolean cond = false;
  public synchronized void await ()   {
    while (!cond)
      try { wait (); }
      catch (InterruptedException e) {}
      // .....
  }
  public synchronized void signal (boolean c)   {
    cond = c;
    notifyAll ();
  }
}
class Outer {
  protected Inner inner_ = new Inner (); // nota! non è accessibile all'esterno
  public synchronized void process ()   {
    inner_.await ();
  }
  public synchronized void set (boolean c)   {
    inner_.signal (c);
  }
}

Nella classe denominata Inner i metodi di attesa e notifica sono giustamente messi pubblici e synchronized; la classe Outer si limita solamente ad utilizzare tali metodi in blocchi sincronizzati al fine di evitare accessi concorrenti. A prima vista sembrerebbe tutto a posto tuttavia in questo frammento di codice si cela un'insidia poco visibile.
Prima di entrare nella coda di wait di un oggetto X, un generico Thread T ne deve acquisire il lock intrinseco (senza se e senza ma), una volta entrato in wait tale lock viene rilasciato e messo a disposizione di altri Thread. Fin qua niente di nuovo, tuttavia se leggiamo attentamente non ho scritto che 'tutti' i lock acquisiti dal Thread T vengono rilasciati; ed infatti solo il lock intrinseco viene rilasciato, gli altri no. Se osserviamo il NMP da vicino si nota che per un Thread T1 che invoca Outer.process() acquisisce ben due lock: quello di Outer e quello di Inner, ma una volta entrato in wait (su inner) il lock di Outer rimane acquisito e non rilasciato. Ogni altro Thread T2 che prova ad invocare Outer.set() rimane bloccato all'infinito in quanto il lock di Outer è in possesso di T1. Non esiste quindi alcun modo per riacquisire il lock di Outer in quanto nessun Thread è in grado di eseguire la notify().
La Nested in Nested Monitor Problem deriva dal fatto che la classe che esegue la wait di norma è una classe interna/annidata della classe che espone i metodi ai client; questa di norma è una buona tecnica di confinamento che limita alcuni problemi di concorrenza anche se, come abbiamo visto, può generare probkemi ben più gravi.

public class Outer {
        protected Nested _nested = new Nested (); // nota! non è accessibile all'esterno
        public synchronized void process ()   {
                _nested.await ();
        }
        public synchronized void set (boolean c)   {
                _nested.signal (c);
        }
        private class Nested {
                protected boolean cond = false;
                public synchronized void await ()   {
                        while (!cond)
                                try { wait (); }
                        catch (InterruptedException e) {}
                        // .....
                }
                public synchronized void signal (boolean c)   {
                        cond = c;
                        notifyAll ();
                }
        }
}

Nested Monitor Solution?

Beh le soluzioni sono molte e non tutte applcabili in ogni contesto. Analizziamo una ipotetica soluzione ne propongo una basata su classi annidate (nested)

public class NestedMonitor {
        private final Nested _nested = new Nested (); // nota! non è accessibile all'esterno
        public  void process ()   {
                _nested.await (); // nessun lock acquisito
        }
        public  void set (boolean c)   {
                _nested.signal (c); // nessun lock acquisito
        }
        private class Nested {
                protected boolean cond = false;
                public synchronized void await ()   {
                        while (!cond)
                                try { wait (); }
                        catch (InterruptedException e) {Thread.currentThread().interrupt(); return ;}
                        // .....
                }
                public synchronized void signal (boolean c)   {
                        cond = c;
                        notifyAll ();
                }
        }
}

Come si nota, la soluzione consiste nel rimuovere la keyword synchronized dai metodi della classe Outer, più qualche “aggiunta” ….. Non si notano a prima vista grossi problemi, ma riflettendo meglio non è esclusa la possibilità di generare il solito problema nel caso in cui una classe cliente tenti un client side locking su una istanza della classe Nestedmonitor.
Attenzione quindi a chiamare metodi “alieni” con un lock acquisito!
Propongo due versioni alternative di una ipotetica soluzione, presto seguiranno commenti … spero pure i vostri! Contattatemi pure all'indirizzo fcasadei CHIOCCIOLA gmail PUNTO com

public class Outer {
        private final Nested _nested = new Nested (); // nota! non è accessibile all'esterno
        private final Object lock = new Object();
        public  void process ()   {
                _nested.await (); // nessun lock acquisito
        }
        public  void set (boolean c)   {
                _nested.signal (c); // nessun lock acquisito
        }
        private class Nested {
                protected boolean cond = false;
                public  void await ()   {
                        synchronized (lock) { //prendo il lock "giusto"
                                while (!cond)
                                        try { lock.wait (); }
                                catch (InterruptedException e) {Thread.currentThread().interrupt(); return ;}
                                // .....
                        }
                }
 
                public  void signal (boolean c)   {
                        synchronized (lock) {
                                cond = c;
                                lock.notifyAll ();
                        }
                }
        }
}

public class NestedOuter {
        private final Nested _nested = new Nested (); // nota! non è accessibile all'esterno
 
        public  void process ()   {
                _nested.await (); // nessun lock acquisito
        }
        public  void set (boolean c)   {
                _nested.signal (c); // nessun lock acquisito
        }
        private class Nested {
                protected boolean cond = false;
                public  void await ()   {
                        synchronized (NestedOuter.this) { //prendo il lock "giusto"
                                while (!cond)
                                        try { NestedOuter.this.wait (); }
                                catch (InterruptedException e) {Thread.currentThread().interrupt(); return ;}
                                // .....
                        }
                }
 
                public  void signal (boolean c)   {
                        synchronized (NestedOuter.this) {
                                cond = c;
                                NestedOuter.this.notifyAll ();
                        }
                }
        }
}

Unsafe lazy instantiation

2012-01-31T01:52:00.002-08:00

Leggi l'articolo completo su flaviocdc.net

In questo Antipattern sono presenti vari problemi, il più ovvio è quello alla creazione di finti Singleton. L'accesso non esclusivo alla getInstance() può favorire la creazione di più istanze differenti della risorsa. Altri e più subdoli problemi sono discussi nel Double checked locking idiom

public class UnsafeLazyInstantiation {
    private static Resource _instance;
    public static Resource getInstance() {
        if (_instance == null)
            _instance = new Resource(); // unsafe publication :-P
        return _instance;
    }
.......
}

La soluzione immediata al problema dei finiti Singleton è la seguente

public class SimpleLazyInstantiation {
    private static Resource _instance;
    public synchronized static Resource getInstance() {
        if (_instance == null)
            _instance = new Resource(); //  sate publication :-|
        return _instance;
    }
.......
}

si nota in fatti che il metodo getInstance() è sincronizzato, non è quindi possibile che due o più Thread vi accedano in contemporanea.
Nonostante il precedente codice sia sicuro può non essere sempre un'ottima cosa sincronizzare il metodo di istanziazione. Java permette il caricamento lazy di una classe tramite il LazyClassLoading utilizzabile tramite gli inizializzatori statici. La versione pulita per l'instanziazione lazy è la seguente

public class EagerInstantiation {
    private static final Resource _instance = new Resource();
    public static Resource getResource() {
        return _instance; // :-)
    }
}

Unsafe Publication

2012-01-31T01:52:00.000-08:00

Unsafe Publication

Pubblicare un oggetto significa renderlo visibile agli altri; pubblicarlo in modo insicuro spesso vuol dire renderne visibile il reference prima che l'oggetto sia completamente costruito.
La pubblicazione di un oggetto comporta la scrittura di una variabile, il reference, la creazione di un oggetto comporta la scrittuta di altre variabili, lo stato dell'oggetto. Se non si ha la garanzia certa che la creazione dell'oggetto preceda la pubblicazione del reference allora e' possible entrare in possesso di un oggetto non perfettamente costruito. Il più celebre esempio di Unsafe Publication derivante da un non corretto ordinamento de eventi è il Double checked locking idiom discusso nella sezione Java, Thread e trabocchetti.

Python Shapefile to CSV converter

2012-01-31T01:48:00.000-08:00

Read the full article at flaviocdc.net

This script exports the data content (tabular data) of a shapefile and the bounding box of every object to csv format

"""
Shapefile export
"""
import shapelib, dbflib, string
 
SHAPEFILE="shpname"
 
shp = shapelib.ShapeFile(SHAPEFILE)
dbf = dbflib.DBFFile(SHAPEFILE)
 
sCount = shp.info()[0]
dCount = dbf.record_count()
 
if sCount <> dCount:
 raise "Error: shape  number %s (%d) differs from  dbf records (%d) " %(SHAPEFILE,sCount,dCount)
 
 
#print l'header!
header = dbf.read_record(0)
#print header.keys()
intestazione = string.join(header.keys(),"|")
intestazione += "|XMIN|YMIN|XMAX|YMAX"
 
print intestazione
 
#read the dbf file 
for i in range (dbf.record_count() ):
 rc = dbf.read_record(i)
 sc = shp.read_object(i)
 row = ""
 for value in rc.values():
  row += "%s|" %(value)
 #print the  extent/envelope
 (min,max) = sc.extents()
 xmin = min[0]
 ymin = min[1]
 xmax = max[0]
 ymax = max[1]
 
 row += "%f|%f|%f|%f" %(xmin,ymin,xmax,ymax)
 print row
 #print "\n"

Banale esempio di utilizzo dell'interfaccia Future

2012-01-20T01:09:00.001-08:00

Esempio future

In questa pagina si vuole descrivere il funzionamento dell'interfaccia 'java.util.concurrent.Future'. Le API Java 5 dicono che un Future rappresenta il risultato di una computazione asincrona, …,

 il risultato può essere recuperato con il metodo get solamente 
quando la computazione è completata, eventualmente bloccando il 
chiamante fino a quando il risultato non è pronto

Esempio

In questo esempio si vogliono testare due processori 'p1' e 'p2' e si da loro da calcolare un risultato. Il testa ha successo se entrambi i processori danno lo stesso risultato altrimenti fallisce. Il calcolo del risultato è piuttosto complesso, si delega quindi ad un esecutore l'esecuzione del calcolo su entrambi i processori e si aspetta che questo abbia finito prima di confrontare i risultati.

'NOTA: l'esempio è assai semplice: non ci sono calcoli complicati, c'è solo un random che può far guastare un processore

 
 
package test.esecutore;
/**
 * Usare solo a scopo didattico!
 */
import java.util.concurrent.Callable;
import java.util.concurrent.Executor;
import java.util.concurrent.FutureTask;
import junit.framework.TestCase;
 
public class TestFuture extends TestCase { 
 //valore atteso dal calcolo
 private static final  Double CLEAN = 1.0;
 //probabilità di successo del primo procesore
 private static final  double okProb1 = 0.6;
 //probabilità di successo del secondo processore
 private static final  double okProb2 = 0.65;
 public void testFoo() throws Exception{
  //Esecutore dei task
  Executor executor = new ThreadPerTaskExecutor();
  //Future del primo processore
  FutureTask<Double> proc1 =
   new FutureTask<Double>(new Callable<Double>() {
    public Double call() throws InterruptedException {
     Double retval = CLEAN;
     double d = Math.random();
     if ( d > okProb1) {
      retval = d;
     }
        Thread.sleep(  (long)Math.floor(d*500 )  );
 
     return retval;
    }});
//  Future del secondo processore
  FutureTask<Double> proc2 =
   new FutureTask<Double>(new Callable<Double>() {
    public Double call() throws InterruptedException {
     Double retval = CLEAN;
     double d = Math.random();
     if ( d > okProb2) {
      retval = d;
     }
     Thread.sleep(  (long)Math.floor(d*500 )  );
     return retval;
    }});
  //eseguo in modo asincrono entrambi i calcoli
  executor.execute(proc1);
  executor.execute(proc2);
  //prendo i risultati
  Double p1 = proc1.get();
  Double p2 = proc2.get();
  // li confronto
  assertEquals(p1, p2);
 }
 
 
 //Semplice esecutore asincrono. Non usare in produzione!!!!!
 class ThreadPerTaskExecutor implements Executor {
  public void execute(Runnable r) {
   new Thread(r).start();
  }
 }
 
 
}

Usare il provider filesystem di JNDI

2012-01-20T01:08:00.001-08:00

nota: questo codice è instabile (alfa) … da notare la necessità di creare le varie directory dell'albero jndi. Nell'esempio viene creata solo la base ma nel caso di alberi più complessi tutte le sottocartelel dovono essere create; chiaramente sto indagando su come fare per ovviare al problema …

package test.jndi;
import java.io.File;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.Reference;
import javax.naming.StringRefAddr;
import test.jndi.mystuff.ClasseInutileFactory;
import junit.framework.TestCase;
 
public class SimpleJndi extends TestCase {
 private static final String JDBC_PIPPO = "data/inutile";
 private static final String PIPPO = "pippo";
 static Hashtable<String,String> props = new Hashtable<String,String>();
 static String dirname = "/tmp/";
 static {
  props.put("java.naming.factory.initial", "com.sun.jndi.fscontext.RefFSContextFactory");
  props.put("java.naming.provider.url", "file://" +
    dirname);
  new File(dirname).mkdirs(); // la directory deve esistere 
 }
        protected void setUp() throws Exception {
  super.setUp();
 }
 protected void tearDown() throws Exception {
  super.tearDown();
 }
 public void testFactory() throws Exception{
  InitialContext ctx = new InitialContext(props);
  Reference ref = new Reference(ClasseInutile.class.getName(),
    ClasseInutileFactory.class.getName(), null);
  ref.add(new StringRefAddr("name", "pippoName"));
  ctx.rebind(PIPPO, ref);
  Context ic2 = new InitialContext(props);
  ClasseInutile ci = (ClasseInutile)ic2.lookup(PIPPO);
  System.out.println(ci);
  ci = (ClasseInutile)ic2.lookup(PIPPO);
  System.out.println(ci);
 }
 public void aatestSimple() throws Exception {
  Context ctx = new InitialContext(props);
  ClasseInutile c = new ClasseInutile();
  c.setName(String.valueOf(Math.random()));
  ctx.rebind(PIPPO,new Reference(c.getClass().getName()));
  ClasseInutile cu = (ClasseInutile)ctx.lookup(PIPPO);
  assertEquals(cu,c);
 }
}

Esportazione di shapefile da python

2012-01-20T01:04:00.001-08:00

Il seguente script esporta in formato “pseudo csv” i dati dello shapefile e la “bounding box” di ogni singola figura censita

"""
Esportazione dei dati di uno shapefile
"""
import shapelib, dbflib, string
 
SHAPEFILE="nomeshp"
 
shp = shapelib.ShapeFile(SHAPEFILE)
dbf = dbflib.DBFFile(SHAPEFILE)
 
sCount = shp.info()[0]
dCount = dbf.record_count()
 
if sCount <> dCount:
 raise "Errore: numero oggeti in shape %s (%d) diverso da record  dbf (%d) " %(SHAPEFILE,sCount,dCount)
 
 
#stampo l'header!
header = dbf.read_record(0)
#print header.keys()
intestazione = string.join(header.keys(),"|")
intestazione += "|XMIN|YMIN|XMAX|YMAX"
 
print intestazione
 
#scandisco riga per riga il file dbf
for i in range (dbf.record_count() ):
 rc = dbf.read_record(i)
 sc = shp.read_object(i)
 row = ""
 for value in rc.values():
  row += "%s|" %(value)
 #aggiungo la extent/envelope
 (min,max) = sc.extents()
 xmin = min[0]
 ymin = min[1]
 xmax = max[0]
 ymax = max[1]
 
 row += "%f|%f|%f|%f" %(xmin,ymin,xmax,ymax)
 print row
 #print "\n"

Introduzione a java e generics parte 3 - Confronti tra element

2012-01-17T08:55:00.000-08:00

PREV Subtyping & wildcards

Parleremo di Comparable<T>

Confrontare elementi
Trovare massimo e minimo in una collezione
Metodi bridge

Comparable

public interface Comparable<T>
{
public int compareTo(T elem);
}

Il metodo compareTo restituisce un valore che è negativo, zero o positivo a seconda che il parametro fornito sia rispettivamente minore, uguale o maggiore del parametro implicito (this). Quando una classe implementa Comparable l'ordine specifcato dalla sua interfaccia è chiamato ordine naturale per la classe.

Mele con mele e pere con pere

Integer i0 = 0;
Integer i1 = 1;
assert i0.compareTo(i1) < 0;
String s0 = "zero";
String s1 = "uno";
assert s0.compareTo(s1) > 0;

(Di norma) un oggetto di una classe può essere confrontato solo con oggetti della stessa classe (pere con pere, mele con mele)

Posso confrontare mele con pere?

Number n1 = 1;
Number npi = 3.14;
assert n1.compareTo(npi) <0; // Errore di compilazione

Notare il boxing
Il codice non compila!
Number non implementa Comparable

Consistente con l'uguaglianza

x.equals(y) ↔ x.compareTo(y) == 0

Attenzione all'inserimento in SortedList ecc …

compareTo VS equals

x.equals(null) → true, false
x.compareTo(null) → NullPointerException

BigDecimal non è consistente con l'uguaglianza

Contratto per comparable

Antisimmetrica
- sgn(x.compareTo(y)) = - sgn(y.compareTo(x))
Transitiva
- x.compareTo(y) < 0 & y.compareTo(z) < 0 → x.compareTo(z) <0
Congruenza
- x.compareTo(y) == 0 → sgn(x.compareTo(z)) == sgn(y.compareTo(z))
Rifessiva
- x.compareTo(x) == 0

sgn(x) è il segno di x: -1 negativo, 0 zero, 1 positivo

Overflow / underflow

Attenzione

public int compareTo(Integer o) {
return this.value - o.value;
}

NO! Può generare overfow: confrontando un numero negativo grande in modulo con un grande numero positivo → Si può superare Integer.MAX_VALUE

Overflow:

Numero troppo grande in valore assoluto Maggiore di Integer.MAX_VALUE o minore di Integer.MIN_VALUE

Underfow:

numero, diverso da zero, troppo piccolo in valore assoluto per essere rappresentato dalla macchina

Trovare il massimo di una collezione

public static <T extends Comparable<T>> T max (Collection<T> coll){
 T cand = coll.iterator().next();
  for (T elem: coll){
  if (cand.compareTo(elem) < 0) cand = elem;
 }
 return cand;
}

Limiti

 <T extends Comparable<T>>

si dice che T è limitato da Comparable T Si è quindi posto un limite sul tipo di T. Il limite può essere ricorsivo

 <T extends C<T,U> , U extends D<T,U>>

Esempi

List<String> stringhe = Arrays.asList("ciao","mondo"); // ok
assert Collections.max(stringhe).equals("mondo" ); // ok 
List<Integer> interi = Arrays.asList(1,2,3); assert Collections.max(interi) == 2; // ok
List<Number> numeri = Arrays.asList(1 ,2 ,3 ,4 ,5 ,3.14); // ok
assert Collections.max(numeri) == 5; // NO! Il codice con compila

E' possibile utilizzare firme il più generiche possibile

public static <T extends Comparable<T>> T max (Collection<T> coll)
 
public static <T extends Comparable<? super T>> T max ( Collection<? extends T > elements)
 
public static <T extends Object & Comparable<? super T>> T max( Collection<? extends T> coll ) {

Limiti multipli

public static <S extends Readable & Closeable,
 T extends Appendable & Closeable>
 void copy(S src, T dest, int dim)throws IOException{
  CharBuffer buff = CharBuffer.allocate(dim);
  int i = src.read(buff);
  while (i >= 0 ){
   buff.flip(); // prepara per la scrittura
   dest.append(buff);
   buff.clear();
   i = src.read(buff);
  }
src.close(); dest.close();
}

Metodi bridge

Generics sono implementati mediante Type erasure

Il bytecode è piuttosto simile (e compatibile) con la versione senza Generics

Classi che implementano interfacce generiche (es: Comparable<T> )

Vengono aggiunti dal compilatore alcuni metodi detti metodi bridge

public class Foo1 implements Comparable {
 private final String value ;
 public Foo1(String value) {
  super();
  this.value = value;
 }
 public int compareTo(Object o) {
  return compareTo((Foo1)o);
 }
 public int compareTo(Foo1 o){
 return value.compareTo(o.value);
 }
}

Esempio di Comparable senza Generics. Il metodo classico chiama il metodo ridefnito dopo un cast (double dispatch). Attenzione! Java supporta il binding dinamico solamente sull'argomento implicito (this) e non sui parametri formali (quelli tra parentesi)

Con i generics

public class Foo2 implements
Comparable<Foo2> {
private final String value;
public Foo2(String value) {
this.value = value;
}
public int compareTo(Foo2 o) {
return value.compareTo(o.value);
}
}

C'è solo un metodo nel codice sorgente Vediamo cosa succede nel bytecode generato dal compilatore …

Bytecode generato con metodo bridge

for (Method m :
Foo2.class.getMethods()){
if (m.getName()
.equals("compareTo")) {
System.out.println(
m.toGenericString());
} }

----------------------
public int Foo2.compareTo(Foo2)
public bridge int Foo2.compareTo(java.lang.Object)

Override covariante (finalmente!)

In java ⇐ 1.4 un metodo può sovrascrivere un altro ↔ le due frme coincidono esattamente.

In java >= 5 un metodo può sovrascrivere un altro se gli argomenti sono identici ed il tipo di ritorno del metodo riscrivente è un sottotipo del tipo di ritorno del metodo riscritto.

Override <= 1.4

public class OldPunto {
private final int x;
private final int y;
public OldPunto(int x, int y) {
this.x = x;
this.y = y;
}
public Object clone() {
return new OldPunto(x, y);

Object ha un metodo clone() che restituisce un Object

Override >= 5.0

public class NewPunto {
private final int x;
private final int y;
public NewPunto(int x, int y) {
this.x = x;
this.y = y;
}
public NewPunto clone() {
return new NewPunto(x, y);
}
}

NewPunto è sottotipo di Object quindi non ci sono errori di compilazione

Vediamo se ci sono dei bridge:

public NewPunto NewPunto.clone()
public bridge java.lang.Object NewPunto.clone() throws java.lang.CloneNotSupportedException

Ancora sui bridge

A seconda del compilatore la dicitura bridge:

Può non comparire!
Può essere sostituita da volatile! (bug)
Altro …
Nel compilatore java6 di Apple non compare bridge

Python Shapefile to CSV converter

2012-01-17T02:06:00.000-08:00

This script exports the data content (tabular data) of a shapefile and the bounding box of every object to csv format

"""
Shapefile export
"""
import shapelib, dbflib, string
 
SHAPEFILE="shpname"
 
shp = shapelib.ShapeFile(SHAPEFILE)
dbf = dbflib.DBFFile(SHAPEFILE)
 
sCount = shp.info()[0]
dCount = dbf.record_count()
 
if sCount <> dCount:
 raise "Error: shape  number %s (%d) differs from  dbf records (%d) " %(SHAPEFILE,sCount,dCount)
 
 
#print l'header!
header = dbf.read_record(0)
#print header.keys()
intestazione = string.join(header.keys(),"|")
intestazione += "|XMIN|YMIN|XMAX|YMAX"
 
print intestazione
 
#read the dbf file 
for i in range (dbf.record_count() ):
 rc = dbf.read_record(i)
 sc = shp.read_object(i)
 row = ""
 for value in rc.values():
  row += "%s|" %(value)
 #print the  extent/envelope
 (min,max) = sc.extents()
 xmin = min[0]
 ymin = min[1]
 xmax = max[0]
 ymax = max[1]
 
 row += "%f|%f|%f|%f" %(xmin,ymin,xmax,ymax)
 print row
 #print "\n"

Introduzione a java e generics parte 2 - Subtyping & wildcard

2012-01-16T12:34:00.000-08:00

Leggi l'articolo aggiornato sul mio sito

In Java un tipo A è un sottotipo di un altro tipo B se questi sono legati da una clausola extends o implements

A extends B o A implements B

(Integer è sottotipo di Number, List<E> è sottotipo di Collection<E>)
 
Subtyping è riflessiva e transitiva:
 
//Se A è sottotipo di B allora B è supertipo di A//
 
Ogni tipo reference è sottotipo di Object ed Object è supertipo di ogni reference type

Principio di sostituzione

interface Collection<E>{
...
public boolean add(E elem);
...
}

Principio di sostituzione: possiamo aggiungere Integer e Double a collezioni di Numbers (Integer e Double sono sottotipi di Number)

List<Number> numeri = new
 ArrayList<Number>();
numeri.add(2);
 
numeri.add(3.14);
assert
   numeri.toString().equals(
    "[2, 3.14]");

OK List<Number> è sottotipo di Collection<Number>
OK 2 ha tipo* Integer che è sottotipo di Number
OK 3.14 ha tipo* Double che è sottotipo di Number
Per ora tutto OK

Eccoci al dunque …

Wildcard con extends

interface Collection<E>{
...
public boolean addAll(
  Collection<? extends E> c);
...
}

OK, posso inserire in una collezione di tipo E elementi di tipo E
? extends E → OK, posso inserire in una collezione di tipo E elementi appartenenti ad una collezione di qualsiasi sottotipo di E

List<Number> numeri = new ArrayList<Number>();
List<Integer> interi = Arrays.asList(1,2);
List<Double> doubles = Arrays.asList(2.78,3.14);
numeri.addAll(interi);
numeri.addAll(doubles)

OK Integer e Double sono sottotipi di Number
List<Integer> è sottotipo di List<? extends Number> (idem per Double)

List<Integer> interi = Arrays.asList(1,2);
List<? extends Number> numeri = interi;
numeri.ADD(3.14); // → Errore di compilazione
assert interi.toString().equals(
   "[1, 2, 3.14]");

List<? extends Number> può essere una lista di qualsiasi tipo di numero! Non è detto che sia una lista di Double!

wildcard con super

public static <T> void copia(List<? super T> dest, List<? extends T> src){
 for (int i=0; i < src.size(); i++) {
 
   dest.set(i,src.get(i)); // ← Attenzione
 }
}

? super T → lista destinazione di supertipo di T

List<Object> oggetti = Arrays.<Object>asList(2,3.14,"four");
List<Integer> interi = Arrays.asList(5,6);
Collections.copia(oggetti, interi);
assert oggetti.toString().equals("[5, 6, four]");

Get and Put Principle

GET: Utilizzare il wildcard extends quando si deve solamente recuperare valori da una struttura
PUT: Utilizzare il wildcard super quando si deve solamente inserire dati in una struttura
GET and PUT: Non utilizzare i wildcard quando si deve sia prendere che inserire

Eccezioni al Get/Put principle

? extends E → è possibile inserire null
? super T → è possibile prelevare Object

Sporco trucco di programmazione

public void rebox(
   Box<? extends Object> box) {
    reboxHelper(box);
}
private static <V> void reboxHelper(Box<V> box) {
    box.put(box.get());
}

Viene effettuata una chiamata ad un “helper” senza wildcard

Array

Il subtyping degli array in java è covariante: S sottotipo di T → S[] sottotipo di T[] Il codice seguente viene compilato

Integer[] interi = 
   new Integer[] {1,2,3};
Number[] numeri = interi;
numeri[2] = 3.14; // --> oops

ma attenzione che a runtime viene lanciato un errore

Exception in thread "main"
java.lang.ArrayStoreException: java.lang.Double
// numeri--> 1 2 3.14

Passiamo adesso ai generics

List<Integer>  interi= Arrays.asList(1,2,3);
List<Number> numeri = interi; → non compila!
numeri.add(3.14);

il codice non compila il Subtyping per i generics è controvariante: S supertipo di T → List<S> è sottotipo di List <? super T>

Covariante

   
   S        ----- extends -----> T
   S[]      ----- extends -----> T[]

   String   ----- extends -----> Object
   String[] ----- extends -----> Object[]

Controvariante

     S                ----- extends -----> T
     List<T>          ----- extends -----> List <? super S>

     String           ----- extends -----> Object
     List<Object>     ----- extends -----> List<? super String>

Cattura del wildcard

Quando viene invocato un metodo generico il parametro di tipo deve essere scelto in modo da “combaciare” con il tipo rappresentato dal wildcard → wildcard capture

public static  <T>  void reverse(List<T> list)
public static void reverse(List<?> list)

<?> è un sinonimo di <? extends Object>

public static  <T>  void reverse(List<T> list){
List<T> tmp = new ArrayList<T>(list);
for (int i = 0 ; i < list.size() ; i++){
list.set(i, tmp.get(list.size() -i - 1) );
}
}

il seguente codice non compila

public static void reverse(List<?> list){
List<Object> tmp = new ArrayList<Object>(list);
for (int i = 0 ; i < list.size() ; i++){
list.set(i, tmp.get(list.size() -i - 1) );
}
}

errore di compilazione

The method set(int, capture#3-of ?) in the type List<capture#3-of ?> is not applicable for the arguments (int, Object)

Restrizioni del wildcard

Creazione dell'istanza
Chiamata a metodo generico
Supertipo

Creazione dell'istanza

List<?> l = new ArrayList<?>();
   NO! Errore di compilazione
 
List<? super Number >  s = new ArrayList<Number>(); 
  OK

Chiamata a metodo generico

public class Lista {
public static <T> List<T>factory() { return new ArrayList<T>(); }
} .. OK
List<?> l = Lista.factory(); OK
List<?> l2 = Lista.<Object>factory(); OK
List<?> l3 = Lista.<?>factory(); → ERRORE
List<?> l4 = Lista.<List<?>>factory(); OK

Supertipo

Class Lista extends ArrayList<?> {…} → NO
Class Lista2 implements List<?> {…} → NO
Class List3  implements  ArrayList<List<?>> {…} → OK

Introduzione a java generics Parte 1 - Alcune novità rispetto a java 1.4

2012-01-16T12:17:00.000-08:00

Pagina in costruzione. Questa pagina è una rielaborazione, fatta prevalentemente di copia&incolla, delle slide relative ai generics disponibili sulla pagina dedicata.

Leggi l'articolo aggiornato sul mio sito

Cominciamo

Generics e Collections vanno a braccetto con altre nuove feature (introdotte da Java5):

boxing e unboxing;
nuovo ciclo for;
funzioni che accettano un numero variabile di argomenti.

La loro combinazione è sinergica: l'intero è maggiore della somma delle parti!

Versione "cool"

List<Integer> ints = Arrays.asList(1,2,3);
int s = 0;
for (int n : ints) {
s += n;
}
assert s == 6;

Probabilmente il codice è comprensibile anche senza alcuna spiegazione …

List<Integer> ints =
Arrays.asList(1,2,3);

List ed ArrayList sono parte del CollectionFramework. List è generico: è possibile scrivere List<E> per indicare liste contenenti elementi di tipo E. List<Integer> indica liste contenenti elementi di tipo Integer.
Boxing ed unboxing automagicamente applicati.
Il metodo statico Arrays.asList prende un numero variabile di argomenti.

for (int n : ints) {
s += n;
}

Ciclo foreach: permette di associare ad una variabile i valori contenuti in un oggetto iterabile. Ad ogni iterazione si prende l'elemento successivo

assert s == 6;

Lo statement assert permette di controllare che l'asserzione fatta sia corretta …
- Asserzione vera
- AssertionError
- … disabilitate di default …

Versione old fashion

List ints = Arrays.asList(new Integer [] {
new Integer(1),
new Integer(2),
new Integer(3) }
);
int s = 0 ;
for (Iterator it = ints.iterator() ; it.hasNext() ; ){
int n = ((Integer)it.next()).intValue();
s += n;
}
assert(s == 6);

Il precedente codice è meno leggibile del primo
Senza i generics non è possibile indicare che tipo di elementi vogliamo inserire nella lista sono necessari dei cast
Senza boxing ed unboxing è necessario eseguire manualmente la conversione esempio: .intValue()
Senza funzioni ad argomenti variabili è necessario passare alla asList un array “preimpostato”
Senza il ciclo foreach è necessario istanziare un iteratore per scandire la lista
.. Si c'è anche un altro modo …

Generics: Base

Una classe o interfaccia può dichiarare di ricevere uno o più parametri di tipo:

Sono scritti tra parentesi angolate (<T>)
I tipi attuali devono essere forniti
- quando si dichiara una variabile
- quando si istanzia un oggetto

List <String> words = new ArrayList<String>();
words.add("Hello ");
words.add("world !");
String s = words.get(0) + words.get(1);
assert s.equals("Hello world !");

La classe ArrayList<E> implementa l'interfaccia List<E>
words è una lista contenente stringhe
Vengono inserite due stringhe e successivamente vengono recuperate
… tutto senza cast!

Codice senza l'ausilio dei generics …

List words = new ArrayList();
words.ADD("Hello ");
words.ADD("world !");
String s = (String)words.get(0) + (String)words.get(1);
assert s.equals("Hello world !");

Type erasure

Il bytecode compilato dei due precedenti esempi è (grossomodo) identico → retro compatibilità. I generics sono implementati tramite la type erasure

compile time	run time
List<Integer>	List
List<String>	List
List<List<String»	List
…	…

I generics eseguono implicitamente il cast che deve essere esplicitato nella versione senza generics

Cast-iron guarantee: I cast impliciti aggiunti dalla compilazione dei generics non falliscono mai!(*) (*) si applica esclusivamente al caso in cui non vengano inviati dal compilatore dei “unchecked warnings”

Type erasure, come mai?

Semplicità → il bytecode è identico
Dimensioni → c'è solo una classe List
Evoluzione → il bytecode (*) è retro compatibile e le librerie con e senza generics possono coesistere
E' possibile evolvere il proprio codice “con calma e con pazienza”
(*) Solo se ricompilato per versioni vecchie di java

Generics VS C++ Template

Java	C++
List<List<String»	List< List<String> > (con lo spazio!)
Type erasure: una sola versione della classe	Expansion: n versioni della solita classe; una per ogni tipo definito a compile-time → code bloat (?ottimizzazioni?)

Tipi reference

Classi
Istanze
Array (tutti)
Possono assumere il valore null
Sono tutti fgli di Object

Tipi primitivi

8 tipi primitivi hanno un corrispondente “tipo reference” nel package java.lang

Primitivo	Reference
byte	Byte
short	Short
int	Integer
long	Long
float	Float
double	Double
bool	Boolean
char	Character

Boxing e unboxing

Boxing → conversione da primitivo a reference

Unboxing → conversione da reference a primitivo

La conversione viene fatta in automatico

int e → new Integer(e) // boxing
Integer e → e.intValue() // unboxing

Esempi

// OK
public static int somma(List<Integer> ints){
int s = 0;
for ( int n :ints) { s += n ; }
return s;
}
//Troppe conversioni! Performance :-(
public static Integer sommaInteger(List<Integer> ints)
{
Integer s = 0;
for ( int n :ints) { s += n ; }
return s;
}

Binary Numeric Promotion

Se uno degli operandi è un reference type viene applicato l'unboxing. Poi

Se uno degli operandi è double anche l'altro viene promosso a double
Se uno degli operandi è foat anche l'altro viene promosso a foat
Se uno degli operandi è long anche l'altro viene promosso a long
Altrimenti entrambi vengono promossi a int

Si applica a vari operatori binari ( tra cui == )

Pericolo boxing/uboxing

Per i primitivi == signifca “uguaglianza dei valori”

Per i reference == signifca “stessa identità”

L ist<Integer> bigs =
Arrays.asList(100,200,300);
assert sommaInteger(bigs) == somma(bigs);
assert sommaInteger(bigs) !=
sommaInteger(bigs); // non raccomandato

I generics funzionano solo con i reference

Interi da -128 a 127, caratteri da 0 a \u007f, Byte e Boolean possono essere cachati

List<Integer> smalls = Arrays.asList(1,2,3);
assert sommaInteger(smalls)
  == somma(smalls);// 6
assert sommaInteger(smalls)
  == sommaInteger(smalls); // 6, non raccomandato

Posso assegnare null ad un primitivo? → NO

Due paroline sul ciclo foreach

For (Pippo p: pippi) …

Applicabile a istanze di java.lang.Iterable<T>
Applicabile ad array[]
Esegue in automatico eventuali boxing ed unboxing

int[] ints = {1,2,3,4};
for (Integer i :ints)
System.out.println(i);

Metodi generici

class Lists {
public static <T> List<T> toList(T[] arr){
List<T> list = new ArrayList<T>();
for (T elem: arr) list.add(elem);
return list;
}
...

Il metodo toList accetta un array di tipo T[] e ritorna un List<T> per ogni tipo T
Si deve indicare <T> all'inizio della frma del metodo statico
T è un parametro di tipo
Ogni metodo che dichiara un parametro di tipo è un metodo generico

List<Integer> ints = Lists.toList(
new Integer[] {1,2,3});
List<String> strings = Lists.toList(
new String[] {"ciao","mondo"});

Boxing e unboxing gratuiti!

Varargs

Che noia inserire gli elementi nell'array!

public static <T> List<T> toList(T ... arr){
List<T> list = new ArrayList<T>();
for (T elem: arr) list.add(elem);
return list;
}
...
List<Integer> ints = Lists.toList( 1,2,2);
List<String> strings = Lists.toList( "ciao","mondo");

Abbiamo sostituito

T[] con T …
L'array[] con valori separati da virgola

Qualsiasi numero di argomenti può precedere il vararg, niente deve seguire il vararg

Attenzione! Il tipo T non viene sempre dedotto dal compilatore, a volte è necessario esplicitarlo

Lists.<Object>toList( 1,"mondo");

Non è detto che Integer e String abbiano in comune solo Object! (Serializable, Comprarable, …)

Asserzioni

Possono essere abilitate tramite i fag della JVM -ea o -enableassertions Altrimenti stanno a dormire …