Guida Java 6: Annotations, StringBuilder, JAXP e Jconsole
In questa nuova guida di Java tratteremo diversi argomenti in modo esauriente e approfondito, suddividendoli in capitoli per facilitarne la comprensione.
Nel primo capitolo tratteremo i seguenti argomenti: Introduzione a Java Annotations; Tipi di Annotations; Creare e utilizzare nuove annotazioni; Estensione del Collection Framework; Import statici; Override del tipo di ritorno; StringBuilder; Formatter, formattazione del testo.
Nel secondo capitolo parleremo di: Array, Queue e typed collections; JAXP processare un documento XML; Reflection; Collection thread safe; Gestione delle eccezioni a Runtime e Gestione delle code.
Nel terzo e ultimo capitolo di questa guida parleremo di: Programmazione concorrente; Callable; Future e Future Task; Semaphore; Locking; Performance; Jconsole; Generazione dinamica proxy RMI.
Ricordiamo che questa guida è il seguito della precedente —> Guida Java: Interfacce funzionali, costruttori, espressioni Lambda e Streams dove abbiamo trattato: le interfacce funzionali in Java; i metodi e i costruttori in Java; la keyword :: in Java; introduzione alle espressioni Lambda; Stream e Lambda Expression in Java; Parallel programming: Fork/Join framework, in particolare spiegheremo: Sequential vs Parallel programming; Stream in Java: aspetti avanzati; Fork/Join Framework; implementare un algoritmo con il framework Fork-Join.
INTRODUZIONE A JAVA ANNOTATIONS
Possiamo definire un’annotation come un appunto che mettiamo per specificare qualcosa relativo al codice che stiamo scrivendo, un attributo particolare, un metodo o una classe che hanno delle peculiarità. Attraverso questo meccanismo siamo capaci di dare espressività al codice, di renderlo più leggibile agli occhi di altri sviluppatori ma soprattutto agli occhi del compilatore.
Le annotations, infatti, sono delle annotazioni per il compilatore (o per chi si occupa del deploy dell’applicazione) che, attraverso di esse avrà la possibilità di effettuare determinate operazioni.
Questo paradigma, oltre a rendere più espressivo il codice sorgente, permette una migliore manutenzione dello stesso. Utilizzando le opportune annotations, infatti, riusciremo ad evitare possibili errori di compilazione, oppure, meglio ancora, potremo delegare a strumenti esterni la configurazione dell’applicazione che stiamo scrivendo (nell’ultima parte dell’articolo vedremo le annotations in ambiente enterprise).
La stessa Sun definisce gli usi delle annotazioni come di seguito:
- Per informare il compilatore,
- Per processare a tempo di compilazione (o di deploy),
- Per processare a run time.
Le ultime due caratteristiche sono tipiche degli ambienti enterprise, che le possono utilizzare mediante reflection.
Annotazioni previste da JDK 1.5
Un’annotazione si presenta nella seguente forma:
@Autore(
name = “Pasquale Congiustì”,
company = “HTML.it”
)
class ClasseAnnotata() {
…
}
Ogni annotazione si presenta con il simbolo @ seguito dal nome dell’annotazione. Eventualmente può essere valorizzata con dei valori, tra parentesi tonde come coppia nome-valore. Essa precede la classe, il metodo o l’attributo che vogliamo annotare.
In questo esempio abbiamo annotato la classe con l’annotation Autore ed i due attributi name e company.
Nel prossimo capitolo vediamo le Annotations di default, fornite a partire dalla distribuzione J2SE 1.5. Si tratta di tre semplici annotazioni utili al compilatore.
Attenzione: utilizzare le annotazioni significherà che il codice non può essere compilato (e spesso anche eseguito) con versioni Java precedenti.
TIPI DI ANNOTATIONS
@Deprecated
L’annotazione @Deprecated viene utilizzata per specificare che l’elemento indicato è un elemento deprecato, cioè, attivo (per mantenere retrocompatibilità) ma non consigliato perché rimpiazzato da uno nuovo e supportato.
Esempio con un annotazione @Deprecated:
public class TestDeprecated {
@Deprecated
public void metodoA() {
System.out.println(“Questo metodo è DEPRECATO, usa metodoB().”);
}
public void metodoB() {
System.out.println(“Questo metodo è SUPPORTATO.”);
}
}
La compilazione di questa classe non darà alcun segnale, procederà tutto normalmente. Sarà la compilazione della classe che userà TestDeprecated a ricevere segnalazioni di warning dal compilatore quando viene utilizzato il metodo metodoA().
TestDeprecated td=new TestDeprecated();
Td.metodoA();
@Override
L’annotation @Override è probabilmente la più utile in quanto consente di evitare degli errori, che in fase di codifica spesso accadono. L’annotazione dice che l’elemento indicato è un elemento che fa l’override (sovrascrive) del relativo elemento, del genitore da cui eredita.
L’esempio ci permetterà di capire meglio.
Esempio di Override:
class A{
void metodo1(){
System.out.println(“Metodo 1”);
}
}
class B extends A{
@Override
void metodoo1(){
System.out.println(“Override A.metodo1()”);
}
}
Abbiamo la classe genitore A, che presenta un metodo, metodo1(). Creiamo una classe B, erede di A. Vogliamo fare l’override di metodo1(), quindi annotiamo il metodo presente nella classe B con l’annotazione @Override, indicando che il metodo annotato è un metodo che sovrascrive un metodo del genitore.
Se provate a compilare il codice, il compilatore vi restituirà un errore. Se notate, infatti, ho inserito un errore di battitura nel nome del metodo. Senza l’annotazione @Override la compilazione sarebbe andata a buon fine e non ci saremmo accorti dell’errore.
@SuppressWarning
L’annotazione @SuppressWarning è utile quando vogliamo sopprimere le indicazioni di warning da parte del compilatore, ad esempio, perché stiamo usando dei metodi deprecati.
Esempio di SuppressWarning:
@SuppressWarnings({“deprecation”})
public void usaMetodoDeprecato() {
TestDeprecated t = new TestDeprecated();
t.metodoA();
}
Pur usando dei metodi deprecated, al compilatore abbiamo segnalato di sopprimere i warning.
CREARE E UTILIZZARE NUOVE ANNOTAZIONI
Le annotazioni di default sono di sicuro interesse, in quanto permettono di migliorare alcuni aspetti nelle fasi di compilazione, facendo sì che lo sviluppatore possa fare a meno di preoccuparsi di alcuni potenziali errori di codifica.
JDK 5 permette allo sviluppatore di definire delle proprie annotazioni totalmente customizzabili. Si tratta semplicemente di definire il nome dell’annotazione e di alcune proprietà che la contraddistinguono.
La cosa che rende le annotations uno strumento davvero importante, tanto da alterare il tipico paradigma di programmazione, è la possibilità di effettuare introspezione del codice.
Con la reflection (vedi guida precedente) è possibile valutare a runtime quali annotations sono presenti (e quali valori hanno in esse) e quindi effettuare determinate operazioni. Possiamo pensare ad un framework che gestica la persistenza con un database, dove all’interno del codice sono presenti delle annotations che indicano come mappare attributi di classe su colonne di database. Oppure utilizzare uno strumento personalizzato per team di sviluppo per commentare opportunamente il codice, chi ne modifica i metodi, chi li crea e quando e così via, per mantenere traccia del lavoro svolto.
Per un esempio pratico sulla creazione delle Java Annotations, rimandiamo all’articolo dedicato, che sicuramente tratta meglio della guida l’argomento.
Dove usare le annotazioni
È chiaro come l’utilizzo opportuno di annotation sia capace di dare tanta espressività in più al codice prodotto. Il reale vantaggio che si ha è quando tale strumento viene affiancato da altri strumenti che fanno introspezione del codice e, in base ad esso, creano delle configurazioni per framework.
È proprio in queste situazioni, infatti, che le annotations hanno un notevole vantaggio. Prima citavamo il framework per la persistenza automatizzata, è il caso di Hibernate, che permette di mappare classi e tabelle attraverso descrittori XML. Ora, attraverso l’uso di annotation, non sarà più necessario creare dei descrittori di configurazione, bensì, adottare delle annotazioni che suggeriscano l’associazione direttamente all’interno del codice.
Mantenere descrittori di configurazione opportunamente allineati può essere un problema, in quanto si tratta di file esterni (generalmente XML), difficilmente leggibili dall’occhio umano.
È il caso anche degli EJB 3.0 che, dalle annotazioni, traggono un notevole vantaggio, rendendo più veloce e meno incline ad errori la produzioni di logica applicativa enterprise.
ESTENSIONE DEL COLLECTION FRAMEWORK
Nel precedente capitolo abbiamo visto come poter utilizzare il nuovo Collection Framework con i Generics associati. Vedremo in questo capitolo come creare una nostra classe che accetti Generics Type. Prima di fare ciò, vediamo però come si presenta l’interfaccia Collection a partire dalla versione jdk 1.5:
Esempio di Interfaccia Collection:
package java.util;
public interface Collection<E> extends Iterable<E> {
//..
Iterator<E> iterator();
<T> T[] toArray(T[] a);
boolean add(E e);
boolean containsAll(Collection<?> c);
boolean addAll(Collection<? extends E> c);
boolean removeAll(Collection<?> c);
boolean retainAll(Collection<?> c);
}
Abbiamo riportato solo i metodi che sono stati modificati dopo l’introduzione dei Generics. Per prima cosa vediamo come l’interfaccia faccia riferimento al parametro <E> quando viene definita; lo stesso dicasi dell’interfaccia Iterable<E> che estende (vedremo il suo uso nel ciclo for-each).
In questo modo si sta informando il compilatore che la classe utilizzerà un parametro di un tipo generico che, d’ora in poi (nei metodi e nel body della classe o interfaccia), verrà riferito come E. Ovviamente si sarebbe potuto utilizzare qualsiasi altro marker per definire il parametro, qui hanno scelto E (ed anche T più avanti nel codice) per definire tipi di cui necessitiamo astrazione (che verranno scelti dallo sviluppatore che utilizzerà questa classe).
Altra cosa che ci rimane da capire è <? extends E>. Il significato è intuitivo comprenderlo: accetteremo parametri che estendono dalla classe E.
L’esempio ci chiarisce:
Esempio di utilizzo delle Collection:
Collection<Number> list = null;
Collection<Double> ld = null;
//…
list.addAll(ld);
Accettiamo come parametro solo una collezione, il cui tipo estende quello definito per la collezione stessa in fase di scrittura del codice (E = Number, quindi accettiamo solo tipi che estendono Number).
A questo punto siamo pronti per definire la nostra struttura dati Generics. Non ci inventiamo nulla per non complicare troppo la comprensione dell’argomento. Creiamo una pila che accetti solo tipi numerici (classe Number) e derivati (tutte le classi wrapper).
Esempio di una struttura Generics:
package it.html.generics;
import java.util.Iterator;
import java.util.Stack;
public class Pila<N extends Number> implements Iterable<N>{
private Stack<N> list;
public Pila(){
list=new Stack<N>();
}
public void add(N element){
list.push(element);
}
public N remove(){
return list.pop();
}
boolean isEmpty(){
return list.isEmpty();
}
@Override
public Iterator<N> iterator() {
return list.iterator();
}
}
Definiamo la classe preoccupandoci di implementare l’interfaccia Iterable. Per non complicarci la vita con l’implementazione utilizziamo la classe Stack già fornita da java (definendo il parametro da utilizzare N, che comunque non conosciamo). Siccome vogliamo che N sia un numero definiamo la sua estensione dalla classe Number.
Codifichiamo quindi i metodi add e remove utilizzando come parametro N, che dinamicamente sarà scelto da chi utilizzerà questa classe. Infine implementiamo iterator() aggiungendo l’annotazione @Override per essere sicuri di sovrascrivere il metodo corretto.
Utilizza la pila vista in precedenza:
public static void main(String[] args) {
Pila<Integer> p2=new Pila<Integer>();
for(int i=0;i<50;i++){
p2.add(i);
}
//..
while(!p2.isEmpty()){
System.out.println(p2.remove());
}
//..
}
Lo spezzone di codice sopra effettua un semplice uso della pila, utilizzando i metodi add e remove. All’inizio definiamo il tipo, Integer (che estende Number) e dopo dovremo utilizzare solo tipi Integer. Nel primo for, per autoboxing, gli int vengono trasformati in Integer, nel while li stampiamo a video.
Come abbiamo visto, la definizione di Generics è piuttosto semplice e risulta davvero importante, soprattutto una volta che diventerà naturale utilizzarle. Quello che dobbiamo sottolineare è come a livello di bytecode non cambi assolutamente nulla. Quello che cambia è dare un indicazione al compilatore per effettuare dei controlli sui tipi e quindi evitare tanti possibili eccezioni di casting durante l’esecuzione, errori che altrimenti avremmo incontrato solo durante l’esecuzione del programma.
IMPORT STATICI
OVERRIDE DEL TIPO DI RITORNO
STRING-BUILDER
FORMATTER: FORMATTAZIONE DEL TESTO
Uno dei problemi che spesso gli sviluppatori hanno è quello relativo alla gestione della formattazione del testo. Infatti, come sappiamo, la rappresentazione può differire in base alle diverse esigenze che possiamo avere nello sviluppo di un programma.
Seppure banali e ripetitive, queste situazioni, quando si manifestano, mettono a dura prova il miglior programmatore. Altro problema è legato al fatto che, non utilizzando una modalità standard, siamo costretti ogni volta a reinventare la stessa soluzione da zero.
java.util.Format è l’implementazione base che si incarica di gestire gli aspetti di conversione e rappresentazione, anche se spesso vedremo che non la utilizzeremo direttamente.
Primi esempi di formattazione del testo:
import java.util.Date;
import java.util.Formatter;
public class FormatterTest {
public static void main(String[] args) {
String name = “Pasquale”;
Date today = new Date();
double cifra=12.332334;
//Creiamo un oggetto formatter
Formatter formatter = new Formatter ();
formatter.format(“Buongiorno %s, sono le %tT”, name, today);
System.out.println(formatter);
Possiamo creare una nuova istanza della classe e, attraverso il metodo format, effettuare la formattazione desiderata. Il metodo format() si aspetta una stringa e zero o n Objects (in modo da poter formattare un numero indefinito di parametri).
La notazione da usare è un segno di percentuale seguito da una serie di caratteri con cui diciamo al metodo come formattare. In questo caso stiamo formattando una stringa (%s) e una data (%T). La sintassi è piuttosto vasta ed è perfettamente spiegata nella documentazione delle API della classe. Proseguiamo con l’esempio:
//Usiamo in metodo format
System.out.format(“Buongiorno %s, sono le %tT”, name, today);
//Usiamo il metodo printf sullo stream out
System.out.printf(“nBuongiorno %s, sono le %tT”, name, today);
//Formattiamo una cifra
System.out.printf(“nCiao %s, stampo la cifra %.2f con 2 cifre decimali”, name, cifra );
//Possibilità di definire l’ordine dei parametri e di stamparli n volte
System.out.printf(“nCiao %2$2s, stampo la cifra %1$2.2f con 2 cifre decimali.” +
” Adios %2$2s”, cifra, name );
}
}
Come dicevamo precedentemente possiamo utilizzare diversi modi per scrivere la rappresentazione su un flusso di output. Infatti utilizziamo gli stessi parametri sul metodo format() di System.out. Questo perché all’interno verrà usata la classe Format.
Nell’esempio vediamo come sia possibile utilizzare il metodo printf() sulla variabile System.out. Gli esempi ci mostrano poi come poter formattare un decimale, troncando le cifre dopo la seconda e infine come sia possibile ordinare e utilizzare i parametri nella rappresentazione testuale.
Fino alla versione 1.4 di Java, a partire dall’oggetto System.in (InputStream), dovevamo costruirci la nostra rappresentazione utilizzando dei filtri (InputStreamReader, BufferedReader, …) ed effettuando gli opportuni controlli.
Java 1.5 presenta un’utilissima classe che già porta con sé tutti i metodi per la lettura e la conversione dei tipi (numerici o stringhe): java.util.Scanner.
Questa classe presenta una lunga serie di metodi, attraverso i quali possiamo gestire un input testuale in maniera ottimale senza preoccuparci delle tipiche operazioni di conversione (ad esempio facendo controlli sui tipi). Inoltre, utilizzando le Regular Expression, è possibile già definire il comportamento, quindi ad esempio stabilire delimitatori di testo in modo da recuperare solo quello di cui abbiamo bisogno.
L’esempio sotto è un programmino che chiede all’utente di digitare il nome del file da visualizzare e dopo legge il file mostrandolo all’utente.
Esempio di lettura di un parametro e di un file:
import java.io.File;
import java.io.FileNotFoundException;
import java.util.Scanner;
public class TestScanner {
public static void main(String[] args) throws FileNotFoundException {
System.out.println(“Insert file name>>”);
Scanner scan=new Scanner(System.in);
String fileName=scan.next();
System.out.println(“Reading “+fileName);
printToScreen(fileName);
}
Nel main effettuiamo la prima richiesta creando un oggetto Scanner costruito con l’InputStream di default (la console). Ovviamente qui sarà possabile montare tutti i filtri immaginabili (per bufferizzare, cifrare, …). Segue la richiesta con il metodo next() che legge un insieme di caratteri (inseriti dall’utente) e ne restituisce una stringa, dopodiché chiamiamo la routine printToScreen(...) passando proprio tale valore.
Prima di proseguire diciamo che è molto interessante l’insieme di metodi esposto dalla classe Scanner. esistono i metodi nextInt(), nextDouble() che si occupano di convertire il valore passato dall’utente in tipo numerico. Questi metodi vanno di pari passo con il rispettivo metodo di controllo hasNext() che restituisce un boolean dicendoci se esiste o meno il prossimo token (quindi avremo anche hasNextInt(), hasNextDouble(), ecc).
Bisogna utilizzare sempre i metodi nextXXX() in coppia con hasNextXXX() perché la conversione può facilmente causare eccezioni a runtime in base al valore che la classe cerca di convertire.
Seguiamo e vediamo come si presenta il metodo utilizzato per leggere il file (e stamparne il contenuto):
private static void printToScreen(String fileName) throws FileNotFoundException {
Scanner scan=new Scanner(new File(fileName));
while(scan.hasNext()){
String tmp=scan.next();
System.out.println(tmp);
}
}
}
All’interno del metodo creiamo un nuovo Scanner passando al costruttore un file. Effettuiamo poi un’iterazione e stampiamo il contenuto di ogni token. Abbiamo visto che uno Scanner presenta una facile interfaccia per interrogare uno stream di input. Vediamo ora un interessante metodo per effettuare la lettura di una pagina Web in maniera identica alla lettura di un file:
Lettura di una pagina Web:
private static void printURL() throws Exception {
URL url = new URL (“http://www.html.it/”);
Scanner scan=new Scanner(url.openConnection().getInputStream());
scan.useDelimiter(“\Z”);
while(scan.hasNext()){
String tmp = scan.next();
System.out.println(tmp);
}
}
In questo caso dobbiamo definire il delimitatore di fine documento (Z), oppure avremmo dovuto bufferizzare, poiché, altrimenti, l’implementazione recupera solo i primi 1024 byte nella lettura dello stream di rete. Per il resto tutto rimane identico (e abbastanza semplice).
Con la versione 1.6 di Java arriva un oggetto che finalmente virtualizza in tutto e per tutto una console testuale, la classe java.io.Console, appunto. Di fatto è una classe che può essere di utilità solo in applicazioni standalone e solo in virtual machine che hanno una console testuale. Il tipico modo di recuperare quest’oggetto è il metodo System.console() ed è implementato solo in versioni della virtual machine che presentano una console di testo (e solo dalla shell di comando).
La classe è davvero interessante in quanto non dobbiamo preoccuparci di complicati gestori, di eccezioni, stream e quant’altro… molto utile per chi inizia a programmare. Inoltre c’è un metodo per chiedere la password che evita di scrivere l’echo di quello che stiamo digitando. Vediamo l’API:
public final class Console implements Flushable {
public PrintWriter writer() ;
public Reader reader();
public Console format(String fmt, Object…args);
public Console printf(String format, Object…args);
public String readLine(String fmt, Object…args);
public String readLine();
public char[] readPassword(String fmt, Object…args);
public char[] readPassword();
public void flush();
}
Il metodo più importante è senza dubbio readLine() la cui chiamata è bloccante in attesa dell’input dell’utente. Il risultato sarà una stringa. I metodi printf() e format() effettuano una stampa sull’output della console, mentre readPassword() restituisce un array che rappresenta i caratteri di input dell’utente. Questo metodo, come dicevamo, è stato codificato per evitare di mostrare il testo digitato (come in qualsiasi applicazione che chiede una password).
Vediamo un esempio concreto dove utilizziamo solo l’interfaccia Console per tutte le operazioni di input/output attraverso i metodi appena visti.
Esempio di utilizzo dell’interfaccia Console:
package it.html.j16;
import java.io.Console;
public class ConsoleTest {
public static void main(String[] args) {
//Recuperiamo l’istanza di Console
//associata a questa macchina virtuale
Console console = System.console();
//Utilizziamola per scrivere in output
console.printf(“Benvenuto alla console Java 1.6”);
if (args.length>0){
//Ora chiediamo un valore in input (notare il formato %s)
String line = console.readLine(“nPrego, %s, inserisci un testo >>”, args[0]);
//facciamo l’eco uppercase
console.printf(“Echo: “+line.toUpperCase());
char pwd[] = console.readPassword(“nPrego, %s, inserisci il PIN >>”, args[0]);
if (pinEsatto(pwd))
console.printf(“Bene! PIN CORRETTO!”);
else
//lo mostriamo giusto per vedere la rappresentazione
//altrimenti non avrebbe senso
console.printf(“PIN ERRATO!”);
}else{
//Mostro la sintassi
console.printf(“nPrego inserire un argomento: java it.html.j16.ConsoleTest yourName”);
}
}
private static boolean pinEsatto(char[] pwd) {
char pinEsatto[] = {‘H’,’T’,’M’,’L’,’.’,’I’,’T’};
//Usiamo l’utility della classe Arrays
return java.util.Arrays.equals(pwd, pinEsatto);
}
}
All’utente chiediamo due operazioni di scrittura, una richiesta di una stringa normale, giusto per effettuare una banale operazione di echo, ed una password. Sulla password effettuiamo un controllo e nel caso di pin positivo lo notifichiamo positivamente. Fate attenzione perché il codice qui non funzionerà se non eseguito da una shell di comando. Eseguire questa classe dal pannello di Eclipse, per esempio, darà un valore null alla chiamata System.console().
ARRAY, QUEUE E TYPED COLLECTIONS
A partire dalla versione Java 5 c’è l’introduzione di una serie nuova di realizzazioni concrete di Collection e la modifica alla gerarchia delle collezioni con l’aggiunta del tipo Queue. Il tipo Queue (da non confondersi con le Queue di JMS) era una di quelle strutture dati mancanti nella gerarchia delle collezioni, spesso utilizzata per la gestione delle politiche FIFO (First In First Out). Ora, grazie alla sua introduzione, la gerarchia si presenta così:
Queue è un nuovo tipo che eredita direttamente da Collection e presenta diverse implementazioni pratiche. Ai fini della logica della struttura dati i metodi offer() e poll() sono quelli fondamentali per l’inserimento e la rimozione di elementi secondo la logica FIFO.
Una classe di prova per effettuare test:
package it.html.java5;
import java.util.LinkedList;
import java.util.PriorityQueue;
import java.util.Queue;
public class QueueTest {
public static void main(String[] args) {
System.out.println(“Ordinamento classico, secondo l’ordine d’arrivo”);
Queue<String> queue= new LinkedList<String>();
for (int i=0; i<50; i++){
queue.offer(“String #”+i);
}
while(!queue.isEmpty()){
System.out.println(queue.poll());
}
//..
Nel primo caso ci troviamo di fronte ad una situazione classica, una coda tipica, ordinata per ordine di arrivo (quindi FIFO). La coppia di metodi offer()–poll() ci garantisce la consistenza della coda e del suo ordine. Eseguendo il codice ci aspettiamo di vedere le stringhe ordinate per identificativo crescente. Si noti che il tipo concreto è LinkedList che è stato reimplementato per garantire l’estensione dell’interfaccia Queue.
Esempio di utilizzo di PriorityQueue:
//..
System.out.println(“Ordinamento alfabetico, in base al compareTo()”);
Queue<String> queuePrio= new PriorityQueue<String>();
for (int i=0; i<50; i++){
queuePrio.offer(“String #”+i);
}
while(!queuePrio.isEmpty()){
System.out.println(queuePrio.poll());
}
}
}
La coda a priorità esegue l’estrazione degli elementi secondo la priorità assegnata. Qui lasciamo il comparatore di default (ma PriorityQueue può accettare un Comparator<E,T>) in quanto lasciamo al metodo compareTo() dell’interfaccia Comparable il compito di effettuare la comparazione. L’esecuzione in questo caso darà la lista in ordine alfabetico:
String #0
String #1
String #10
String #11
String #12
String #13
String #14
String #15
String #16
String #17
String #18
String #19
String #2
String #20
String #21
String #22
La novità più importante è l’introduzione nella gerarchia di questo nuovo tipo. Tra le altre piccole novità introdotte sicuramente dobbiamo citare l’estensione della classe di utilità java.util.Arrays che presenta una serie di utilissimi metodi statici per la gestione di array mono e multidimensionali.
Nuove interfacce (package java.util):
- Deque;
- BlockingDeque;
- NavigationSet;
- NavigationMap;
- ConcurrentNavigableMap.
Di fatto queste rappresentano definizioni di nuove strutture dati. La prima è importante ed è direttamente collegata alla coda discussa nel capitolo precedente. Una Deque, è una coda a cui è possibile accedere da entrambi gli estremi (sia in inserimento che in rimozione). In alcune situazioni può essere il modello di struttura dati che necessitiamo, quindi Sun ha provveduto con l’implementazione all’interno del framework.
Per la gestione di sistemi multithread sarà utile l’utilizzo dell’interfaccia BlockingDeque, che estende dalla prima e che effettua l’attesa di spazio disponibile, nel caso di inserimento in coda piena, e l’attesa di un elemento inserito nel caso di coda vuota.
I Set e Map navigabili (NavigationSet e NavigationMap) definiscono il comportamento di un set e una mappa rispettivamente, permettendo delle funzioni di navigazione e attraversamento dei nodi in maniera ordinata. La versione concorrente (ConcurrentNavigableMap) verrà utilizzata nel caso di possibile accesso concorrente.
Ovviamente, per poter realizzare queste interfacce sono state realizzate le rispettive classi che elenchiamo:
- ArrayDeque;
- LinkedBlockingDeque;
- ConcurrentSkipListSet;
- ConcurrentSkipListMap;
- AbstractMap.SimpleEntry;
- AbstractMap.SimpleImmutableEntry;
- LinkedList;
- TreeSet;
- TreeMap.
Partiamo dalle ultime tre, che non sono dei nuovi tipi ma sono delle reimplementazioni, fatte per essere compatibili con le nuove interfacce. LinkedList ora implementa la nuova interfaccia Deque.
ArrayDeque invece è una nuova classe che si occupa di gestire il comportamento di una Deque in concreto. Stessa cosa dicasi per LinkedBlockingDeque, che si occupa di implementare l’interfaccia BlockingDeque. In generale il naming utilizzato già indica la tipologia di implementazione che quella classe vuole realizzare, come per tutte la gerarchia del Collection framework.
A partire dalla versione di Java 1.6 c’è l’introduzione dei metodi Array.copyOf() e Array.copyOfRange() che consentono di superare l’utilizzo della vecchia classe di utilità System.arraycopy().
JAXP: PROCESSARE UN DOCUMENTO XML
Una delle principali mancanze, delle vecchie versioni di Java, era quella relativa a un paradigma per l’elaborazione di una sorgente XML. Nel momento in cui intendevate effettuare una lettura o qualsiasi operazione su un file XML dovevate utilizzare uno strumento proprietario (API di terze parti) con il rischio di legarvi a vita ad una specifica implementazione.
Una delle modifiche della versione 1.4 di Java è stata quella di introdurre, tra le sue API di base, la JAXP (Java API for XML Processing). Il principale obiettivo di questa modifica è quello di astrarre l’implementazione concreta, lasciando quindi allo sviluppatore un’interfaccia generica da utilizzare, e poi un motore di parsing da poter cambiare in maniera dinamica.
Prima di vedere l’implementazione concreta, citiamo i due modelli di parsing che vengono proposti in JAXP: SAX (Simple API for XML) e DOM (Document Object Model).
Non entriamo nel dettaglio delle due tipologie, richiederebbe un capitolo a parte, ma per comprendere quello che segue è bene sapere che il primo è un modello di accesso semplice, basato sugli eventi incontrati nella lettura di un file XML (apertura e chiusura dei tag, attributi, ecc), il secondo è basato su una scansione del documento e di una rappresentazione dell’albero degli oggetti.
Il primo non mantiene in memoria una rappresentazione del documento, quindi può essere utilizzato per grossi file XML o per accessi veloci. Il secondo, invece, mantiene una struttura dei nodi, quindi può essere utilizzato per documenti di dimensione ridotta o per modificare la struttura dell’albero, aggiungendo e rimuovendo dinamicamente i nodi.
Visto che sono due possibili modelli di utilizzo, JAXP lascia la possibilità di scegliere. La libreria infatti è così composta:
- javax.xml.parsers
- org.w3c.dom
- org.xml.sax
- javax.xml.transform
Il primo è un package generico che definisce le classi factory per poter accedere alle implementazioni concrete di SAX e DOM, e quindi poter processare i file XML.
Il secondo definisce le classi e l’interfaccia programmatica da utilizzare nel caso di un processing DOM delle risorse XML. Qui è contenuta la definizione di Node, Attribute e in generale del modello che rappresenta l’albero dei nodi e come poterlo accedere e modificare.
Il terzo è più semplice in quanto espone il modello programmatico SAX per processare le risorse XML, in questo caso guidato dagli eventi (quindi dalla classe Handler e relativi metodi startTag(), endTag(), ecc).
L’ultimo package introduce la possibilità di trasformare il codice XML attraverso il meccanismo della trasformazione XSL, dando accesso a una serie di interfacce di utilità per raggiungere lo scopo.
Come si vede dal codide, non c’è la necessità di importare librerie di terze parti ed è immediato manipolare il documento modificandone la struttura.
Esempio di accesso DOM a un documento:
package it.html.xml;
public class MainXML {
public static void main(String[] args) throws Exception {
//Recupero concretamente l’engine di parsing DOM (di default)
DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance();
DocumentBuilder domparser = dbfactory.newDocumentBuilder();
//Effettuiamo il parsing di un file
Document doc = domparser.parse(new File(“data.xml”));
//Recuperiamo il primo nodo
Node x = doc.getFirstChild();
//Recupero il primo nodo TEAM del documento
Node y = doc.getElementsByTagName(“TEAM”).item(0);
//Aggiungo il nodo y a x
x.appendChild(y);
//Creiamo un nuovo documento
Document doc2 = domparser.newDocument();
//e appendiamo la rappresentazione del primo doc
doc2.appendChild(x);
//infine salviamo il file
XMLSerializer serializer = new XMLSerializer();
serializer.setOutputCharStream(new java.io.FileWriter(“data2.xml”));
serializer.serialize(doc2);
}
}
L’uniformità garantita dall’interfaccia JAXP ci permette di vedere un documento DOM sempre allo stesso modo. Ciò significa che questo codice potrà essere riutilizzato anche quando cambia l’implementazione del motore di parsing sottostante. Infatti, le prime due righe di codice sono quelle che concretamente recuperano l’implementazione che poi ci garantisce un corretto utilizzo della risorsa.
Abbiamo mostrato come funziona il DOM, ma altrettanta semplicità avrete utilizzando l’interfaccia SAX o la trasformazione XSL.
REFLECTION
COLLECTION THREAD SAFE
FUTURE E FUTURE TASK
LOCKING
Nel capitolo precedente abbiamo introdotto alcuni concetti di sincronizzazione avanzata, mostrando l’uso di una struttura dati molto utile, il semaforo. Il concetto che vedremo qui è quello più a basso livello introdotto con la versione Java 5, il locking.
L’introduzione del locking, attraverso la classe java.util.concurrent.locks.Lock ha lo scopo di mettere a disposizione uno strumento più avanzato e potente rispetto alla classica sincronizzazione, tant’è che ci riferiamo ad esso per definire la sincronizzazione avanzata.
Chi sviluppa programmazione concorrente sa benissimo che l’uso del modificatore di accesso synchronized consente l’accesso in mutua esclusione ad una porzione di codice condivisa per evitare il problema della race condition e dell’interleaving di processi concorrenti. Definendo una sezione o un metodo “synchronized” forziamo l’accesso atomico a quel blocco evitando perciò i problemi di race condition. Questo meccanismo funziona bene ed è tuttora valido ma ha alcune limitazioni che l’uso dei Lock permettono di superare:
- Multi locking;
- Timeout;
- Interruptibility.
Il primo caso è noto in letteratura come “hand over hand” e si riferisce ad esempio quando abbiamo più di una risorsa su cui effettuare il locking, quindi ad esempio prima effettuiamo il locking sulla risorsa A, poi accediamo al lock della risorsa B e liberiamo quindi la A e così via (tipico problema di alcune strutture dati).
Quando una classe accede a un blocco synchronized non ha modo di uscirne finché quella sezione non è liberata. In pratica c’è un’attesa indefinita per la risorsa. Il Lock permette di definire un timeout oltre il quale possiamo uscire dall’attesa (come già abbiamo visto nel capitolo precedente).
L’interruptibility è simile a quanto detto in precedenza, un Lock può essere interrotto e quindi saltare il blocco sincronizzato.
Queste nuove caratteristiche rendono possibile sviluppare evitando le tante insidie che la programmazione concorrente nasconde, grazie a queste nuove strutture dati che ci danno dei potenti strumenti di controllo del flusso concorrente. Vediamo una classe in cui abbiamo codificato dei potenziali blocchi atomici:
Classe che codifica blocchi atomici:
package it.html.threads;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class LockableAction {
private Lock l;
public LockableAction(){
//Creiamo un Reentrant lock, in modo
//da non creare dei deadlock per cicli di lock interni
l = new ReentrantLock();
}
public void doSomethingConcurrent(){
//…svolge qualcosa non concorrente
//acquisici il lock
l.lock();
//…azione 1
//…azione 2
//…
l.unlock();
}
public void doSomethingConcurrentLimitedWait(){
//…svolge qualcosa non concorrente
//Prova ad acquisire il lock
try {
//superati i 5 secondi salta
boolean acquired = l.tryLock(5,TimeUnit.SECONDS);
if (acquired){
//…azione 3
//…azione 4
//…
}
} catch (InterruptedException e) {
e.printStackTrace();
}finally{
l.unlock();
}
}
}
La classe ha un Lock, definito concretamente come ReentrantLock, che è quello più sicuro in quanto evita problemi nel caso il Lock venga utilizzato internamente, come già accade con i metodi synchronized. I due metodi vengono acceduti concorrentemente da processi esterni che ne condividono un’istanza concreta.
Nel primo metodo simuliamo un blocco synchronized. Se però pensiamo che all’interno di esso possiamo definire altri Lock, allora riusciamo a capire come sia possibile sviluppare logiche più complesse (esiste anche la classe Condition). Il secondo metodo sperimenta il lock con timeout (metodo tryLock()) dove definiamo un timeout di 5 secondi, oltre il quale svolgiamo altre azioni.
L’esempio è servito per mostrare l’uso della classe che concretamente potrà aiutarvi in compiti di concorrenza anche abbastanza complessi. Esistono altre classi e migliorie a partire dalla versione Java 5 che abbiamo omesso (come ad esempio il package java.util.concurrent.atomic), ma i maggiori cambiamenti sono quelli che abbiamo illustrato. In generale, per avere una maggiore comprensione delle nuove caratteristiche, potete riferirvi alla documentazione del package java.util.concurrent dove risiedono tutte le nuove implementazioni.
PERFORMANCE
Come vediamo, la crescita nelle performance è lineare e sempre ben marcata (questa la slide della JRE server, ma quella desktop si discosta di poco). Bloccata a 100 la versione 1.3, la 1.6 arriva quasi a 350 di rendimento.Ovviamente mai potrà attestarsi a livelli di un linguaggio a bassissimo livello ma, secondo alcune ricerche, ci sono delle similitudini a livello di performance che permettono di fare ottime esecuzioni (ovviamente non sceglieremo mai Java per sviluppare un software per applicazioni critiche real-time). Vediamo alcune delle attività nascoste del linguaggio Java che gli consentono di avere prestazioni eccellenti:
- Compilazione Just In Time (JIT);
- Hot Spot;
- Garbage Collection.
Discutiamo di come si siano evolute queste attività nelle ultime versioni. Ovviamente si tratta di attività nascoste che il comune programmatore non si deve preoccupare di conoscere, ma che ci sollevano dall’effettuare alcuni compiti (come la gestione della memoria da parte del garbage collector) che necessiterebbero un livello di conoscenza più profondo della tecnologia.
Attraverso la compilazione Just In Time si effettua un lavoro di ottimizzazione per eseguire un pezzo di codice Java compilandolo in codice nativo solo al momento della reale necessità. Java effettua questo con un linguaggio intermedio (il famoso bytecode), il cui compito è quello di rendere più facile il passaggio verso il codice finale “nativo” sul sistema operativo di destinazione.
Nelle ultime versioni di Java sono introdotte delle migliorie che decisamente migliorano in termini percentuali elevati grazie a tecniche “adattative” che danno vita al seguente strumento di Java: l’hot spot.
Java Hot Spot (che è un trademark di Java) è uno strumento, introdotto nella versione di Java 2 (o 1.2), il cui compito è quello di individuare gli “hot spots” (i punti caldi) di esecuzione per poterli ottimizzare e rendere il processo di traduzione ed esecuzione il più rapido possibile. Per intenderci, se l’hot spot individua un metodo di una classe utilizzato spesso, lo compila e lo lascia già compilato in maniera che il prossimo utilizzo non necessita compilazione. Come faccia la JVM ad individuare un hot spot è compito degli algoritmi adattativi di intelligenza artificiale, che addirittura sono in grado di prevedere con un basso margine di errore le attività più frequenti nel ciclo di vita di una applicazione (giusto per fare un esempio, se dopo un metodo open(), chiamiamo sempre un metodo write() è facile presupporre che alla prossima chiamata di open() la JVM si aspetti un write()). Anche qui, le ultime versioni portano delle migliorie in questi algoritmi adattativi, prendendo a vantaggio anche l’utilizzo del Class Data Sharing.
Il Class Data Sharing viene introdotto in Java 5 e consente di migliorare la velocità all’avvio di una applicazione riutilizzando eventuali package di librerie già caricati in memoria da altre JVM.
Il garbage collector è un altro utilissimo strumento, forse il più importante per il successo di Java. Chiunque abbia sviluppato applicazioni informatiche, prima dell’utilizzo di Java, sa bene quanto complessa e “costosa” sia la gestione della memoria in un linguaggio di programmazione dove lo spazio deve essere allocato (prima del suo utilizzo) e liberato (quando non ci serve più). Con Java tutto questo non è mai servito proprio grazie al Garbage Collector che è un’altra attività automatica effettuata dalla JVM, il cui compito è verificare se un’istanza di un oggetto (e la relativa parte di memoria nell’heap) sia ancora necessario (referenziato da uno degli oggetti che il programma sta utilizzando). Possiamo pensare al garbage collector come a un processo asincrono che tiene una mappa di oggetti e referenze alle istanze utilizzate e che cancella lo spazio di memoria fisico quando uno di questi oggetti non ha referenze da parte di nessuno.
Dal punto di vista delle sostanziali modifiche, anche qui, le principali vennero fatte nella versione 1.5, con l’introduzione del concetto di “young generation” e “old generation”. In realtà il concetto è un po’ più complesso di quello che vado a spiegare ma il principio rimane valido. Quello che si è visto è che la maggior parte delle istanze di una classe sono temporanee, create, utilizzate e scartate, con un ciclo di vita abbastanza giovane. D’altra parte una piccola minoranza di istanze (circa il 10% secondo studi) ha un ciclo di vita maggiore, quasi quello dell’applicazione.
Applicare gli stessi concetti di garbage collection è evidentemente una cosa inutile, in quanto quello che vale per oggetti dal ciclo di vita giovane, non vale per il ciclo di vita vecchio.
La Sun ha quindi introdotto una suddivisione tra “young generation” e “old generation” con garbage collector che appartengono alle due classi e si comportano di conseguenza. Non entriamo nel dettaglio di nessuna delle tecniche utilizzate in quanto richiederebbero approfondimenti piuttosto lunghi, ma penso che già il concetto ci faccia capire le principali modifiche per avere un maggiore rendimento.
JCONSOLE
In questo capitolo affrontiamo una nuova libreria introdotta con la versione 5 di Java: il package java.lang.management. Rispetto ai diversi set di API introdotti finora, questo non ha lo scopo di migliorare gli aspetti di sviluppo, inteso come produzione del codice, ma quelli di gestione dell’applicazione, in particolare della gestione della memoria e delle criticità che l’esecuzione di un programma può presentare (ad esempio accessi concorrenti o altri aspetti peculiari del multithreading).
Effettivamente, una delle carenze del linguaggio era quella di non poter valutare le risorse su cui esso viene eseguito (anche perché non esegue codice nativo) colmata comunque con l’introduzione di questo package e di uno strumento che approfondiremo: JConsole.
Prima di vedere cos’è JConsole, vediamo le principali classi che vengono utilizzate dal tool e che possono essere utilizzate da interfaccia programmatica (API) per le esigenze dei programmi.
- ClassLoadingMXBean Class loading system;
- CompilationMXBean Compilation system;
- MemoryMXBean Memory system;
- ThreadMXBean Threads system;
- RuntimeMXBean Runtime system;
- OperatingSystemMXBean Operating system;
- GarbageCollectorMXBean Garbage collector;
- MemoryManagerMXBean Memory manager;
- MemoryPoolMXBean Memory pool.
Ognuno di essi (come potete vedere dalla convenzione) è un MXBean che è creato secondo lo standard JMX (Java Managment eXtensions). Non vedremo nel dettaglio il funzionamento e l’uso delle suddette classi. Diciamo solo che attraverso esse è possibile interrogare le diverse risorse utilizzate da una JVM per poter capire come le sta utilizzando, quindi torna utile per valutare a runtime la bontà di un nostro algoritmo o di come le nostre classi si stanno relazionando.
In realtà non utilizzeremo quasi mai direttamente queste classi. Se vogliamo monitorare l’andamento di un nostro programma Java lo faremo utilizzando il già citato JConsole, uno strumento diagnostico introdotto da Java 5 che si basa sulla tecnologia JMX; si tratta di uno strumento grafico all’apparenza abbastanza complesso, ma che in realtà ci può dare delle semplici indicazioni su alcuni potenziali problemi che stanno avvenendo sul programma Java in esecuzione.
Il compito di JConsole, secondo la definizione Sun è quello di:
- Scoprire cali di memoria;
- Abilitare o disabilitare il Garbage Collector;
- Scoprire deadlocks;
- Controllare e manipolare dinamicamente il log delle applicazioni;
- Accedere alle risorse del sistema operativo;
- Gestire i Managed Beans (MXBeans) visti sopra.
Per accedere al tool dovrete eseguire il programma bin/jconsole.exe che si trova nella directory degli eseguibili della JDK (1.5 o superiore). Una volta acceduti, un pannello di controllo vi chiederà le azioni da eseguire. Potete scegliere tra “amministrazione locale”, “amministrazione remota” e “amministrazione avanzata”.
La prima gestirà la (o le) Java Virtual Machine in esecuzione in locale, la seconda vi permetterà di accedere ad una macchina remota (un server su cui è presente un servizio, ad esempio), con la terza, sempre remotamente, vi potrete connettere anche a una JVM su cui gira JDK 1.4.
Una volta selezionata la modalità avrete un pannello con le diverse risorse disponibili. Le aree principali sono:
- Sommario
- Memoria
- Threads
- Classi
- Virtual Machine
- Managed Beans
Sta di fatto che in alcune di esse avrete la possibilità di studiare l’andamento grafico (memoria), la concorrenza di risorse (threads) o il numero di classi che, in una determinata istanza della JVM, si stanno eseguendo al momento.
Vi sono alcune caratteristiche basiche che consentono un immediato uso del tool, ma sicuramente, per una amministrazione più professionale, dovrete imparare bene ognuna delle possibili situazioni critiche e come poterle risolvere con JConsole: a tal proposito vi consigliamo la lettura della documentazione Sun.
GENERAZIONE DINAMICA PROXY RMI
“Greetings! Very useful advice in this particular article! It’s the little changes that produce the most significant changes. Thanks for sharing!”
ragb43235