Advanced Java rev. 1.

0 Novembre 2012

Sommario
Sommario.........................................................................................................................................................1
Introduzione.....................................................................................................................................................8
Ambiente software e tool.............................................................................................................................8
Analisi delle proprietà di sistema e variabili di ambiente.................................................................................9
Introduzione alla Java Reflection......................................................................................................................9
Uso delle annotazioni e reflection..............................................................................................................14
C’è un baco in URLClassLoader ?............................................................................................................15
Uso della reflection nella classe ServerSistema..........................................................................................16
Caricamento delle classi e uso dell’opzione –Xbootclasspath........................................................................18
Il caricamento delle classi in Java...............................................................................................................18
Il caricamento delle classi per istanziazione...............................................................................................19
Uso dell’opzione non standard –Xbootclasspath........................................................................................21
Accesso programmatico al JAR manifest........................................................................................................24
Scrittura del manifest.................................................................................................................................24
Lettura del manifest...................................................................................................................................25
Uso combinato della lettura del manifest e dell’opzione –Xbootclasspath/p.........................................27
Manifest di MyCorbaWorld e modifiche all’oggetto ServerSistema.......................................................28
Serializzazione di oggetti Java.........................................................................................................................29
Approccio programmatico alla serializzazione: l’applicazione Serial..........................................................30
Subtipi della classe OutputStream e codice di serializzazione................................................................31
Ereditarietà della serializzabilità di una classe....................................................................................31
Dump degli oggetti serializzati e scrittura permanente......................................................................32
Approccio programmatico alla deserializzazione: l’applicazione Deserial..................................................33
Subtipi della classe InputStream e codice di deserializzazione...............................................................34
Limitazioni alla deserializzabilità.............................................................................................................34
Il protocollo di serializzazione.....................................................................................................................35
Dettagli sulla serializzazione dell’istanza di una classe...........................................................................35
Descrizione della classe......................................................................................................................37
Descrizione del supertipo...............................................................................................................37
Descrizione dei campi di una classe................................................................................................38
Descrizione dello stato dell’istanza serializzata..................................................................................38
Serializzazione di tipi primitivi................................................................................................................39
Serializzazione nativa di un tipo primitivo..........................................................................................39

pag. 1
Advanced Java rev. 1.0 Novembre 2012

Serializzazione di un tipo primitivo.....................................................................................................40

Serializzazione di tipi primitivi numerici.............................................................................................41
Serializzazione di un oggetto di tipo String.............................................................................................42
Serializzazione dell’istanza di una classe con campi tipizzati mediante altre classi................................42
L’ottimizzazione della serializzazione gestita mediante handle..............................................................44
Serializzazione di una classe ricorsiva.................................................................................................47
Serializzazioni iterate..............................................................................................................................48
Serializzazione di array...........................................................................................................................49
Serializzazione di un array di dati primitivi.........................................................................................50
Serializzazione di un array di stringhe.................................................................................................51
Serializzazione di un array di classi.....................................................................................................52
Array come campi di classi serializzate..............................................................................................53
Campo di tipo array di dati primitivi...............................................................................................53
Campo di tipo array di classi...........................................................................................................55
Introduzione all’utilizzo dei socket in Java......................................................................................................58
La struttura dell’applicazione.....................................................................................................................58
La classe Telephone................................................................................................................................59
La classe Receiver...................................................................................................................................61
Gestione degli errori...........................................................................................................................63
Scenario di utilizzo......................................................................................................................................63
Considerazioni finali sui socket in Java.......................................................................................................65
Introduzione euristica al Remoting di Java....................................................................................................66
Eventi remoti..............................................................................................................................................68
Lato server..............................................................................................................................................69
Lato client...............................................................................................................................................71
Miglioria alla gestione eventi sul lato server..........................................................................................73
La gestione degli eventi remoti nell’applicazione AppReflex..................................................................73
Introduzione euristica a Corba nativo in Java.................................................................................................75
L’applicazione server NativeServer.............................................................................................................75
Implementazione dell’oggetto server.....................................................................................................75
Partenza e collegamento al NameService...............................................................................................76
Creazione o risoluzione di un namespace (contesto) applicativo...........................................................76
Creazione e bind dell’oggetto server......................................................................................................77
Ingresso nello stato d’attesa e terminazione..........................................................................................77
Costruzione e lancio dell’applicazione....................................................................................................77

pag. 2
Advanced Java rev. 1.0 Novembre 2012

L’applicazione client NativeClient...............................................................................................................78

Partenza e collegamento al NameService...............................................................................................78
Risoluzione dell’oggetto server e invocazione dei suoi metodi..............................................................78
Costruzione e lancio dell’applicazione....................................................................................................79
Scenario semplice di funzionamento..........................................................................................................79
Messaggi GIOP utilizzati da Corba nativo in Java........................................................................................79
Modifiche al software volte ad effettuare il dump dei messaggi GIOP...................................................79
Individuazione del punto in cui intervenire........................................................................................79
Soluzione adottata..............................................................................................................................80
Messaggi GIOP scambiati con ORBD NameService.................................................................................80
Primo messaggio di richiesta..............................................................................................................80
Realizzazione diretta di siti web con Tomcat..................................................................................................82
L’applicazione web First.............................................................................................................................82
Apparenza e navigazione........................................................................................................................82
Costruzione dell’applicazione web First.................................................................................................83
Il welcome file [Link] e le altre pagine del sito............................................................................83
La directory META-INF........................................................................................................................84
La directory WEB-INF .........................................................................................................................84
Il servlet di First..............................................................................................................................85
Il file descrittivo [Link]................................................................................................................86
Passaggio dalla directory First al sito First.........................................................................................86
L’applicazione web Second.........................................................................................................................87
Costruzione dell’applicazione web Second.............................................................................................87
Uso dell’annotazione..........................................................................................................................87
Passaggio dalla directory First2 al sito Second...................................................................................87
Seconda versione del sito Second...........................................................................................................87
Compilazione e costruzione del WAR file...........................................................................................88
Servlet standalone......................................................................................................................................89
Costruzione ingenua del servlet standalone Ciao e del sito client LightSite..........................................89
Costruzione corretta del servlet standalone Ciao e del sito client LightSite..........................................90
Servlet (standalone) che restituisce dati e non pagine HTML.....................................................................92
Costruzione del servlet...........................................................................................................................92
Un esempio di client che utilizza JavaScript............................................................................................93
Il servlet Booklet.............................................................................................................................................95
Impostazione del progetto Eclipse..............................................................................................................95

pag. 3
Advanced Java rev. 1.0 Novembre 2012

I metodi doGet e doPost.............................................................................................................................97

Deployment e librerie necessarie...............................................................................................................98
Richieste e risposte.....................................................................................................................................99
Un problema nell’implementazione delle Servlet Specifications 3.0 ?.......................................................99
L’applet BookletApplet.................................................................................................................................100
Costruzione mediante Eclipse...................................................................................................................100
Analisi del codice del metodo gestData................................................................................................101
Build e deployment..............................................................................................................................102
Utilizzo dell’applet da una pagina HTML..................................................................................................102
Uso di Ajax per realizzare pagine HTML client di servlet..............................................................................103
Definizione di Ajax....................................................................................................................................103
Modifiche al servlet Booklet.....................................................................................................................103
La pagina HTML PaginaAjax......................................................................................................................104
Struttura del codice..............................................................................................................................105
Codice HTML.....................................................................................................................................106
Codice JavaScript..............................................................................................................................106
Pagina in versione asincrona....................................................................................................................109
Riorganizzazione del codice JavaScript per la modalità asincrona........................................................109
Utilizzo della libreria axis2 per la realizzazione di Web Service e client........................................................111
Installazione di axis2.................................................................................................................................111
Impostazione del progetto Eclipse LibreriaWS.........................................................................................111
Build......................................................................................................................................................111
Installazione..........................................................................................................................................112
WSDL, l’interfaccia verso i client...........................................................................................................112
Modalità di accesso client alla web service..............................................................................................112
SocketClient..........................................................................................................................................112
PaginaAjaxWS.......................................................................................................................................114
Realizzazione di un client di LibreriaWS utilizzando axis2.........................................................................115
L’applicazione LibreriaWSClient............................................................................................................116
Generazione delle classi stub per il colloquio con la web service.....................................................116
Utilizzo delle classi stub nel codice dell’applicazione client..............................................................117
Build dell’applicazione client............................................................................................................118
L’applet LibreriaWSApplet....................................................................................................................119
Firma dell’applet...............................................................................................................................120
Uso di un manifest esplicito per l’applet......................................................................................120

pag. 4
Advanced Java rev. 1.0 Novembre 2012

Costruzione della jax-ws web service PeopleWS..........................................................................................122

Installazione del framework jax-ws RI......................................................................................................122
Impostazione del progetto Eclipse PeopleWS..........................................................................................122
Build della jax-ws web service LibreriaXWS..........................................................................................123
Fase di annotation processing..........................................................................................................123
Un problema rilevato nell’uso della classe AnnotationProcessingTask........................................124
I file descrittivi [Link] e [Link]..........................................................................................124
Dettagli su [Link]......................................................................................................................125
Dettagli su [Link]..............................................................................................................125
Fase di creazione del file WAR..........................................................................................................125
Aggiunta di librerie.......................................................................................................................126
Installazione della JAX-WS web service PeopleWS...................................................................................127
Realizzazione di un applet client di PeopleWS..........................................................................................127
Fase di generazione dello stub.............................................................................................................127
Uso delle classi generate da <wsimport>.............................................................................................129
Generazione ed esecuzione..................................................................................................................129
Analisi dei messaggi SOAP con SocketClient.............................................................................................130
Utilizzo di funzionalità avanzate del framework JAX-WS..............................................................................132
Generalità su handler e message context nel framework jax-ws.............................................................132
La classe LoggingHandler, implementazione dell’interfaccia SOAPHandler.............................................132
File di configurazione contenente la definizione della catena dei handler...............................................133
Il nuovo target wsimport e gli effetti della sua esecuzione...................................................................134
Dump dei messaggi HTTP SOAP................................................................................................................135
Client avanzato che usa feature proprie del framework jaxws-ri.............................................................135
Modifiche alla compilazione e generazione del JAR.............................................................................136
Esecuzione e analisi dei messaggi.........................................................................................................137
Utilizzo di un handler applicativo da parte della web service...................................................................137
La classe LoggingHandler adattata al lato server..................................................................................137
File di configurazione contenente la definizione della catena dei handler...........................................138
Modifiche al codice della classe PeopleWSClass...............................................................................138
Modifiche al target <compileService> e gli effetti della sua esecuzione...........................................138
Generazione del file WAR, suo caricamento e funzionamento.............................................................138
Scenario di funzionamento...............................................................................................................138
Introduzione alle pagine JSP.........................................................................................................................141
Generalità sulle pagine JSP mediante l’analisi della pagina [Link].......................................................141

pag. 5
Advanced Java rev. 1.0 Novembre 2012

Panoramica sugli elementi JSP..............................................................................................................141

Scripting elements............................................................................................................................142
Informazioni di basso livello sulle pagine JSP.......................................................................................143
L’uso di form HTML nelle pagine JSP....................................................................................................144
La pagina autoimpostante [Link].........................................................................................144
Uso di un custom bean.........................................................................................................................145
Ingresso nella pagina, post della form e uso dell’oggetto param di EL.................................................146
Accesso al database..................................................................................................................................146
Visibilità e persistenza degli oggetti di accesso al database.................................................................148
Barriere e aperture tra codice client, codice Java e azioni nelle pagine JSP.............................................149
Case study............................................................................................................................................150
Uso dei cookie..............................................................................................................................................152
Prima versione, ingenua, della pagina......................................................................................................152
Analisi dei messaggi HTTP.....................................................................................................................153
Utilizzo di XSLT in Booklet.....................................................................................................................153
Analisi di [Link] e suo utilizzo ...................................................................................................154
Il problema della persistenza dei valori nei campi delle form...............................................................156
Il tentativo fallimentare dell’uso di una pagina JSP..................................................................................156
Uso dei cookie su lato client.....................................................................................................................156
Creazione, persistenza e visibilità dei cookie........................................................................................156
Utilizzo dei cookie per ripristinare i valori delle form...........................................................................157
Soluzione al problema dell’eccessiva persistenza.................................................................................157
Uso dei cookie originati da server............................................................................................................158
Un esempio di funzionalità protetta: GiudiziSuAutori..........................................................................158
Modifiche al codice di Booklet..........................................................................................................159
Esempio di pagina HTML che utilizza un cookie originato da server.....................................................160
Scope, visibilità e modo d’impiego del cookie..................................................................................162
Principali novità introdotte da Java 1.8........................................................................................................163
Setup di Eclipse per l’uso di Java 1.8.........................................................................................................163
Le espressioni lambda..............................................................................................................................163
Il progetto Lambda...............................................................................................................................163
Definizione di interfaccia funzionale.................................................................................................163
Uso dell’interfaccia funzionale per costruire espressioni lambda.....................................................163
Rapporti di visibilità tra body di un’espressione lambda ed enclosing scope...............................164
Scrittura semplificata di espressioni lambda.................................................................................165

pag. 6
Advanced Java rev. 1.0 Novembre 2012

Passaggio parametrico di espressioni lambda..................................................................................165

La vecchia alternativa alle espressioni lambda: le classi anonime........................................................166
I default method.......................................................................................................................................167
Dichiarazione e utilizzo dei default method.........................................................................................167
Uso di metodi statici nelle interfacce...................................................................................................168
Sinergia tra default method ed espressioni lambda.............................................................................168
Cos’è un oggetto di tipo Stream...............................................................................................................169
Relazioni tra collezioni, operazioni aggregate e stream........................................................................169
Non confondere il metodo forEach della collezione con il metodo forEach dello stream................170
Principali caratteristiche delle operazioni aggregate............................................................................170
Operazioni aggregate intermedie e parallele...................................................................................170
Pipeline di operazioni aggregate.......................................................................................................171
Stream nativi.....................................................................................................................................172
Ordinamento degli elementi di uno stream..........................................................................................173
Caso di ordinamento sovraimpresso................................................................................................174
L’ordinamento nella collezione e nello stream associato.................................................................175
Dettagli di funzionamento del metodo sort delle collezioni.........................................................175
Stream standalone................................................................................................................................176
I method reference...................................................................................................................................176
Riferimento ad un metodo d’istanza di un oggetto arbitrario di tipo dato...........................................176
Riferimento ad un metodo statico di un tipo dato...............................................................................177
Riferimento ad un metodo d’istanza di un particolare oggetto............................................................178
Riferimento ad un costruttore..............................................................................................................178
Limitazioni comuni ai method reference..............................................................................................180

pag. 7
Advanced Java rev. 1.0 Novembre 2012

Introduzione.
Questo documento descrive un’odissea attraverso il mondo Java; il viaggio procede per tematiche: alcune
sono intrinseche al mondo Java, fanno parte del cuore del framework, come la reflection; altre tematiche
riguardano campi applicativi, che però hanno grande importanza nel mondo Java.

Ambiente software e tool.

Ho lavorato sempre in Windows, 32 bit, XP Professional oppure 7 Professional, in italiano. A tratti ho
utilizzato anche un server Linux, ma senza sviluppi, solo per l’esecuzione.

Il linguaggio utilizzato è Java, versione 1.7.0_07 JavaEE (Enterprise Edition); l’ho installato tramite il
pacchetto di installazione java_ee_sdk-[Link], usando le scelte default: così facendo, Java
risulta installato nella directory C:\glassfish3\jdk7.

Ho definito la variabile d’ambiente, di sistema, JAVA_HOME = C:\glassfish3\jdk7; poi ho aggiunto

<JAVA_HOME>/bin alla variabile d’ambiente path.

Come strumento indipendente, non compreso in altri pacchetti (cioè not embedded), ho installato Apache
ant, versione 1.8.4. Ho definito la variabile d’ambiente, di sistema, ANT_HOME = C:\apache-ant-1.8.4, e ho
aggiunto <ANT_HOME>/bin alla variabile d’ambiente path.

Ho usato Eclipse, nella versione Eclipse Java EE IDE for Web Developers, versione Juno SR1. Per
installarlo, bisogna scaricare il pacchetto [Link], quindi unzippare sotto C:\, così
viene creata la directory C:\eclipse, con alcune sottodirectory.

Tuttavia servono alcuni accorgimenti, per poter operare come desiderato.

Prima di tutto, bisogna modificare il file [Link]:

[Link] originale [Link] modificato

... ...

--[Link] --[Link]

256m 256m

--[Link] -vm

C:/glassfish3/jdk7/bin/[Link]

openFile openFile

-vmargs -vmargs

-[Link]=1.5 -[Link]=1.7

-Xms40m -Xms40m

-Xmx384m -Xmx512m

Per comodità, definisco la variabile d’ambiente, di sistema, ECLIPSE_HOME = C:\eclipse.

Una volta installato Eclipse, lo lancio e scelgo Help  Install new software e controllo la voce: What is
already installed ?

pag. 8
Advanced Java rev. 1.0 Novembre 2012

Trovo che l’unico plugin installato è Eclipse IDE for Java EE Developers.

Volendo creare applicazioni grafiche, Swing e SWT, bisogna installare i plugin appositi. Per farlo, scelgo
HelpInstall new software, come prima, Work with = All available sites, e dalla lista che si presenta scelgo
General purpose tools, di qui seleziono Swing Designer e SWT Designer, e li installo: con ciò, Eclipse Juno è
pronto per sviluppare applicazioni grafiche, Swing o SWT che siano.

Come web application server, viene utilizzato Apache Tomcat 7.0, corredato di axis2 come libreria di
implementazione delle web service.

Ho installato Tomcat usando il pacchetto [Link]; ho seguito tutti i default, tranne che per
la porta principale, al posto del default 8080 ho assegnato 8081.

Per installare Apache axis2, ho scaricato il pacchetto [Link] (è la standard binary distribution,
che non necessita compilazione), e ho unzippato sotto C:\, ottenendo così la directory C:\axis2-1.6.1. Ho
definito la variabile d’ambiente, di sistema, AXIS2_HOME = C:\axis2-1.6.1.

Per costruire [Link], apro un command prompt e mi posiziono in <AXIS2_HOME>/webapp, ove si trova
[Link], e do il comando ant [Link]. Così facendo, viene creato [Link] entro la directory
<AXIS2_HOME>/dist.

Copio il file [Link] entro la directory webapps di Tomcat, con Tomcat running: automaticamente Tomcat
crea la directory axis2 entro webapps.

Come database, viene utilizzato Oracle Express 10g. Dopo l’installazione, il TNS name è XE.

Sono presenti tre utenti/database: Libreria, DBPeople e il sample database predefinito HR.

Ho creato la directory Drivers entro oraclexe, contenente [Link], usato per l’accesso JDBC dal linguaggio
Java, JDK 1.6 o superiore.

Come software di implementazione di Corba, viene usato Orbacus, versione 4.3.4 per Java; ogni dettaglio
inerente Orbacus è fornito in un apposito documento.

Analisi delle proprietà di sistema e variabili di ambiente.

Tanto le proprietà quanto le variabili di sistema sono meccanismi per condizionare il comportamento delle
applicazioni; le proprietà si ricavano solitamente come [Link](), le variabili di ambiente come
[Link](): entrambe le chiamate restituiscono i dati organizzati come mappe di coppie chiave-valore.

Introduzione alla Java Reflection.

La reflection solitamente comincia caricando una classe della quale si conosce il nome, poi prosegue
analizzandone i metodi ed eventualmente istanziando la classe e chiamando i metodi dell’istanza.

Questo è ciò che viene fatto in maniera generalizzata nell’applicazione AppReflex; non studierò
l’applicazione in toto, ma studierò la sua gestione della reflection.

Il sistema di caricamento di una classe della quale si conosce il nome cambia, a seconda che la classe sia
locale ossia già presente nell’insieme di classi (JAR) acceduto di default dalla JVM, oppure la classe sia
esterna ossia si trovi in un JAR esterno, non acceduto di default dalla JVM 1. L’applicazione AppReflex
permette il caricamento in entrambi i casi.
1
Non bisogna confondere tra ricerca e caricamento: la JVM carica solamente le classi che servono, quando
servono, e le cerca entro i JAR che si trovano in un certo default path; finchè non c’è necessità, la JVM non
carica una classe che pure si trova in un JAR del default path.

pag. 9
Advanced Java rev. 1.0 Novembre 2012

Il codice che permette il caricamento di una classe locale, partendo dal suo nome, è il seguente:
try
{
Class cls = [Link](nomeClasse);
}
catch (ClassNotFoundException e)
{
<segnalazione dell’errore>
}

ove nomeClasse è una variabile di tipo String; la classe Class appartiene al package [Link].

Posso caricare una classe appartenente a [Link], come Empl che appartiene al package rem,
assegnando nomeClasse = “[Link]”, ma posso caricare anche una classe non appartenente a
[Link] ma comunque situata (in un JAR) sul default path della JVM, ad esempio la classe NTSystem,
appartenente a [Link]: nomeClasse = “[Link]”.

Il default path in cui la JVM cerca le classi comprende sicuramente il classpath, rappresentato dalla proprietà
[Link], ma comprende anche altri percorsi; i dettagli variano tra le diverse installazioni.
Programmaticamente, il default path comprende sia il classpath, sia la lista dei JAR elencati dalla proprietà
[Link] (tra essi, c’è sempre [Link]), sia i JAR presenti nelle directory elencate nella proprietà
[Link]. L’argomento sarà approfondito e chiarito nel seguito, trattando i class loader.

Osservazione importante: quando l’oggetto della JVM è un JAR e non una singola classe, il classpath è
posto automaticamente uguale al JAR oggetto; così, dato il comando java –jar [Link], il valore della proprietà,
quindi il classpath, è il seguente: [Link] = [Link], qualsiasi diversa assegnazione del classpath prima
del lancio viene ignorata.

Adesso considero una classe esterna, ad esempio la classe Complex, appartenente al package num,
contenuta in LibJar/[Link]. Per caricarla, devo prima di tutto indirizzare correttamente il JAR file; nel caso in
cui si trovi sul disco locale, come Uti, posso scrivere String urlJAR =
"file:/C:/Libjar/[Link]".

Ecco il codice utilizzato per caricare la classe esterna:

String urlJAR = "file:/C:/Libjar/[Link]";
URL[] urls = { new URL(urlJAR) };
URLClassLoader loader = new URLClassLoader(urls);
try
{
Class cls = [Link]("[Link]");
}
catch (ClassNotFoundException exc)
{
<segnalazione dell’errore>
}
[Link]();

Una volta che una classe è stata caricata, è possibile studiarne i costruttori, i metodi e gli altri membri; come
esempio, uso ancora la classe [Link] della libreria [Link]. Ecco il codice della classe [Link]:
public class Complex
{
private double real,img;
public Complex() { real = img = 0; }
public Complex(double r,double i) { real = r; img = i; }
public double getReal() { return real; }
public double getImg() { return img; }
public void setReal(double r) { real = r; }
public void setImg(double i) { img = i; }
private String format(double x) { ... }

pag. 10
Advanced Java rev. 1.0 Novembre 2012

private String replacer(String txt,String old,String neu) { ... }

private String postProc(String s) { ... }
@Override
public String toString() { ... }
public double module() { return [Link](real*real + img*img); }
public void coniugate() { img = -img; }
public Complex autoSum(double r,double i) {return new
Complex(r+real,i+img);}
}

Posso conoscere i costruttori della classe caricata, e i tipi dei parametri di ciascuno di essi, mediante il
codice seguente, in cui Constructor appartiene al package [Link]:
Constructor[] ctors = [Link]();
[Link]("Trovati " + [Link] +" costruttori");
for (Constructor ctor : ctors) [Link]([Link]());

l’esecuzione del codice fornisce:

Trovati 2 costruttori
public [Link](double,double)
public [Link]()

È possibile recuperare i tipi dei parametri in modo programmatico (cioè, non solo visualizzarli): dato un
costruttore ctor, il codice Type[] ts = [Link]() recupera l’array dei tipi
dei parametri del costruttore, nell’ordine di apparizione.

Si può creare un’istanza utilizzando un costruttore ben preciso.

Se il costruttore che si intende usare è senza parametri, scrivo Object ist = [Link](),
ovviamente non posso definire ist usando il suo tipo, Complex, quindi lo definisco genericamente come
Object (se sapessi già del tipo Complex, non seguirei questa strada). Alternativamente, se ctor rappresenta il
costruttore senza parametri, posso scrivere Object ist = [Link](); le due strade non
sono esattamente coincidenti, tuttavia sono entrambe percorribili.

Se invece il costruttore ctor è dotato di parametri, scrivo Object ist = [Link](vals),

ove vals è di tipo Object[] e ha tanti elementi quanti sono i parametri del costruttore – si ricordi che numero,
tipo e ordine dei parametri sono noti come Type[] ts = [Link]().

I valori da passare devono essere del tipo giusto; ad esempio, usando come ctor il costruttore
Complex(double,double), posso scrivere quanto segue:
Object[] vals = new Object[2];
vals[0] = -2.3;
vals[1] = 3.15;
Object c = [Link](vals);
[Link](c);

Ecco l’output: -2.3+i3.15.

Anche vals[0] = -Math.E e vals[1] = [Link] costituiscono una valida parametrizzazione, oppure
vals[0] = 1 e vals[1] = 2 perché essendo interi possono fungere da double; invece scrivendo
vals[0] = 1 e vals[1] = true oppure vals[0] = "1" e vals[1] = 2 ho eccezioni runtime.

Per conoscere i metodi della classe caricata, uso come esempio il codice seguente:
Method[] ms = [Link]();
[Link]("Trovati " + [Link] + " metodi");
for (Method m : ms) [Link]([Link]());

l’esecuzione del codice fornisce:

Trovati 11 metodi
public [Link] [Link]()
private [Link] [Link](double)

pag. 11
Advanced Java rev. 1.0 Novembre 2012

public double [Link]()

public double [Link]()
public void [Link](double)
public void [Link](double)
private [Link]
[Link]([Link],[Link],[Link])
private [Link] [Link]([Link])
public double [Link]()
public void [Link]()
public [Link] [Link](double,double)

si noti che vengono inclusi anche i metodi non pubblici.

Osservazione importante: si possono chiamare solamente i metodi pubblici della classe.

È possibile recuperare i tipi dei parametri in modo programmatico (cioè, non solo visualizzarli): dato un
metodo m, il codice Type[] ts = [Link]() recupera l’array dei tipi dei
parametri del metodo, nell’ordine di apparizione.

Vedo adesso come possono essere invocati i metodi; c’è differenza tra metodi con o senza parametri, e
comincio dall’invocazione di uno di questi ultimi.

Costruisco come sopra un’istanza c di [Link], rappresentabile come -2.3+i3.15; poi invoco su
essa il metodo module e osservo il risultato:
Method mm = [Link]("module");
Object res = [Link](c);
[Link]("modulo(c)="+res);

Ecco l’output: modulo(c)=3.9003204996512784.

Si noti che ho assegnato il risultato dell’invocazione a un oggetto generico; avrei potuto essere più preciso,
studiando il tipo del valore di ritorno del metodo, ad esempio ottenendo il tipo di ritorno mediante l’istruzione
Type rt = [Link]()), e poi facendo uno switch sui nomi dei tipi fino a trovare quello giusto,
cioè “double”, a questo punto avrei potuto scrivere double result = (Double) [Link](c).

Il motivo per cui preferisco usare un generico Object è dovuto al fatto che non sempre ho a disposizione il
tipo di ritorno: questo è il caso dell’esempio seguente.

Ho ancora l’istanza c di [Link], rappresentabile come -2.3+i3.15; invoco su c il metodo autoSum,

passando 3.3 e -0.15 nei parametri: viene generato un altro oggetto Complex, rappresentabile come 1+i3.

Segue il codice – si ricordi che autoSum ha due parametri di tipo double in input e restituisce Complex:
Class[] pars = new Class[2];
pars[0] = pars[1] = [Link];
Method mm = [Link]("autoSum",pars);
Object[] vals = new Object[2];
vals[0] = 3.3;
vals[1] = -0.15;
Object cc = [Link](c, vals);
[Link]("cc="+cc);

Ecco l’output: cc=1+i3.

Un caso a parte è costituito dai metodi statici.

Innanzi tutto, dato un certo metodo, è possibile stabilire se esso sia statico oppure no. La classe Complex
non ha metodi statici, quindi gliene aggiungo un paio:
public static Complex GeneraCasuale()
public static String HexExpr(Complex c)

il primo è un metodo senza parametri, che genera un numero complesso avente come parti due interi di
valore tra 0 e 50 scelti randomicamente; il secondo metodo ha un parametro in ingresso, un complesso, del
quale fornisce, come stringa, una specie di rappresentazione esadecimale.

pag. 12
Advanced Java rev. 1.0 Novembre 2012

Rieseguo il codice che fornisce la lista dei metodi ([Link]):

Trovati 13 metodi
public [Link] [Link]()
private [Link] [Link](double)
public static [Link] [Link]()
public double [Link]()
public static [Link] [Link]([Link])
public void [Link](double)
public void [Link](double)
public double [Link]()
public double [Link]()
private [Link]
[Link]([Link],[Link],[Link]
ing)
private [Link] [Link]([Link])
public void [Link]()
public [Link] [Link](double,double)

Per appurare programmaticamente la natura statica di un metodo, è possibile usare il seguente codice, nel
quale si suppone che m sia un oggetto di tipo Method, quindi rappresentativo del metodo di una classe:

boolean isStatic = (([Link]() & [Link]) ==

[Link])

se isStatic è true, allora il metodo m è statico, altrimenti non lo è.

La classe [Link] definisce, sotto forma di costanti intere potenze di 2, i modificatori

d’accesso applicabili a classi e metodi; oltre a STATIC, ci sono ABSTRACT, PUBLIC, PROTECTED, etc.

La chiamata di un metodo statico, con o senza parametri, è analoga a quella di un metodo non statico, a
parte il fatto che nell’invocazione si passa un null al posto dell’istanza dell’oggetto.

Mostro un esempio di codice, in cui cls è la classe di Complex: prima viene invocato il metodo senza
parametri GeneraCasuale, poi il metodo HexExpr ad un parametro:
Method m = [Link]("GeneraCasuale");
Object oc = [Link](null);
[Link]("Complesso casualmente generato: "+oc);
Class<?>[] pars = new Class<?>[1];
pars[0] = cls;
m = [Link]("HexExpr",pars);
Object[] vals = new Object[1];
vals[0] = oc;
Object os = [Link](null, vals);
[Link]("Rappresentazione esadecimale di "+oc+": "+os);

ecco l’output ottenuto:

Complesso casualmente generato: 9+i46
Rappresentazione esadecimale di 9+i46: 0x1.2p3+i0x1.7p5

Oltre ai costruttori e ai metodi, è possibile ricavare anche i campi e le annotazioni.

Per vedere i campi della classe Complex, utilizzo il seguente codice:

Field[] fs = [Link]();
[Link]("Trovati " + [Link] +" campi");
for (Field f : fs) [Link]([Link]());

ecco il suo output:

Trovati 2 campi
private double [Link]
private double [Link]

pag. 13
Advanced Java rev. 1.0 Novembre 2012

I campi privati vengono mostrati, ma non sono poi accessibili, solamente i campi pubblici sono accessibili.

Uso delle annotazioni e reflection.

Le annotazioni sono i metadati di Java. Sia quelle predefinite, sia quelle definite applicativamente,
discendono tutte dall’interfaccia [Link]. La IDE di Eclipse Juno permette la creazione di
annotazioni, mediante un apposito wizard richiamabile come File  New  Annotation; ho creato in Uti il
package meta, e in esso l’annotazione Remare usando il wizard, ecco il risultato:
package meta;
public @interface Remark
{
}

si noti il carattere @ davanti alla keyword interface, per contraddistinguere l’interfaccia come
annotazione.

Aggiungo i campi e la clausola Retention, molto importante:

package meta;
import [Link];
import [Link];
@Retention([Link])
public @interface Remark
{
String autore();
String commento();
int revisione();
}

non serve dichiarare pubblici i campi, avendo dichiarato pubblica l’annotazione che li contiene.

La clausola Retention ha tre possibili valori di policy: CLASS (il default), SOURCE e RUNTIME; se voglio
poter ritrovare l’annotazione a runtime accedendo le classi o i metodi sui quali l’ho applicata, allora devo
scegliere [Link], in caso contrario essa risulta null.

Creo anche le annotazioni Volatile, di policy CLASS, e Effimera, di policy SOURCE, entrambe con un solo
campo, labile di tipo stringa.

Suppongo di applicare le tre annotazioni alla classe Complex; per farlo, le scrivo in [Link]:
@Remark(autore="Virgilio",commento="okay",revisione=2)
@Volatile(labile="In classe")
@Effimera(labile="In sorgente")
public class Complex
{
...
}

Creo il package prg e in esso la classe [Link], dotata di metodo main; sia il package sia la classe hanno
natura dimostrativa e sono temporanei. Scrivo il codice seguente nel metodo main di Maine:
public static void main(String[] args)
{
Annotation[] anns = ([Link]).getDeclaredAnnotations();
for (Annotation a : anns) [Link](a);
}

mentre il file [Link] è aperto nella IDE di Eclipse, mi sposto col cursore su Complex: la IDE mostra un
tooltip contenente tutte e tre le annotazioni, coi valori assegnati.

Poi compilo il progetto: nel folder build/num trovo [Link]; seleziono [Link] e con il tasto
destro scelgo Open with  Class File Viewer, ecco ciò che vedo nelle prime righe:
@[Link](labile="In classe")
@[Link](autore="Virgilio",

pag. 14
Advanced Java rev. 1.0 Novembre 2012

commento="okay",
revisione=(int) 2)
public class [Link] {
………

l’annotazione Effimera è andata persa: le annotazioni con policy SOURCE sono visibili solo nei sorgenti,
infatti la IDE le mostra, ma non sopravvivono alla compilazione e quindi non compaiono nei class file.

Adesso eseguo il metodo main della classe Maine, ecco l’output:

@[Link](autore=Virgilio, commento=okay, revisione=2)

solamente le annotazioni con policy RUNTIME sono disponibili a runtime, dato che la JVM scarta le
annotazioni con policy CLASS trovate nei class file.

Le annotazioni possono essere associate a un metodo piuttosto che alla classe in toto, ad esempio posso
scrivere il codice seguente in [Link]:
@Remark(autore="Virgilio",commento="okay",revisione=2)
public class Complex
{
...
@Remark(autore="Virgilio",commento="somma di due complessi",revisione=3)
public Complex autoSum(double r, double i)
{
...
}
...
}

Ecco il frammento di codice nel metodo main della classe Maine, usato per recuperare a runtime le
annotazioni su un metodo, qui autoSum:
Class[] pars = { [Link],[Link] };
Method ts = ([Link]).getDeclaredMethod("autoSum",pars);
anns = [Link]();
for (Annotation a : anns) [Link](a);

ecco l’output: @[Link](autore=Virgilio, commento=somma di due complessi,

revisione=3).

Le annotazioni possono essere recuperate con il proprio tipo, e non solo genericamente come ho fatto
finora, ciò permette l’accesso programmatico ai singoli campi delle annotazioni; ecco un esempio:
Remark remc = ([Link]).getAnnotation([Link]);
Class[] pars = { [Link],[Link] };
Method ts = ([Link]).getDeclaredMethod("autoSum", pars);
Remark remm = [Link]([Link]);
[Link]("Commento sulla classe: " + [Link]());
[Link]("Commento sul metodo autoSum: " + [Link]());

ecco l’output:
Commento sulla classe: okay
Commento sul metodo autoSum: somma di due complessi

L’accesso programmatico alle annotazioni avviene solamente in lettura, sono cioè immodificabili.

C’è un baco in URLClassLoader ?

Creo il progetto Tester, una semplicissima applicazione console costituita dal file [Link], contenente la
classe Prg nel package app, dotata del metodo main. Utilizzerò Tester per provare di volta in volta varie
asserzioni, quindi Tester cambierà, anche pesantemente, a seconda dei casi.

Uso una versione di Tester che non referenzia né include [Link], ma si serve di URLClassLoader e della
reflection per accederne le classi; in particolare, l’oggetto loader viene usato per caricare la classe cls, quindi
viene chiuso (nel codice è stata omessa la gestione degli errori, per brevità):
URL[] urls = { new URL("file:/C:/LibJar/[Link]") };

pag. 15
Advanced Java rev. 1.0 Novembre 2012

URLClassLoader loader = new URLClassLoader(urls);

Class<?> cls = [Link]("[Link]");
[Link]();
Annotation[] anns = [Link]();
if ([Link] == 0)
[Link]("La classe "+[Link]()+ " non ha
annotazioni");
else for (Annotation ann : anns) [Link](ann);
... operazioni su cls: istanziazione, chiamata di metodi ...

Ecco l’output:
La classe [Link] non ha annotazioni
Complesso casualmente generato: 25
Rappresentazione esadecimale di 25: 0x1.9p4+i0x0.0p0
non è quello che mi sarei aspettato, perché la classe Complex ha un’annotazione.

Adesso pospongo la chiusura del loader:

URL[] urls = { new URL("file:/C:/LibJar/[Link]") };
URLClassLoader loader = new URLClassLoader(urls);
Class<?> cls = [Link]("[Link]");
Annotation[] anns = [Link]();
[Link]();
if ([Link] == 0)
[Link]("La classe "+[Link]()+ " non ha
annotazioni");
else for (Annotation ann : anns) [Link](ann);
... operazioni su cls: istanziazione, chiamata di metodi ...

Ecco l’output:
@[Link](autore=Virgilio, commento=okay, revisione=2)
Complesso casualmente generato: 33+i10
Rappresentazione esadecimale di 33+i10: 0x1.08p5+i0x1.4p3

Stavolta l’output è proprio quello che mi aspettavo.

Evidentemente il problema è la chiusura del loader: la chiusura del loader di una classe impedisce la lettura
delle annotazioni della classe stessa, sebbene i metodi e le altre feature della classe continuino a funzionare
regolarmente, infatti nel mio esempio la classe può essere istanziata e i suoi metodi possono essere
invocati, solamente le annotazioni spariscono.

Questo comportamento è a mio avviso scorretto, in contrasto con la documentazione.

Uso della reflection nella classe ServerSistema.

Tra le informazioni che il metodo SystemInfo dell’oggetto server ServerSistema fornisce, alcune dipendono
dal sistema operativo sottostante, così è il caso delle informazioni concernenti l’utente nel quale è in
esecuzione l’oggetto remoto (cioè, l’utente nel quale è in esecuzione la JVM che ospita l’applicazione host a
sua volta istanziatrice dell’oggetto server).

Se il sistema operativo sul quale è in esecuzione l’oggetto ServerSistema è Windows, allora posso ricavare il
nome dell’utente e il suo dominio di appartenenza, ad esempio ETS/Ravagliv.

Se invece il sistema operativo è Linux, il concetto di dominio non ha senso, mentre ne acquista quello del
gruppo al quale appartiene l’utente (o meglio, i gruppi, perché di solito un utente appartiene a più gruppi); ad
esempio, se l’oggetto remoto è in esecuzione su sccver, trovo user = tms e i gruppi sono quelli aventi
identificativi 16, 33, 100, 1000.

Posso ricavare il nome dell’utente per vie indipendenti dal sistema operativo, ma non posso sapere il
dominio nel caso Windows, o i gruppi nel caso Linux, senza ricorrere a classi specialistiche: nel caso
Windows, c’è la classe [Link] in grado di fornire l’informazione

pag. 16
Advanced Java rev. 1.0 Novembre 2012

sul domain, mentre nel caso Linux c’è la classe [Link] in

grado di fornire le informazioni sui gruppi d’appartenenza…

il problema è che su Windows le librerie di Java dispongono solamente della classe NTSystem, mentre su
Linux dispongono solamente della classe UnixSystem.

La soluzione a questo problema è l’uso della Java reflection: stabilito a runtime quale sia il sistema operativo
sottostante, il codice del metodo SystemInfo servendosi della reflection istanzia la classe giusta e ne chiama
i metodi adeguati.

Espongo il codice del metodo, omettendo la gestione degli errori e tutte le informazioni ricavate senza
ricorrere all’uso della reflection:
public String[] SystemInfo()
{
Vector<String> infos = new Vector<String>();
String osName = [Link]("[Link]");
Class cls = null;
String methodName1 = "",methodName2 = "";
if ([Link]("Win"))
{
cls = [Link]("[Link]");
methodName1 = "getDomain";
methodName2 = "getName";
}
else if ([Link]("Linux"))
{
cls = [Link]("[Link]");
methodName1 = "getGroups";
methodName2 = "getUsername";
}
else // sistema operativo non previsto
{
String user = [Link]("[Link]");
[Link]("Corba User: "+user);
}
if (cls != null)
{
Object account = [Link]();
Method m1 = null,m2 = null;
m1 = [Link](methodName1);
m2 = [Link](methodName2);
Object res1 = null,res2 = null;
res1 = [Link](account);
res2 = [Link](account);
if ([Link]("Win"))
[Link]("Corba User: "+res1+"/"+res2);
else // Linux
{
long[] ids = (long[]) res1;
String buf = "Corba User: "+res2+" [Group IDs=";
for (int i=0;i<[Link]-1;i++) buf += ids[i]+",";
buf += ids[[Link]-1]+"]";
[Link](buf);
}
}
String[] info = new String[0];
return [Link](info);
}

Viene ricavato in osName il sistema operativo presente: se si tratta di Windows, la variabile cls di tipo Class
carica la classe NTSystem e definisce i nomi dei metodi utili allo scopo, naturalmente metodi della classe

pag. 17
Advanced Java rev. 1.0 Novembre 2012

NTSystem; se invece il sistema operativo è Linux, cls carica la classe di tipo UnixSystem e definisce anche
in questo caso i nomi dei suoi metodi da utilizzare.

Una volta che la classe giusta è stata caricata, bisogna istanziarla: l’istruzione [Link]() crea
l’istanza account, che viene vista come oggetto generico, in quanto non posso fare alcun cast esplicito.

Recupero gli oggetti descrittivi dei metodi, dei quali conosco i nomi, differenti a seconda del sistema
operativo, e compio le invocazioni: anche i risultati vengono trattati a programma come oggetti generici
(res1, res2 sono dichiarati Object); nel caso Linux, è necessaria l’effettuazione di un cast con l’oggetto di
ritorno del metodo [Link], che è di tipo long[].

Caricamento delle classi e uso dell’opzione –Xbootclasspath.

I due argomenti sono strettamente correlati.

Il caricamento delle classi in Java.

La JVM carica le classi servendosi sempre di un loader; esistono diversi tipi di loader usati dalla JVM:
a) bootstrap class loader: carica le classi contenute in alcuni file JAR di JRE_DIR 2/lib, tra essi [Link]; il
bootstrap class loader fa parte del JVM core ed è scritto in codice nativo, non è quindi una classe
Java come le altre
b) class loader per le estensioni: carica le classi contenute nei JAR presenti nelle cosiddette directory
di estensione, ossia quelle presenti in JRE_DIR/lib/ext, o più in generale sul path presente in
[Link]; il class loader per le estensioni è un’istanza della classe
[Link]$ExtClassLoader – la classe [Link], contenuta in [Link], subtipo solo
di Object, ha la classe interna statica ExtClassLoader, subtipo di [Link]
c) system class loader: carica le classi (singoli file .class o interne a un file JAR) trovate sul percorso
definito dalla proprietà [Link]; il system class loader è un’istanza della classe
[Link]$AppClassLoader, ove AppClassLoader è un’altra classe, statica, interna alla
classe Launcher, ed è subtipo di [Link].

Le classi caricate dai class loader di cui ai punti a), b) e c) costituiscono l’insieme delle classi locali.

In precedenza, si è visto come caricare una classe a seconda che si trovi in un JAR già caricato dalla JVM,
oppure in un JAR non caricato dalla JVM. Nel primo caso, il class loader che interviene nell’esecuzione
dell’istruzione [Link](nomeClasse) è uno dei tre sopra elencati.

Ad esempio, considero il codice seguente:

Class cls = [Link]("[Link]");

la classe [Link] appartiene a [Link], quindi è immediatamente caricabile.

La lista dei JAR acceduti in JRE_DIR/lib dal bootstrap class loader è disponibile programmaticamente
mediante il valore della proprietà [Link]; in generale il valore dipende dall’installazione, ma
comprende sempre [Link], [Link], [Link].

Oltre alla lista di JAR, è solitamente compresa nel valore di [Link], anche la directory
JRE_DIR/classes. Quindi, ogni classe presente in JRE_DIR/classes risulta locale e viene caricata dal
bootstrap class loader: se ad esempio estraggo da [Link] (un JAR accademico prodotto in LibJar) la
classe [Link] e la copio entro JRE_DIR/classes, la classe [Link] risulterà essere classe locale e
verrà caricata dal bootstrap class loader.

È possibile riassegnare il valore della proprietà in fase di lancio, ad esempio:

java –D [Link]=<lista personalizzata> –jar [Link]

la proprietà è utilizzata dalla JVM alla sola partenza, successive modifiche non vengono considerate.

2
JRE_DIR qui equivale al valore della proprietà [Link]; nel caso in cui si usi un JDK, in generale essa è
JDK_DIR/jre, ad esempio glassfish3/jdk7/jre, ma non è garantito, dipende dalla configurazione.

pag. 18
Advanced Java rev. 1.0 Novembre 2012

In teoria, ogni classe, una volta che è stata caricata, fornisce il riferimento al class loader che l’ha caricata
mediante il metodo getClassLoader: ClassLoader clsLoader = [Link]().

Tuttavia nel caso in cui sia stata caricata una classe come StringTokenizer, scopro che clsLoader è null:
questo è sempre così, quando una classe è stata caricata dal bootstrap class loader.

Adesso considero un caso di tipo b): Class cls =

[Link]("[Link]"), la classe ZipCoder appartiene a [Link], il quale
si trova in JRE_DIR/lib/ext. Stavolta clsLoader non è null, è invece un’istanza della classe
[Link]$ExtClassLoader, come atteso.

Ciascuna istanza di un class loader ha il metodo getParent, che fornisce il riferimento al class loader che a
sua volta ha caricato l’istanza in questione. Ovviamente non si può applicare alle classi caricate dal bootstap
class loader, essendo clsLoader null. Nel caso del caricamento di ZipCoder, clsLoader è di tipo
[Link]$ExtClassLoader e [Link] è null, infatti il class loader del class loader di
ZipCoder è il bootstrap class loader.

Nel caso b), la proprietà [Link] definisce una lista di directory di estensione, ossia ogni JAR in una
directory di estensione viene considerato locale (cioè, tutte le sue classi sono locali); anche qui, il valore
della proprietà può essere riassegnato alla partenza, come –D [Link]=<lista personalizzata>.

Per quanto concerne il punto c), va ricordato che, nel caso sia stato lanciato un JAR e non una singola
classe, il valore della proprietà [Link] è sempre il path del JAR lanciato, e non è possibile
riassegnarlo tramite l’opzione –D [Link].

In generale tutte le classi che implementano un class loader sono subtipi della classe astratta
[Link], che discende direttamente da Object; è possibile costruire come suoi subtipi dei
class loader applicativi. Comunque il subtipo più importante e versatile è URLClassLoader, è il loader
solitamente usato all’interno del codice applicativo allo scopo di caricare classi contenute in qualche JAR file.

Studio adesso il caso di una classe appartenente a un JAR non caricato dalla JVM, ad esempio penso alla
classe [Link] appartenente a LibJar/[Link]: costruito il class loader loader di
tipo URLClassLoader sul JAR suddetto, carico la classe GestoreCorba con il codice seguente:
Class cls = [Link]("[Link]")

Il suo class loader clsLoader è ovviamente coincidente con loader, quidi è di tipo URLClassLoader; ecco il
resto della catena:
[Link] è di tipo [Link]$AppClassLoader
([Link]).getParent è di tipo [Link]$ExtClassLoader
(([Link]).getParent).getParent è null (bootstrap class loader)

Il caricamento delle classi per istanziazione.

Finora ho studiato il loading di classi caricate nominalmente, non ho studiato il caso dell’istanziazione diretta,
che avviene quando in un’applicazione viene istanziata una variabile di tipo Tipo, appartenente al package p,
mediante un codice come [Link] tipo = new [Link](); tuttavia non ci sono novità: il loading procede come se
si effettuasse [Link](“[Link]”), quindi la classe Tipo viene caricata usando uno dei tre loader, a
meno che non sia usato un loader applicativo.

Come case study, sfrutto una versione ad hoc del progetto Tester: il progetto contiene il package app con la
main class [Link], e anche il package alter, contenente la classe Altra.

Ecco il codice (a blocchi) presente in [Link]:

package app;
final class Dummy {}
public class Prg
{
private class InternalDummy {}
public static void main(String[] args)

pag. 19
Advanced Java rev. 1.0 Novembre 2012

{
...
}
}

Nel metodo main vengono dichiarate alcune variabili, di tipi diversi:

InternalDummy id = (new Prg()).new InternalDummy();
Dummy d = new Dummy();
[Link] altra = new [Link]();
[Link] fake = new [Link]();
String f = "stringa";
[Link] complex = new [Link](3,4);
[Link] fool = new [Link]();

Su tutte queste istanze, applico il metodo getClass per recuperare la classe, poi alla classe applico il metodo
getClassLoader per recuperare il class loader responsabile del caricamento della classe, ad esempio per
l’istanza altra di tipo [Link] scrivo ClassLoader cla = [Link]().getClassLoader(),
quindi stampo [Link]().getName(), e così via per tutte le altre istanze.

Nel build file di Tester, il target <jarGen> include solamente [Link], un JAR accademico prodotto in LibJar,
contenente la classe Fake nel package lib.

La classe [Link] appartiene a [Link], presente in LibJar, che non è inclusa in [Link] né è caricata
esplicitamente dal codice (in altre parole, non uso alcun URLClassLoader entro Tester), ma viene resa
disponibile lanciando [Link] con l’opzione non standard –Xbootclasspath/a:”C:/LibJar/[Link]”.

L’uso dell’opzione verrà meglio indagato nel seguito, per adesso basti dire che essa consente di aggiungere
i JAR in lista al classpath di bootstrap, cioè all’insieme di JAR acceduti dalla JVM alla partenza.

La classe Pinata del package foo appartiene a [Link], un JAR accademico prodotto in LibJar; [Link]
non è caricato da Tester, ma è reso disponibile venendo copiato nella directory C:/ExtLibs, definita directory
d’estensione, al lancio di [Link].

Questo è il comando di lancio, dato in un command prompt posizionato entro ExeJar:

java –[Link]=%JAVA_HOME%/jre/lib/ext;C:/ExtLibs
–Xbootclasspath/a:"C:/LibJar/[Link]" –jar [Link]

ove assegno la proprietà [Link], in modo che comprenda, oltre al path default, anche il percorso
C:/ExtLibs, che quindi diventa directory d’estensione. Qui ipotizzo che %JAVA_HOME%/jre abbia lo stesso
valore della proprietà [Link], il che non è affatto garantito, oppure che %JAVA_HOME%/jre sia
comunque la directory d’estensione da accedere.

Ecco i risultati dell’esecuzione:

Dichiarazione dell’istanza Nome della classe Loader impiegato

InternalDummy id [Link]$InternalDummy [Link]$AppClassLoader

Dummy d [Link] [Link]$AppClassLoader

[Link] altra [Link] [Link]$AppClassLoader

[Link] fake [Link] [Link]$AppClassLoader

String f [Link] bootstrap class loader (il valore di

[Link] è null)

[Link] complex [Link] bootstrap class loader

[Link] fool [Link] [Link]$ExtClassLoader

pag. 20
Advanced Java rev. 1.0 Novembre 2012

Le prime quattro classi sono tutte interne a [Link]; siccome il valore della proprietà [Link] è
[Link], allora tutte le classi di [Link] vengono caricate da [Link]$AppClassLoader,
cioè dal system class loader, in accordo con quanto stabilito al punto c).

I risultati per le variabili di tipo [Link] e [Link] sono in accordo col punto a), dato che la
classe String appartiene a [Link], mentre l’opzione –Xbootclasspath/a fa sì che [Link] venga trattato come un
JAR di sistema, perciò sia String che [Link] sono classi di sistema.

Il risultato per la variabile di tipo [Link] è in accordo con il punto b)..

Uso dell’opzione non standard –Xbootclasspath.

L’opzione non standard –Xbootclasspath del comando java permette di alterare il percorso di ricerca delle
classi di bootstrap. Di particolare interesse è la forma –Xbootclasspath/p:<lista di JAR file>, che antepone i
JAR file in lista (separati dal carattere ‘;‘ se più d’uno) al classpath di bootstrap.

È anche importante la forma –Xbootclasspath/a:<lista di JAR file>, che pospone i JAR file in lista (separati
dal carattere ‘;‘ se più d’uno) al classpath di bootstrap.

La differenza tra le due forme dell’opzione si manifesta quando i JAR presenti in lista contengono classi
omonime di quelle presenti nei JAR che la JVM accede di default alla partenza; ad esempio, suppongo che
Orbacus/lib/[Link] sia uno dei JAR in lista: allora, scrivendo –Xbootclasspath/p, alla partenza
dell’applicazione, quando si richiede il caricamento della classe [Link], viene
usata la classe [Link] di Orbacus e non l’omonima presente in [Link];
scrivendo –Xbootclasspath/a, accade il contrario.

La forma semplice, –Xbootclasspath:<lista di JAR file>, rimpiazza il classpath di bootstrap con i JAR in lista,
come tale è alquanto “estrema” e quindi di utilizzo meno frequente.

Si è già visto l’uso dell’opzione –Xbootclasspath/p a proposito di Corba, ora ne studierò un caso più
personale, anche se totalmente accademico: voglio rimpiazzare la classe [Link] contenuta
in [Link] con una classe omonima da me creata, contenuta in [Link].

Creo il package [Link] entro il progetto Uti, e in esso creo la mia classe StringTokenizer, subtipo di
[Link] come l’originale. La classe originale implementa l’interfaccia Enumerable<Object>, in prima
battuta io non la implemento.

Utilizzerò Tester per provare la mia classe StringTokenizer, partendo da una versione minimale della classe
Prg: le classi Prg e StringTokenizer evolveranno insieme.

Inizialmente Prg consiste del solo main, contenente solamente il codice StringTokenizer st = null.

Tester viene attivato in un command prompt: java –Xbootclasspath/p:”C:/LibJar/[Link]” –jar [Link].

Se la mia classe StringTokenizer non ha almeno tutti i metodi pubblici dell’originale, ci sono errori; ma anche
se li ha tutti, con tutte le giuste signature, ma con implementazioni vuote o troppo semplici (ad esempio
countTokens che ritorna 0), non c’è funzionamento, nemmeno minimale come quello richiesto dalla forma
minimalistica di Prg.

Questo succede perché il bootstrap class loader non si limita a caricare il codice della classe entro la JVM. Il
bootstrap class loader opera in tre fasi: loading, linking e initializing. Il loading è il caricamento del codice
binario della classe entro la JVM; il linking incorpora il codice caricato nello stato runtime della JVM;
l’initializing è l’esecuzione del codice (statico) che compie l’inizializzazione del tipo.

In sintesi, la classe sostitutiva non può essere troppo lontana dalla classe originale.

Allora scrivo una classe StringTokenizer con qualche parvenza di realismo; anche se la classe sostitutiva
funziona diversamente dall’originale, tuttavia presenta analogie:
package [Link];

pag. 21
Advanced Java rev. 1.0 Novembre 2012

public class StringTokenizer

{
private Vector<String> tokens = new Vector<String>();
private int idx = 0;
public StringTokenizer(String s,String delim)
{
for (int i=0;i<[Link]();i++) [Link](s);
idx = -1;
}
public StringTokenizer(String s)
{
for (int i=0;i<[Link]();i++)
[Link]([Link](i,i+1));
idx = -1;
}
public int countTokens()
{
return [Link]();
}
public boolean hasMoreTokens()
{
return ((idx+1) < [Link]());
}
public String nextToken()
{
idx++;
if (idx == [Link]()) return "";
return [Link](idx);
}
public String nextToken(String s)
{
return "";
}
}

Scrivo anche una classe Prg più impegnativa: aggiungo alla classe il metodo statico leggiBuffer, che
restituisce la stringa digitata a tastiera, e riscrivo il metodo main come segue:
public static void main(String[] args)
{
[Link]("Passa: ");
String bu = leggiBuffer();
StringTokenizer st = null;
if ([Link]("x")) st = new StringTokenizer(bu,"x");
else st = new StringTokenizer(bu);
int nTokens = [Link]();
[Link]("nTokens = "+nTokens);
do
{
String f = (String) [Link]();
[Link](f);
}
while([Link]());
}

Confronto il lancio di Tester con o senza l’opzione –Xbootclasspath:

java –jar [Link] java –Xbootclasspath/p:”C:/LibJar/[Link]” –jar [Link]
Passa: uno due Passa: uno due
nTokens = 2 nTokens = 7
uno u
due n
o

pag. 22
Advanced Java rev. 1.0 Novembre 2012

d
u
e

Evidentemente il funzionamento è corretto, è quello atteso.

Posso riscrivere i metodi derivati da Object, ad esempio reimplemento il metodo toString nella mia classe:
@Override
public String toString()
{
return "I'm a fake StringTokenizer";
}

aggiungo l’istruzione [Link](st) in coda al main della classe Prg, e rieseguo:

java –jar [Link] java –Xbootclasspath/p:”C:/LibJar/[Link]” –jar [Link]
Passa: uno due Passa: uno due
nTokens = 2 nTokens = 7
uno u
due n
[Link]@17cf28b o

d
u
e
I’m a fake StringTokenizer

La mia classe non implementa l’interfaccia Enumerable<Object>, a differenza dell’originale, tuttavia il

funzionamento non è inficiato…o meglio, non lo è finchè non chiamo uno dei metodi dell’interfaccia non
implementata: in tal caso, si verifica un’eccezione. Per mostrarlo, aggiungo al metodo main di Prg il codice:
try
{
[Link]();
[Link]("E' stato invocato il metodo hasMoreElements");
}
catch (NoSuchMethodError exc)
{
[Link]("Il metodo hasMoreElements non esiste");
}

Ecco l’esecuzione nei due casi:

java –jar [Link] java –Xbootclasspath/p:”C:/LibJar/[Link]” –jar
... come sopra ... [Link]
... come sopra ...
E’ stato invocato il metodo Il metodo hasMoreElements non esiste
hasMoreElements

La classe sostitutiva può implementare metod pubblici assenti nella classe originale, ad esempio:
public String soloMio()
{
return [Link]()+"-"+[Link]();
}

questo metodo ovviamente è assente nella classe StringTokenizer originale.

Chiamare il metodo soloMio dal codice di Prg è però arduo: il metodo soloMio risulta sconosciuto in fase di
compilazione, scriverlo genera errori in fase di compilazione. Posso però accederlo ricorrendo alla reflection,
aggiungo il codice seguente al metodo main della classe Prg (ometto la gestione degli errori):
// viene recuperato il metodo soloMio, posto che esista
Method m = null;
Class<?>[] ps = { };
try
{

pag. 23
Advanced Java rev. 1.0 Novembre 2012

m = [Link]().getMethod("soloMio", ps);
}
catch (NoSuchMethodException exc)
{
[Link]("Il metodo soloMio non esiste");
return;
}
// se siamo qua, allora il metodo soloMio esiste e quindi posso invocarlo
Object[] vs = { };
[Link]("soloMio = "+(String) [Link](st, vs));

Ecco l’esecuzione nei due casi:

java –jar [Link] java –Xbootclasspath/p:”C:/LibJar/[Link]” –jar
... come sopra ... [Link]
... come sopra ...
Il metodo soloMio non esiste soloMio = u-e

In ultimo, si noti che l’istruzione [Link]() restituisce sempre null, sia che si tratti della
classe originale, sia che si tratti di quella sostitutiva: entrambe vengono caricate dal bootstrap class loader.

Ogni classe appartenente a [Link], anche una classe come [Link], che non ha corrispondenza tra le
classi del runtime Java, è caricabile direttamente – ad esempio, cls =
[Link]("[Link]") – e il loader che la carica è sempre il bootstrap class loader.

Accesso programmatico al JAR manifest.

Mediante il manifest, è possibile scrivere e leggere informazioni concernenti il JAR file al quale il manifest
appartiene (in ogni JAR, è presente al più un manifest); queste informazioni sono di interesse più o meno
grande per le altre applicazioni. Ad esempio, posso specificare in un JAR quale sia la classe di partenza,
mediante l’attributo Main-Class: si tratta di una specificazione importantissima, rivolta alla JVM.

Le informazioni scritte nel manifest vengono chiamate attributi e sono coppie nome/valore, una per riga, con
la sintassi: name: value, ad esempio Main-Class: [Link]. Alcuni di questi attributi, come Main-Class
oppure Implementation-Title, sono riconosciuti da classi del framework Java, ma si possono anche
specificare attributi di fantasia, gestiti da classi applicative e sconosciuti al framework Java.

Scrittura del manifest.

Il manifest può essere scritto in fase di generazione del JAR, oppure essere aggiunto in seguito; è inoltre
possibile modificare il manifest di un JAR, senza bisogno di rigenerare tutto il JAR.

Ad esempio, il plugin ant di Eclipse scrive un default manifest.

Inizio con un progetto Test, accademico, avente un unico package, app, contenente due classi, Maine (col
metodo main) e OtherClass; è presente il file [Link] coi soliti target <clean>, <init>, <compile>, <jarGen>,
tutti minimali. In particolare, <jarGen> è <jar jarfile="[Link]" basedir="build"/>.

Il progetto Test nasce senza alcun manifest esplicitamente definito, tuttavia nel file [Link], generato dal
target <jarGen>, è presente META-INF/[Link] (default manifest):
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.3
Created-By: 1.7.0_07-b11 (Oracle Corporation)

Aggiungo al progetto, nella basedir, il file [Link], che definisce [Link] come Main-Class, e rieseguo
il build; entro [Link] trovo ancora META-INF/[Link], coi seguenti contenuti:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.3
Created-By: 1.7.0_07-b11 (Oracle Corporation)
Main-Class: [Link]

pag. 24
Advanced Java rev. 1.0 Novembre 2012

Di qui in poi, lavorerò in un modo più aderente agli standard, ossia creerò la sottodirectory META-INF entro
la directory build, porrò in essa il manifest, e lo chiamerò [Link]. Inoltre riscrivo il target <jarGen>:
<jar manifest="${build}/META-INF/[Link]" jarfile="[Link]" basedir="build"/>.

Entro [Link] ritrovo lo stesso manifest di cui sopra.

Fin qui, ho scritto il manifest manualmente, ma non è necessario che sia così, infatti un manifest può anche
essere generato servendosi di ant. Aggiungo a [Link] il seguente target:
<target name="manifesto" description="crea il manifest">
<property name="[Link]" value="1.0.0"/>
<tstamp>
<format property="TODAY" pattern="yyyy-MM-dd HH:mm:ss" />
</tstamp>
<manifest file="${build}/META-INF/[Link]">
<attribute name="Built-By" value="${[Link]}" />
<attribute name="Built-Date" value="${TODAY}" />
<attribute name="Implementation-Title" value="Test app" />
<attribute name="Implementation-Vendor" value="Virgilio spa" />
<attribute name="Implementation-Version" value="${[Link]}"/>
<attribute name="Main-Class" value="[Link]"/>
</manifest>
</target>

Gli altri <target> di [Link] restano invariati.

Quindi la sequenza nominale diventa: (clean)initmanifestcompilejarGen, in essa i target <manifest>

e <compile> potrebbero essere invertiti. Stavolta ottengo [Link] con manifest META-INF/[Link]:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.3
Created-By: 1.7.0_07-b11 (Oracle Corporation)
Built-By: RavagliV
Built-Date: 2012-11-09 18:22:42
Implementation-Title: Test app
Implementation-Vendor: Virgilio spa
Implementation-Version: 1.0.0
Main-Class: [Link]

Questa è la generazione programmatica del JAR manifest.

Infine, ci sono casi in cui si dispone del solo JAR, senza avere alcun progetto Eclipse e nemmeno un ant
build file. Questo può essere il caso dei JAR di Orbacus: per essi ho a disposizione i build file, ma preferisco
non modificarli. Come esempio, considero [Link], contenuto in Orbacus/lib: il suo manifest è il
default dovuto alla creazione tramite ant (stavolta ant 1.8.4, non il plugin di Eclipse):
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.4
Created-By: 1.7.0_07-b11 (Oracle Corporation)

Apro [Link] con WinZip o un analogo prodotto, estraggo quindi il manifest, ad esempio come C:\
META-INF\[Link]; poi edito il manifest estratto, e lo modifico come segue:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.4
Created-By: 1.7.0_07-b11 (Oracle Corporation)
Implementation-Title: CosNaming
Implementation-Vendor: Orbacus
Implementation-Version: 4.3.4

Poi riapro [Link] con WinZip, faccio un Add/replace di C:\META-INF/[Link], e

l’aggiornamento è completato; affinché l’operazione d’aggiornamento del manifest funzioni, è necessario che
il JAR non risulti aperto in alcun’altra applicazione.

pag. 25
Advanced Java rev. 1.0 Novembre 2012

Lettura del manifest.

Inizio con un caso piuttosto semplice: aggiungo il manifest al progetto Uti, e lo accedo dal programma
Tester, anch’esso già incontrato come client della libreria [Link].

Il progetto Uti ha (almeno) tre package: num, che contiene la classe Complex; meta, che contiene alcune
annotazioni; [Link], contenente la mia versione della classe StringTokenizer. Il progetto costruisce la
libreria [Link] e la scrive in LibJar.

Aggiungo il manifest a [Link], seguendo la via programmatica: aggiungo a [Link] il tag <manifesto>
(esattamente come sopra) e lo uso nella generazione del JAR, quindi [Link] ha il seguente manifest:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.3
Created-By: 1.7.0_07-b11 (Oracle Corporation)
Built-By: Administrator
Built-Date: 2012-11-10 01:09:35
Implementation-Title: Uti library
Implementation-Vendor: Virgilio spa
Implementation-Version: 1.0.0

Come client di [Link] utilizzo il progetto Tester, adattando di volta in volta la classe [Link] alle esigenze di
test. Comincio con un codice molto semplice, scritto nel metodo main della classe Prg:
Complex nc = new Complex(3,4);
Package pkg = [Link]().getPackage();
[Link]([Link]()+" - "+[Link]());

Per non vedere errori nella IDE di Eclipse, aggiungo [Link] alle Referenced libraries. Fatto ciò, provo a
eseguire il codice direttamente dalla IDE: stando nel codice di [Link] e servendomi del tasto destro, do il
comando Run As  Java Application: ottengo l’output num – Uti library, che è quanto mi aspetto.

Adesso costruisco [Link], usando un build file minimalistico, cioè i soliti target <clean>, <init> etc, e in
particolare il seguente <jarGen>:
<target name="jarGen" description="Compression target">
<jar manifest="[Link]" jarfile="${appname}.jar" basedir="build">
<zipfileset src="${[Link]}/[Link]" />
</jar>
</target>

ove [Link], che è il manifest di [Link], consiste della sola riga Main-Class: [Link].

Apro un command prompt in ExeJar e do il comando: java –jar [Link]. L’output è: num – null, ben
diverso da quello atteso. La spiegazione è semplice: all’esecuzione del target <jarGen>, [Link] è stato
scomposto nelle sue classi e queste, assieme alla classe [Link], sono state aggiunte a [Link]; perciò le
classi come Complex sono diventate, per così dire, classi di [Link]. Il manifest di [Link] è andato perso, e
ciò che viene acceduto dal codice [Link] è il manifest di [Link]; siccome
quest’ultimo non definisce alcun Implementation-Title, allora ne consegue l’output num – null.

Per convincermene, provo ad aggiungere Implementation-Title: Tester app entro [Link], che è il
manifest di Tester, quindi rigenero [Link] e lo rilancio: stavolta ottengo l’output num – Tester app.

Questo risultato apre una problematica generale: per la costruzione di un file [Link] che necessita delle classi
di un altro jar, diciamo [Link], non è sempe consigliabile l’inclusione delle classi di [Link] entro [Link], anzi
sarebbe meglio evitare l’inclusione, quando possibile.

L’alternativa all’inclusione è la definizione di un adeguato classpath, e una delle scelte più potenti e flessibili
è l’utilizzo dell’opzione non standard –Xbootclasspath/a. L’opzione –Xbootclasspath/a:<jarFile> fa sì che,
quando necessario, vengano caricate le classi contenute in <jarFile>, dando però la precedenza ad eventuali
classi omonime contenute nei JAR di sistema; è l’opzione speculare di –Xbootclasspath/p.

Tornando al mio caso, riscrivo il target <jarGen> di Tester eliminando l’inclusione di [Link]:
<target name="jarGen" description="Compression target">

pag. 26
Advanced Java rev. 1.0 Novembre 2012

<jar manifest="[Link]" jarfile="${appname}.jar" basedir="build"/>

</target>

ovviamente java –jar [Link] non funziona più; per lanciare Tester, utilizzo il seguente comando:
java –Xbootclasspath/a:”C:/LibJar/[Link]” –jar [Link]

trovo il risultato atteso, cioè num – Uti library.

Adesso riscrivo il codice di [Link] in modo più complicato, ma interessante perché mostra l’uso delle classi
del framework [Link] e [Link], che rappresentano programmaticamente il
manifest del JAR e i suoi attributi ossia le sue righe:
Complex nc = new Complex(3,4);
URL res = [Link]().getResource([Link]().getSimpleName() +
".class");
JarURLConnection conn = (JarURLConnection) [Link]();
Manifest mf = [Link]();
Attributes attrs = [Link]();
String title = [Link]("Implementation-Title");
Package pkg = [Link]().getPackage();
[Link]([Link]()+" - "+title);

ho omesso la gestione degli errori per brevità. Rigenero [Link] e lo rilancio, sempre usando il comando
java –Xbootclasspath/a:”C:/LibJar/[Link]” –jar [Link]; l’output è ancora num – Uti library.

Notare: provo a tornare alla vecchia forma di <jarGen>, che include [Link]; fatto ciò, rigenero [Link] e lo
lancio col comando java –jar [Link]: ottengo num – Tester, per le ragioni sopra spiegate; invece il lancio
col comando java –Xbootclasspath/a:”C:/LibJar/[Link]” –jar [Link] dà il risultato atteso, però è insensato
includere [Link] se poi si utilizza l’opzione –Xbootclasspath/a !!!

In sintesi, utilizzo l’opzione –Xbootclasspath/a, perchè preferisco generare [Link] senza includere [Link].

Come già detto, questa scelta va ben al di là del caso di Tester e Uti, è di portata generale.

Tutte le applicazioni Corba possono evitare l’inclusione della libreria MyCorbaWorld, a patto di aggiungere
l’opzione –Xbootclasspath/a:”C:/LibJar/[Link]” entro ciascun file di lancio ([Link]).

Uso combinato della lettura del manifest e dell’opzione –Xbootclasspath/p.

Riscrivo il metodo main della classe Prg del progetto Tester:
[Link]._NamingContextStub st = new
[Link]._NamingContextStub();
URL res = [Link]().getResource([Link]().getSimpleName() + ".class");
JarURLConnection conn = (JarURLConnection) [Link]();
Manifest mf = [Link]();
Attributes attrs = [Link]();
String title = [Link]("Implementation-Title");
String vendor = [Link]("Implementation-Vendor");
String version = [Link]("Implementation-Version");
[Link]([Link]().getName()+" - "+title+", "+vendor+",
"+version);

La classe _NamingContextStub è presente in [Link], ma anche in Orbacus/lib/[Link]; ho arricchito il

manifest di [Link] con gli attributi Implementation-Title, Vendor e Version.

Lancio [Link] come java –jar [Link], e ottengo l’output seguente:

[Link]._NamingContextStub – Java Runtime Environment, Oracle Corporation,
1.7.0_07

è stata utilizzata la classe appartenente a [Link].

Adesso uso un altro comando di attivazione:

java –Xbootclasspath/p:”C:/Orbacus/lib/[Link]” –jar [Link]

pag. 27
Advanced Java rev. 1.0 Novembre 2012

e ottengo un output diverso, che indica l’uso della classe Orbacus:

[Link]._NamingContextStub – CosNaming, Orbacus, 4.3.4

Faccio ancora un esempio, che implica la riscrittura di [Link]:

StringTokenizer st = new StringTokenizer("123");
URL res = [Link]().getResource([Link]().getSimpleName() + ".class");
JarURLConnection conn = (JarURLConnection) [Link]();
Manifest mf = [Link]();
Attributes attrs = [Link]();
String title = [Link]("Implementation-Title");
String vendor = [Link]("Implementation-Vendor");
String version = [Link]("Implementation-Version");
[Link]([Link]().getName()+" - "+title+", "+vendor+",
"+version);

La classe [Link] fa parte di [Link], ma anche di [Link].

Lancio [Link] come java –Xbootclasspath/a:”C:/LibJar/[Link]” –jar [Link], e ottengo l’output seguente:
[Link] – Java Runtime Environment, Oracle Corporation,
1.7.0_07

è stata utilizzata la classe appartenente a [Link] (avrei avuto lo stesso risultato con java –jar [Link]).

Lancio [Link] come java –Xbootclasspath/p:”C:/LibJar/[Link]” –jar [Link], e ottengo l’output seguente:
[Link] – Uti library, Virgilio spa, 1.0.0

qui è evidente l’utilizzo della classe appartenente a [Link].

Manifest di MyCorbaWorld e modifiche all’oggetto ServerSistema.

Finora non ho definito alcun manifest per la libreria LibJar/[Link], creata dal progetto omonimo;
adesso però aggiungo il tag <manifesto> nel build file del progetto, in modo da ottenere il manifest seguente:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.3
Created-By: 1.7.0_07-b11 (Oracle Corporation)
Built-By: Administrator
Built-Date: 2012-11-10 01:06:39
Implementation-Title: MyCorbaWorld library
Implementation-Vendor: Virgilio spa
Implementation-Version: 2.1.0

La classe GestoreCorba ha il vettore di stringhe, statico, AppContextInfo, che viene popolato all’interno del
metodo CatchNamespace:
Class c = [Link]();
Package p = [Link]().getPackage();
URL res = [Link]([Link]() + ".class");
JarURLConnection conn = (JarURLConnection) [Link]();
Manifest mf = [Link]();
Attributes attrs = [Link]();
String title = [Link]("Implementation-Title");
String vendor = [Link]("Implementation-Vendor");
String version = [Link]("Implementation-Version");
String pkg = [Link]();
[Link]("RootNS: Class="+[Link]()+", Package="+pkg);
[Link]("Text(RootNS)="+[Link]());
c = [Link]();
pkg = [Link]().getPackage().getName();
[Link]("VirgoSpace: Class="+[Link]()+", Package="+pkg);
[Link]("Text(VirgoSpace)="+[Link]());
[Link]("Package "+ pkg +": Title="+title+",Vendor="+vendor+
",Version="+version);

Modifico anche una parte del codice del metodo SystemInfo dell’oggetto ServerSistema:

pag. 28
Advanced Java rev. 1.0 Novembre 2012

... parte invariata ...

[Link]("Me type: "+[Link]().getName());
URL res = [Link]().getResource([Link]().getSimpleName() +
".class");
JarURLConnection conn = (JarURLConnection) [Link]();
Manifest mf = [Link]();
Attributes attrs = [Link]();
String title = [Link]("Implementation-Title");
String vendor = [Link]("Implementation-Vendor");
String version = [Link]("Implementation-Version");
String tStamp = [Link]("Built-Date");
[Link]("...belonging to "+title+" rev. "+version);
[Link]("...created by "+vendor+" on "+tStamp);
... parte invariata ...

Ecco il risultato (il client è Fenester):

ho ritagliato solo la parte d’interesse della window.

Serializzazione di oggetti Java.

In Java, si dice stream un flusso sequenziale di byte, utilizzato da un oggetto; dal punto di vista dell’oggetto,
si parla di input stream quando l’oggetto riceve un flusso sequenziale di byte da una sorgente (un file, un
socket, la tastiera etc), mentre si parla di output stream quando l’oggetto invia un flusso sequenziale di byte
verso una destinazione (un file, un socket, il video etc).

Si dice che l’oggetto legge da un input stream e scrive su un output stream.

Serializzare un oggetto significa trasformarlo in una sequenza di byte: dato un certo codice, si dice che esso
serializza un oggetto Obj (istanza di una certa classe) quando trasforma l’oggetto in una sequenza ordinata
di byte e scrive la sequenza su un output stream.

Il processo inverso si chiama deserializzazione: dato un certo codice, si dice che esso deserializza un oggetto
Obj quando legge una sequenza ordinata di byte da un input stream e se ne serve per (ri)generare l’oggetto
Obj, completo del proprio stato.

In senso proprio, serializzazione è il passaggio da oggetto (comprensivo del proprio stato) a sequenza
statica, ordinata, di byte; tuttavia il termine serializzazione spesso indica sia la serializzazione in senso
proprio sia la deserializzazione.

pag. 29
Advanced Java rev. 1.0 Novembre 2012

La serializzazione gioca un ruolo fondamentale nella comunicazione tra oggetti remoti.

Siano P1 e P2 due processi distinti, ciascuno con la propria JVM – JVM 1 e JVM2 rispettivamente, e siano O1 e
O2 due oggetti, appartenenti rispettivamente a P1 e P2: i due oggetti si dicono (reciprocamente) remoti.

Quando O1 chiama un metodo di O 2, si parla di comunicazione tra oggetti remoti: essa implica uno scambio
di oggetti tra le due JVM; dico Ω uno di questi oggetti scambiati. La JVM 1 serializza Ω, cioè trasforma Ω in
una sequenza ordinata ∑ di byte e scrive la sequenza ∑ su un output stream device del processo P 1,
tipicamente un socket; quest’ultimo comunica (a basso livello) con un input stream device del processo P 2
(tipicamente, un altro socket): la JVM2 deserializza ossia legge dall’input stream la sequenza ∑ di byte e la
trasforma nell’oggetto Ω, cioè in un oggetto dello stesso tipo e con lo stesso stato di Ω.

Oltre al remoting, la serializzazione è di grande importanza anche in molti altri processi, ad esempio nei
database object relational.

Approccio programmatico alla serializzazione: l’applicazione Serial.

L’applicazione Serial è un’applicazione console, creata in ExeJar tramite un omonimo Java project; il
progetto Serial contiene il package app, con la sola classe Maine, dotata di metodo main. Il metodo main
compie la maggior parte del lavoro; utilizza la classe MultiUso di [Link], in particolare usa i metodi (statici)
leggiBuffer, per leggere una stringa da tastiera, e hexDump, che mostra a video un array di byte in
notazione esadecimale.

Il build file ha la solita struttura clean  init  compile  jarGen  copy; il tag <jarGen> include la libreria
LibJar/[Link]. Questa libreria è anche configurata nel build path.

Il codice di [Link] inizia chiedendo il passaggio (da tastiera) del nome di una classe; il nome va inteso
completo del package, ad esempio [Link] oppure [Link] o [Link]. La classe Serianda
e il suo subtipo XSerianda, appartenenti al package mix, sono state introdotte ad hoc nel progetto Uti per
studiare la serializzazione; in seguito fornirò dettagli su queste classi.

Il nome della classe è stato assegnato alla variabile nmCls di tipo String; se la classe è locale, allora posso
istanziarla direttamente, se invece la classe è esterna devo usare la reflection… non fa differenza, nel
seguito per semplicità assumo che le classi siano locali, ecco quindi il codice:
Object obj = null;
switch (nmCls)
{
case "[Link]":
obj = new Complex(0.5,-1);
break;
case "[Link]":
obj = new XSerianda("Virgilio",53,7.45);
break;
... altre classi ...
default:
[Link]("Non so come trattare questa classe");
return;
}

Segue il codice di serializzazione:

ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
try
{

pag. 30
Advanced Java rev. 1.0 Novembre 2012

[Link](obj);
}
catch (NotSerializableException e)
{
[Link]("Classe non serializzabile");
return;
}
byte[] bSerial = [Link]();
ho lasciato solo la parte cruciale della gestione degli errori.

L’oggetto obj è tipato in base alla classe scelta, nonostante la dichiarazione di obj come oggetto generico (è
l’istanziazione a determinare il tipo di obj, e l’istanziazione è sempre tipata).

Subtipi della classe OutputStream e codice di serializzazione.

Dal punto di vista programmatico, ogni output stream è un subtipo della classe astratta
[Link], che discende direttamente da Object; le classi [Link] e
[Link] Stream sono subtipi (diretti) della classe OutputStream.

L’operazione fondamentale di un output stream è la scrittura di una sequenza di byte; essendo

OutputStream una classe astratta, ogni suo subtipo deve implementare almeno un metodo write.

La serializzazione dell’oggetto obj consiste nella scrittura dell’oggetto su un output stream di tipo
particolare, predisposto proprio alla serializzazione di oggetti, ossia un’istanza della classe ad hoc
ObjectOutputStream: il nocciolo della serializzazione dell’oggetto obj è l’istruzione [Link](obj).

La classe ObjectOutputStream dispone di vari metodi di scrittura: come ogni subtipo di OutputStream, ha il
metodo write, con svariate signature; ha il metodo writeObject, per scrivere un oggetto dato; e inoltre ha
metodi che consentono la scrittura di vari tipi primitivi, ad esempio [Link](db) con db di tipo
double, e altri come writeLong, writeInt etc.

L’unico costruttore pubblico della classe ObjectOutputStream vuole sempre come parametro di input un
oggetto di tipo OutputStream; si può interpretare ciò come la necessità da parte dell’istanza oos di un
output stream sottostante. Dato che la serializzazione è la trasformazione dell’oggetto in una sequenza di
byte, la scelta scontata è un’istanza del tipo ByteArrayOutputStream.

Questo spiega il codice di serializzazione: prima di tutto creo baos, un’istanza di ByteArrayOutputStream,
poi creo l’istanza oos di ObjectOutputStream, costruita sopra baos. Fatto ciò, si può serializzare l’oggetto
utilizzando il metodo writeObject.

La sequenza di byte che rappresenta l’oggetto obj è recuperabile mediante l’istruzione [Link],
che copia tutto il contenuto corrente di baos entro un byte array creato sul momento, cioè bSerial.

Osservazione importantissima: la scelta di un oggetto di tipo ByteArrayOutputStream come supporto

all’oggetto di tipo ObjectOutputStream non è affatto la migliore possibile, in quanto può creare gravi
problemi quando si utilizzano istruzioni di serializzazione di tipi primitivi come writeInt. Questo punto verrà
affrontato nel seguito; l’uso di ByteArrayOutputStream non ha controindicazioni finchè il codice si limita
all’uso del metodo writeObject.

Ereditarietà della serializzabilità di una classe.

All’interno del progetto Uti, la classe Serianda è la seguente:
package mix;
public class Serianda

pag. 31
Advanced Java rev. 1.0 Novembre 2012

{
String stringa = null;
int intero = 0;
double doppio = 0;
public Serianda(String s,int n,double d)
{
stringa = s;
intero = n;
doppio = d;
}
@Override
public String toString()
{
return "Serianda instance: stringa = "+ stringa+" - "+
"intero = "+intero+" - "+"double = "+doppio;
}
}
Suppongo di lanciare Serial, come java –jar [Link], e quindi passargli [Link]: l’istruzione
[Link] genera un’eccezione di tipo NotSerializableException.

Infatti, affinchè un oggetto sia serializzabile, è necessario che la classe della quale l’oggetto è un’istanza,
implementi l’interfaccia Serializable, oppure sia subtipo di una classe che implementa Serializable:
package mix;
public class Serianda implements [Link]
{
...
}
L’interfaccia Serializable non ha metodi, è solo una specie di monito per il framework Java, lo informa della
serializzabilità della classe in questione. Allora, impongo che anche [Link] e tutte le altre classi che
intendo utilizzare nella serializzazione implementino l’interfaccia Serializable.

Quando una classe implementa l’interfaccia Serializable, dovrebbe definire un identificativo univoco detto
SerialVersionUID; la IDE di Eclipse lo ricorda, e se esso non viene definito, la piattaforma lo crea; a breve
mostrerò il procedimento con cui è possibile scegliere il valore da assegnare alla classe.

Per ragioni che spiegherò nel seguito, userò come prototipo di classe da serializzare non Serianda, ma il suo
subtipo XSerianda, definito come segue:
package mix;
public class XSerianda extends Serianda
{
private static final long serialVersionUID = 1066L;
private short tag = 12000;
private char car = 'w';
public XSerianda(String s,int n,double d)
{
super(s,n,d);
}
@Override
public String toString()
{
return [Link](tag)+[Link](car)+":X"+[Link]();
}
}

pag. 32
Advanced Java rev. 1.0 Novembre 2012

la classe XSerianda è implicitamente serializzabile (cioè, non va dichiarata tale) perché è subtipo di una
classe, Serianda, che è stata esplicitamente dichiarata serializzabile 3. Anche qui, la IDE mi ha avvertito della
necessità di definire il SerialVersionUID; per farlo, bisogna dichiarare il membro statico di tipo long e nome
serialVersionUID, quindi lo si può valorizzare come si crede.

Scelgo il valore 1066 per il SerialVersionUID della classe XSerianda; nel caso di Serianda, ho usato l’attributo
@SuppressWarnings("serial"), lasciando al sistema la scelta del valore.

Dump degli oggetti serializzati e scrittura permanente.

La sequenza di byte contenuta nella variabile bSerial rappresenta l’istanza serializzata, ad esempio l’istanza
della classe [Link], creata come new XSerianda("Virgilio",53,7.45). Il codice successivo
del metodo main mostra la sequenza a video: hexDump(bSerial,[Link]), il valore di ciascun
byte è visualizzato in notazione esadecimale su due cifre.

Inoltre la sequenza di byte viene anche scritta su un file:

FileOutputStream fos = new FileOutputStream(nmCls+".obj");
[Link](b);
[Link]();
il file, nell’esempio [Link], viene generato nella directory ExeJar in cui viene lanciato Serial;
nell’esempio, trovo il file ExeJar/[Link]. Si tratta di un file binario.

Approccio programmatico alla deserializzazione: l’applicazione Deserial.

L’applicazione Deserial è un’applicazione console, creata in ExeJar tramite un omonimo Java project; il
progetto Deserial contiene il package app, con la sola classe Maine, dotata di metodo main. Il metodo main
compie la maggior parte del lavoro Il metodo main compie la maggior parte del lavoro; utilizza la classe
MultiUso di [Link], in particolare usa i metodi (statici) leggiBuffer, per leggere una stringa da tastiera, e
hexDump, che mostra a video un array di byte in notazione esadecimale.

Il build file ha la solita struttura clean  init  compile  jarGen  copy; il tag <jarGen> non include
alcuna libreria, mentre nel build path è configurata [Link] per ragioni di compilazione.

In generale, lancio Deserial come java –Xbootclasspath/a:” LibJar/[Link]” –jar [Link].

Il codice di [Link] inizia chiedendo il passaggio (da tastiera) del nome di una classe; il nome va inteso
completo del package, ad esempio [Link], e viene passato entro la variabile stringa nmCls. Il nome
del file da accedere, contenuto nella variabilestringa nmFile, viene costruito aggiungendo “.obj” al nome
della classe: ad esempio, [Link]; la directory è C:/Serials.

Posto che il file esista (altrimenti il programma termina), ne viene letta la lunghezza entro la variabile intera
fLen, quindi viene creata la variabile byte[] bSerial = new byte[fLen]. Queste operazioni servono
allo scopo di allocare un byte array della lunghezza giusta per ospitare la sequenza contenuta nel file; la
lettura effettiva viene compiuta dal seguente codice:
FileInputStream fis = new FileInputStream(nmFile);
[Link](bSerial);
[Link]();
poi viene mostrata la sequenza a video: hexDump(bSerial,[Link]), il valore di ciascun byte
è visualizzato in notazione esadecimale su due cifre.

Segue il codice di deserializzazione:

3
Se una classe C implementa l’interfaccia I, allora anche i subtipi di C implementano I, senza bisogno di
dichiararlo esplicitamente.
pag. 33
Advanced Java rev. 1.0 Novembre 2012

fis = new FileInputStream(bSerial);

ObjectInputStream ois = new ObjectInputStream(fis);
Object obj = null;
try
{
obj = [Link]();
}
catch (InvalidClassException e)
{
[Link]("La classe " +nmCls + " non e' (de)serializzabile");
return;
}
[Link]();
[Link]();

ho lasciato solo la parte cruciale della gestione degli errori.

Subtipi della classe InputStream e codice di deserializzazione.

Dal punto di vista programmatico, ogni input stream è un subtipo della classe astratta [Link],
che discende direttamente da Object; le classi [Link] e [Link] Stream sono
subtipi (diretti) della classe InputStream.

L’operazione fondamentale di un input stream è la lettura di una sequenza di byte; essendo InputStream
una classe astratta, ogni suo subtipo deve implementare almeno un metodo read.

La deserializzazione dell’oggetto obj consiste nella lettura della sequenza di byte rappresentativa
dell’oggetto precedentemente serializzato da un input stream di tipo particolare, predisposto proprio alla
deserializzazione di oggetti, ossia un’istanza della classe ad hoc ObjectInputStream: il nocciolo della
deserializzazione dell’oggetto obj è l’istruzione obj = [Link]().

La classe ObjectInputStream dispone di vari metodi di lettura: come ogni subtipo di InputStream, ha il
metodo read, con svariate signature; ha il metodo readObject, per leggere un oggetto; e inoltre ha metodi
che consentono la lettura di vari tipi primitivi, ad esempio db = [Link]() con db di tipo double, e
altri come readLong, readInt etc.

L’unico costruttore pubblico della classe ObjectInputStream vuole sempre come parametro di input un
oggetto di tipo InputStream; si può interpretare ciò come la necessità da parte dell’istanza ois di un input
stream sottostante. Questo spiega il codice di deserializzazione: prima di tutto creo fis, un’istanza di
FileInputStream agganciata al file contenente l’oggetto serializzato, poi creo l’istanza ois di
ObjectInputStream, costruita sopra fis. Fatto ciò, si può deserializzare l’oggetto utilizzando il metodo
readObject: dopo questa istruzione, l’oggetto è pronto.

Si noti che avevo già usato l’oggetto fis per leggere il contenuto del file nmFile, in modo da poter mostrare il
dump a video; siccome l’oggetto fis rappresenta uno stream sequenziale, non dotato di possibilità di rewind
o riposizionamento, trovandomi in fondo al file ho dovuto ricreare fis, in modo da ripartire dall’inizio dei
dati nel file.

Nel codice, segue l’istruzione:

[Link]("Istanza di "+[Link]().getName() + ": "+obj);
supponendo che sia stato letto il file [Link], il risultato è il seguente:
Istanza di [Link]: 12000w:XSerianda instance: stringa = Virgilio – intero = 53 – double = 7.45

l’oggetto di tipo [Link] è stato ricostruito con lo stato che aveva all’atto della serializzazione.

Notare: non ho usato un oggetto di tipo ByteArrayInputStream, qui non avrebbe avuto senso, dato che
dispongo già della sequenza di byte, letta dal file entro bSerial.

pag. 34
Advanced Java rev. 1.0 Novembre 2012

Limitazioni alla deserializzabilità.

Considero un JAR non appartenente al default path della JVM, ad esempio [Link] in LibJar; ha la classe
[Link]. Posso serializzare un oggetto della classe Pinata con l’applicazione Serial, ricorrendo alla
reflection: usando un oggetto di tipo URLClassLoader, carico la classe e poi, servendomi di un suo
costruttore, creo un’istanza, che serializzo nel file C:/Serials/[Link].

Tuttavia la deserializzazione fallisce: l’esecuzione dell’istruzione [Link]() genera l’eccezione di

tipo ClassNotFoundException. In effetti, si scopre che ciò accade ogni volta che la classe non appartiene a
un JAR situato sul default path della JVM.

Si noti che non c’è alcun errore, ossia la creazione dell’oggetto di tipo [Link] va a buon fine, attivando
Deserial con il comando java –Xbootclasspath/a:” LibJar/[Link];LibJar/[Link]” –jar [Link], infatti ciò
equivale a porre [Link] sul default path della JVM.

Il problema nasce dal modo di operare del metodo readObject: questo legge il nome della classe all’interno
della sequenza di byte ricevuta in input e cerca tale classe o all’interno del JAR corrente (qui, [Link]),
oppure nei JAR che incontra nel default path della JVM. L’uso dell’opzione –Xbootclasspath aggiunge il JAR
referenziato nel default path, quindi risolve il problema aggirando l’ostacolo.

Una soluzione migliore sarebbe la costruzione di un subtipo della classe ObjectInputStream, modificando il
codice del metodo readObject, tuttavia è al di là dei miei attuali scopi.

Il protocollo di serializzazione.
Supponendo d’aver serializzato l’istanza di [Link], new XSerianda("Virgilio",53,7.45),
ecco il dump della sequenza di byte rappresentativa, visualizzata da hexDump:
AC ED 00 05 73 72 00 0D 6D 69 78 2E 58 53 65 72
69 61 6E 64 61 00 00 00 00 00 00 04 2A 02 00 02
43 00 03 63 61 72 53 00 03 74 61 67 78 72 00 0C
6D 69 78 2E 53 65 72 69 61 6E 64 61 63 B0 64 D4
33 22 89 AF 02 00 03 44 00 06 64 6F 70 70 69 6F
49 00 06 69 6E 74 65 72 6F 4C 00 07 73 74 72 69
6E 67 61 74 00 12 4C 6A 61 76 61 2F 6C 61 6E 67
2F 53 74 72 69 6E 67 3B 78 70 40 1D CC CC CC CC
CC CD 00 00 00 35 74 00 08 56 69 72 67 69 6C 69
6F 00 77 2E E0

Si parla di protocollo di serializzazione per indicare le regole e le modalità con cui il processo di
serializzazione trasforma un certo oggetto in una sequenza di byte.

Osservazione importante: lo studio in corso si basa in larga misura sull’esempio della classe [Link] e
come tale non copre tutte le possibilità, esistono sequenze diverse, nelle quali compaiono campi non
trattati nel mio studio; tuttavia quanto esposto costituisce un buon punto di partenza, un ragionevole
compromesso tra concretezza e generalità.

Si tenga anche in conto la possibilità di serializzare entità diverse dall’istanza di una classe: posso
serializzare tipi primitivi, array, anche la sola costante null. In ogni caso, la serializzazione dell’istanza di una
classe è il caso più importante, e per la sua frequenza, e perché essa costituisce la serializzazione di base, e
la serializzazione di altre entità, come gli array, può essere spiegata solo dopo aver chiara la prima.

Tornerò in seguito sulla serializzazione di dati primitivi e array.

pag. 35
Advanced Java rev. 1.0 Novembre 2012

Dettagli sulla serializzazione dell’istanza di una classe.

Premetto che, data una classe Cls, dico che essa ha supertipi non banali quando almeno uno dei suoi
supertipi è diverso da [Link].

In generale, la sequenza descrittiva dell’istanza obj della classe Cls, avente uno o più supertipi non banali,
può essere così schematizzata:
a) sottosequenza iniziale costituita dai byte AC ED 00 05
b) descrizione della classe Cls, sempre iniziata dai byte 73 72 e terminata da 78
c) descrizione di tutti i supertipi, banale incluso: è sempre iniziata dal byte 72 e terminata dal byte 70
se la classe Cls ha almeno un supertipo non banale, altrimenti consiste del solo byte 70
d) rappresentazione dello stato dell’istanza obj.

La classe [Link] ha il supertipo [Link], che a sua volta ha come supertipo solamente Object.

Nella sottosequenza iniziale, i primi due byte, AC ED, sono detti stream magic; i due byte a seguire, detti
stream version, identificano la versione del protocollo di serializzazione: in Java 1.7 la versione utilizzata è 5.

La sottosequenza iniziale è sempre la stessa, qualunque sia l’entità serializzata; non è così per i byte a
seguire, ad esempio se avessi serializzato un array, nel quinto byte troverei un valore diverso da 73.

Il valore 0x73 = TC_OBJECT dice che l’entità serializzata è un oggetto in senso proprio, cioè l’istanza di una
classe, e la descrizione della classe inizia sempre col byte 0x72 = TC_CLASSDESC.

Lo schema precedente vale per la serializzazione dell’istanza di una qualsiasi classe; tuttavia il dettaglio dei
campi nelle sezioni b), c) e d) dipende dalle particolarità della classe Cls e dai particolari valori assunti nello
stato dell’istanza obj.

Nel seguito mostrerò un caso, particolare ma paradigmatico, cioè l’insieme dei campi dell’istanza della
classe [Link] creata come new XSerianda("Virgilio",53,7.45):
esempio di [Link] Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC
00 0D Lunghezza del nome della classe
6D 69 78 2E 58 53 65 72 69 61 6E 64 61 Nome (completo) della classe: [Link]
00 00 00 00 00 00 04 2A SerialVersionUID: 1066
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 02 Numero di campi (XSerianda ha 2 campi)
43 Tipo del primo campo: ‘C’ – character
00 03 Lunghezza del nome del primo campo
63 61 72 Nome del primo campo: car
53 Tipo del secondo campo: ‘S’ – short
00 03 Lunghezza del nome del secondo campo
74 61 67 Nome del secondo campo: tag
78 Terminatore: TC_ENDBLOCKDATA
Descrizione del supertipo
72 TC_CLASSDESC
00 0C Lunghezza del nome della classe

pag. 36
Advanced Java rev. 1.0 Novembre 2012

6D 69 78 2E 53 65 72 69 61 6E 64 61 Nome (completo) della classe: [Link]

63 B0 64 D4 33 22 89 AF SerialVersionUID
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 03 Numero di campi (Serianda ha 3 campi)
44 Tipo del primo campo: ‘D’ – double
00 06 Lunghezza del nome del primo campo
64 6F 70 70 69 6F Nome del primo campo: doppio
49 Tipo del secondo campo: ‘I’ – integer
00 06 Lunghezza del nome del secondo campo
69 6E 74 65 72 6F Nome del secondo campo: intero
4C Tipo del terzo campo: ‘L’ – object
00 07 Lunghezza del nome del terzo campo
73 74 72 69 6E 67 61 Nome del terzo campo: stringa
Descrizione del tipo del terzo campo
74 TC_STRING
00 12 Lunghezza del nome
4C 6A 61 76 61 2F 6C 61 6E 67 2F 53 74
72 69 6E 67 3B Nome: Ljava/lang/String;
78 Terminatore: TC_ENDBLOCKDATA
70 TC_NULL
Stato dell’istanza
40 1D CC CC CC CC CC CD Valore del campo doppio: 7.45
00 00 00 35 Valore del campo intero: 53
Valore del campo stringa
74 TC_STRING
00 08 Lunghezza del dato
56 69 72 67 69 6C 69 6F dato: Virgilio
00 77 Valore del campo car: w
2E E0 Valore del campo tag: 12000

I valori STREAM_MAGIC, STREAM_VERSION, TC_OBJECT, TC_CLASSDESC etc, sono tutti definiti

nell’interfaccia [Link]: ObjectStreamConstants.STREAM_MAGIC, detto
semplicemente STREAM_MAGIC; ObjectStreamConstants.STREAM_VERSION, detto semplicemente
STREAM_VERSION; etc.

Descrizione della classe.

La descrizione della classe di cui l’oggetto è istanza inizia sempre con il byte 0x72 = TC_CLASSDESC.

Oltre al nome in chiaro, fa parte della descrizione anche l’identificativo univoco della classe,
SerialVersionUID; nel caso della classe XSerianda, ho assegnato io il valore, 1066.

Segue un byte, chiamato flag, che contiene alcuni attributi descrittivi della classe; per i miei scopi, questo
campo contiene sempre il solo valore SC_SERIALIZABLE, che ribadisce la natura serializzabile della classe.

A questo punto segue la lista descrittiva dei campi della classe: prima c’è il numero dei campi (su 4 byte),
poi la descrizione di ciascun campo. I campi sono ordinati in ordine alfabetico.

Il carattere 0x78 = TC_ENDBLOCKDATA funge da terminatore della descrizione della classe.

Descrizione del supertipo.

Nell’esempio, la classe [Link] ha un solo supertipo non banale; esaminerò a breve anche i casi di
classi con più di un supertipo non banale e di classi senza alcun supertipo non banale.

pag. 37
Advanced Java rev. 1.0 Novembre 2012

La descrizione del supertipo, nell’esempio la classe [Link], è la descrizione di una classe e quindi vale
quanto detto sopra, né più né meno. Il supertipo di [Link] è [Link], quindi la catena dei
supertipi di [Link] finisce qui: la serializzazione di [Link] si traduce nella scrittura sullo
stream del byte 0x70 = TC_NULL. Siccome Object è il supertipo finale di ogni classe, e la sezione descrittiva
dei supertipi comprende tutti i supertipi, allora la descrizione dei supertipi termina sempre con 0x70.

Il caso di una classe senza alcun supertipo non banale è immediato: la sezione del supertipo consiste del
solo byte 0x70 = TC_NULL, a seguito del byte 0x78 che chiude la descrizione della classe; in questo caso,
non c’è alcun byte 0x72 ad iniziare la descrizione dei supertipi.

Supponiamo che una classe abbia più di un supertipo non banale: detta C una classe con due supertipi non
banali, posso rappresentare la catena della sua ereditarietà come [Link]  T1  T2  C, ove T1 e
T2 sono i supertipi in cascata di C.

Serializzando un’istanza di C, posso schematizzare a blocchi la struttura che ne risulta:

serializzazione di Cls sezioni

AC ED 00 05 73 STREAM_MAGIC & STREAM_VERSION & TC_OBJECT
72 ... 78 Descrizione della classe Cls
72 ... 78 Descrizione del supertipo T2
72 ... 78 Descrizione del supertipo T1
70 TC_NULL
Stato dell’istanza:
Valori dei campi ereditati da T2 (in ordine alfabetico)
Valori dei campi ereditati da T1 (in ordine alfabetico)
Valori dei campi propri della classe Cls (in ordine alfabetico)

È immediata l’estensione dello schema al caso di classi con n > 2 supertipi non banali. Questa struttura a
blocchi è del tutto equivalente alla struttura in proposizioni già esposta.

Segue la descrizione formale dei campi, che è la stessa per la classe come per i supertipi. Nel caso di una
classe priva di campi, viene scritto 00 00 sull’output stream e, di seguito, il byte 0x78 che pone fine alla
descrizione della classe in questione.

Descrizione dei campi di una classe.

La descrizione del campo di una classe può essere così schematizzata:
i) tipo: è un carattere, vale ‘C’ (cioè 0x43) per un character, ‘S’ (0x53) per un short (intero a 16
bit), ‘D’ (0x44) per un double, e altri valori per altri tipi primitivi; se invece il campo è una classe,
allora vale ‘L’ (0x4C), mentre vale ‘[‘ (0x5B) se il campo è un array
ii) lunghezza del nome, su due byte
iii) nome
iv) se il tipo del campo non è primitivo: nome del tipo in notazione JVM.

I campi tag e car della classe XSerianda, e anche i campi doppio e intero della classe supertipo Serianda,
hanno tipi primitivi, perciò la loro descrizione consiste di tre sole informazioni: tipo, lunghezza del nome e
valore del nome.

Il campo stringa della classe Serianda è invece trattato come un oggetto, il suo tipo è 0x4C, e infatti per esso
è passato il nome del tipo, cioè [Link], scritto però nella notazione utilizzata dalla JVM, ossia
Ljava/lang/String;.

Studierò altri esempi nel seguito, tra i quali campi definiti come array.

pag. 38
Advanced Java rev. 1.0 Novembre 2012

Descrizione dello stato dell’istanza serializzata.

Lo stato dell’istanza è costituito dai valori dei campi dell’istanza all’atto della serializzazione, quindi
compaiono tante descrizioni dei valori quante sono le descrizioni dei campi.

Se il campo è di tipo primitivo, ad esempio double oppure integer, viene semplicemente scritto il suo
valore4; quando il campo è di tipo object, la struttura del valore è più complessa.

Nell’esempio di XSerianda, il campo stringa di tipo String (ereditato dal supertipo Serianda) ha valore scritto
in notazione stream protocol, tuttavia la sua struttura è peculiare del tipo String, per altri tipi la struttura è
diversa, come si vedrà nel seguito.

Serializzazione di tipi primitivi.

In Java, i tipi primitivi sono otto: byte, short, int, long, float, double, boolean, char; il tipo String non è
invece un vero tipo primitivo, anche se spesso viene ritenuto tale.

I tipi primitivi non sono classi e quindi una variabile primitiva non è un oggetto, infatti scrivendo int x = 10,
la variabile x contiene il valore 10, mentre scrivendo String s = “Virgilio”, la variabile s non contiene il valore,
ma contiene l’indirizzo (il reference) in cui si trova il valore.

I tipi primitivi dispongono di una pseudoclasse: l’istruzione Class cls = [Link] restituisce un
oggetto cls non null, tuttavia applicando la reflection scopro che la classe cls ha package null, nessun
costruttore, nessun metodo e nessun campo, e nemmeno alcun supertipo, neppure [Link], ma ha
solo un nome, infatti l’istruzione [Link] restituisce la stringa boolean.

Osservazione importante: i tipi primitivi possono essere serializzati nativamente, cioè non come oggetti,
usando i metodi appositi della classe ObjectOutputStream, come writeInt, writeDouble etc. È anche
possibile serializzare una variabile di tipo primitivo come se fosse un oggetto, servendosi ancora del metodo
[Link], tornando così al caso di serializzazione dell’istanza di una classe. I due
procedimenti di serializzazione danno risultati diversi.

Serializzazione nativa di un tipo primitivo.

Il caso di serializzazione nativa di tipi primitivi è, per i miei scopi, meno interessante della serializzazione dei
tipi primitivi come oggetti, per cui mi limito a illustrarlo attraverso un esempio; nel seguito, parlando di
serializzazione di tipi primitivi senza ulteriori specificazioni, intenderò sempre serializzazione di tipi primitivi
trattati come oggetti.

Nel caso nativo, anche il codice, sia di serializzazione sia di deserializzazione, è un po’ diverso; il frammento
seguente mostra come serializzare nativamente una variabile di tipo double:
FileOutputStream fos = new FileOutputStream(nmFile);
ObjectOutputStream oos = new ObjectOutputStream(fos);
double reale = 7.45;
[Link](reale);
[Link]();
[Link]();

la gestione degli errori è stata omessa per semplicità; è importantissimo ricordarsi di chiudere l’oggetto
ObjectOutputStream (oos) prima di terminare l’applicazione5 !

Si noti che non è stato usato il tipo ByteArrayOutputStream come substrato per l’oggetto oos, il suo
impiego avrebbe comportato errori; l’utilizzo del tipo FileOutputStream consente di serializzare sia oggetti,
sia tipi primitivi nativamente, nonché un misto dei due.

4
Il formato del valore che viene scritto non ha nulla a che fare con la notazione dello stream protocol. Ad esempio, il
double 7.45 ha rappresentazione binaria 40 1D CC CC CC CC CC CD, e tale è il suo valore, scritto all’atto della
serializzazione.
5
La chiusura dell’oggetto FileOutputStream (fos) non è da sola sufficiente; non è neppure necessaria, tuttavia è buona
norma effettuarla.

pag. 39
Advanced Java rev. 1.0 Novembre 2012

Segue il frammento di codice per la deserializzazione:

FileInputStream fis = new FileInputStream(nmFile);
ObjectInputStream ois = new ObjectInputStream(fis);
double reale = [Link]();
[Link]();

anche qui, la gestione degli errori è stata omessa per semplicità.

Mostro il dettaglio dei contenuti del file:
serializzazione nativa di una variabile di tipo double Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
77 TC_BLOCKDATA
08 Lunghezza del blocco di dati a seguire
40 1D CC CC CC CC CC CD Dato, di tipo double, col valore 7.45

Per il momento non aggiungo altro sull’argomento.

Serializzazione di un tipo primitivo.

Per ogni tipo primitivo esiste una classe wrapper, ad esempio [Link] per int, [Link]
per boolean etc. Le classi wrapper sono vere classi e le loro istanze sono oggetti.

Serializzare una variabile di tipo primitivo significa serializzare un’istanza della classe wrapper.

Ad esempio, considero il seguente codice (appartenente ad una versione estesa di Serial):

boolean flag = true;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
[Link](flag);
byte[] bSerial = [Link]();
hexDump(bSerial,[Link]);

ho tralasciato la gestione errori. Ecco il risultato:

serializzazione di una variabile booleana Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC
00 11 Lunghezza del nome della classe
6A 61 76 61 2E 6C 61 6E 67 2E 42 6F 6F
6C 65 61 6E Nome (completo) della classe: [Link]
CD 20 72 80 D5 9C FA EE SerialVersionUID
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 01 Numero di campi (Boolean ha un campo)
5A Tipo del primo campo: ‘Z’ – boolean
00 05 Lunghezza del nome del primo campo
76 61 6C 75 65 Nome del primo campo: value
78 Terminatore: TC_ENDBLOCKDATA
70 TC_NULL
Stato dell’istanza
01 Valore del campo value: true

Ciò che è stato serializzato è un’istanza della classe [Link], wrapper del tipo primitivo boolean.

pag. 40
Advanced Java rev. 1.0 Novembre 2012

Posso partire direttamente dal wrapper, usando il codice standard di Serial; allo scopo, aggiungo al switch
su nmCls il ramo seguente:
case "[Link]":
obj = new Boolean(true);
break;

tutto il resto del codice, rimasto immodificato, va come già illustrato. L’output che ottengo è identico a
quello già esposto.

Dallo studio della serializzazione, si evince che il wrapper di un tipo primitivo P è una classe con un solo
campo, il cui nome è value e il cui tipo è P.

Notare: l’istruzione ObjectStreamClass osc = [Link]([Link])

restituisce osc = null, ciò è dovuto alla natura di pseudoclasse di [Link]; se al posto di
[Link] avessi scritto [Link], avrei ottenuto osc non null.

Serializzazione di tipi primitivi numerici.

Il caso di serializzazione di tipi numerici primitivi, come int, è analogo al caso della serializzazione di una
variabile booleana, ma con una differenza legata alla presenza di un supertipo, cioè [Link] –
mentre [Link] discende direttamente da Object.

Anche qui, è indifferente che io utilizzi la variabile esplicita int n = 1008357163 (hex 3C1A4F2B),
oppure utilizzi il codice standard aggiungendo allo switch su nmCls il ramo:
case "[Link]":
obj = new Integer(1008357163); //
break;

il risultato non cambia. Ecco l’output:

serializzazione di una variabile integer Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC
00 11 Lunghezza del nome della classe
6A 61 76 61 2E 6C 61 6E 67 2E 49 6E 74
65 67 65 72 Nome (completo) della classe: [Link]
12 E2 A0 A4 F7 81 87 38 SerialVersionUID
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 01 Numero di campi (Integer ha un campo)
49 Tipo del primo campo: ‘I’ – integer
00 05 Lunghezza del nome del primo campo
76 61 6C 75 65 Nome del primo campo: value
78 Terminatore: TC_ENDBLOCKDATA
Descrizione del supertipo
72 TC_CLASSDESC
00 10 Lunghezza del nome della classe
6A 61 76 61 2E 6C 61 6E 67 2E 4E 75 6D
62 65 72 Nome (completo) della classe: [Link]
86 AC 95 1D 0B 94 E0 8B SerialVersionUID
02 Flag: SC_SERIALIZABLE
00 00 Numero di campi (Number non ha campi)
78 Terminatore: TC_ENDBLOCKDATA
70 TC_NULL

pag. 41
Advanced Java rev. 1.0 Novembre 2012

Stato dell’istanza
3C 1A 4F 2B Valore del campo value: 1008357163

Esaminando l’output, si vede che è assai analogo a quello ottenuto serializzando un’istanza di
[Link], anzi è sottocaso della serializzazione di un’istanza della classe [Link], in quanto
compare pure qui un supertipo non banale.

Serializzazione di un oggetto di tipo String.

Studiando la serializzazione della classe XSerianda, ho incontrato il caso del campo stringa di tipo String, che
è stato trattato come se fosse un object. Adesso studio la serializzazione di un oggetto di tipo String, gestita
all’interno dell’applicazione Serial nel codice standard, allo scopo aggiungo il ramo relativo a
[Link] nel switch sulla variabile nmCls, contenente il nome della classe:
case "[Link]":
obj = new String("Prova seriale");
break;

Ecco l’output:
serializzazione di una variabile stringa Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
74 TC_STRING
00 0D Lunghezza del valore
50 72 6F 76 61 20 73 65 72 69 61 6C 65 valore: Prova seriale

Avrei ottenuto lo stesso risultato se avessi scritto direttamente [Link](“Prova seriale”).

Si tratta di un comportamento peculiare, si manifesta solo quando l’oggetto serializzato è una stringa. È
importante osservare che la stessa struttura è presente nel caso della classe XSerianda, nella sezione
dedicata al valore del campo stringa di tipo String, mentre non è così nella descrizione del tipo del campo
stringa di tipo String (sempre di XSerianda).

Un altro caso a sé è la serializzazione di un oggetto null: ciò che ottengo in output è AC ED 00 05 70.

Serializzazione dell’istanza di una classe con campi tipizzati mediante altre classi.
Le classi esaminate finora avevano tutti i campi di tipo primitivo oppure di tipo String; adesso esaminerò il
caso della classe [Link], avente tre campi: it di tipo int, cx di tipo [Link] e db di tipo double.
Prima mostro la serializzazione di un’istanza della classe [Link], prevista fin dall’inizio in Serial; il
valore dell’istanza è new Complex(0.5,-1):
serializzazione di una variabile di tipo [Link] Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC
00 0B Lunghezza del nome della classe
6E 75 6D 2E 43 6F 6D 70 6C 65 78 Nome (completo) della classe: [Link]
C3 F4 C2 20 85 A4 98 4C SerialVersionUID
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 02 Numero di campi
44 Tipo del primo campo: ‘D’ – double
00 03 Lunghezza del nome del primo campo
69 6D 67 Nome del primo campo: img

pag. 42
Advanced Java rev. 1.0 Novembre 2012

44 Tipo del secondo campo: ‘D’ – double

00 04 Lunghezza del nome del secondo campo
72 65 61 6C Nome del secondo campo: real
78 Terminatore: TC_ENDBLOCKDATA
70 TC_NULL
Stato dell’istanza
BF F0 00 00 00 00 00 00 Valore del campo img: -1
3F E0 00 00 00 00 00 00 Valore del campo img: 0.5

Aggiungo il ramo concernente la classe [Link] allo switch su nmCls:

case "[Link]":
obj = new Complessa(1000,new Complex(0.5,-1),7.45);
break;

ecco l’output – ho imposto SerialVersionUID = 1021:

esempio di [Link] Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC
00 0D Lunghezza del nome della classe
6D 69 78 2E 43 6F 6D 70 6C 65 73 73 61 Nome (completo) della classe: [Link]
00 00 00 00 00 00 03 FD SerialVersionUID: 1021
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 03 Numero di campi (Complessa ha 3 campi)
44 Tipo del primo campo: ‘D’ – double
00 02 Lunghezza del nome del primo campo
64 62 Nome del primo campo: db
49 Tipo del secondo campo: ‘I’ – integer
00 02 Lunghezza del nome del secondo campo
69 74 Nome del secondo campo: it
4C Tipo del terzo campo: ‘L’ – object
00 02 Lunghezza del nome del terzo campo
63 78 Nome del terzo campo: cx
Descrizione del tipo del terzo campo
74 TC_STRING
00 0D Lunghezza del nome del tipo
4C 6E 75 6D 2F 43 6F 6D 70 6C 65 78 3B Nome: Lnum/Complex;
78 Terminatore: TC_ENDBLOCKDATA
70 TC_NULL
Stato dell’istanza
40 1D CC CC CC CC CC CD Valore del campo db: 7.45
00 00 03 E8 Valore del campo it: 1000
Valore del campo cx, istanza di [Link]:
73 TC_OBJECT
Descrizione della classe
72 TC_CLASSDESC
00 0B Lunghezza del nome della classe
6E 75 6D 2E 43 6F 6D 70 6C 65 78 Nome della classe: [Link]
C3 F4 C2 20 85 A4 98 4C SerialVersionUID

pag. 43
Advanced Java rev. 1.0 Novembre 2012

02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 02 Numero di campi
44 Tipo del primo campo: ‘D’ – double
00 03 Lunghezza del nome del primo campo
69 6D 67 Nome del primo campo: img
44 Tipo del secondo campo: ‘D’ – double
00 04 Lunghezza del nome del secondo campo
72 65 61 6C Nome del primo campo: real
78 Terminatore: TC_ENDBLOCKDATA
70 TC_NULL
BF F0 00 00 00 00 00 00 Valore del campo img: -1
3F E0 00 00 00 00 00 00 Valore del campo real: 0.5

La serializzazione di [Link] ha seguito lo schema di [Link], con una novità per quanto
riguarda la descrizione dello stato: il valore del campo cx, di tipo [Link], è stato scritto riportando
tutta la serializzazione dell’istanza new Complex(0.5,-1), eccezion fatta per i primi 4 byte AC ED 00 05.

Osservazione importantissima: affinchè una classe sia serializzabile, devono esserlo tutte le classi che
compaiono come tipi dei suoi membri; nel caso di [Link], la serializzazione è garantita perché non
solo la classe [Link] è serializzabile (cioè implementa l’interfaccia Serializable), ma lo è anche la
classe [Link] che tipizza due suoi membri.

L’ottimizzazione della serializzazione gestita mediante handle.

C’è un’importante ottimizzazione nella serializzazione degli oggetti, che risulta essere di grande importanza
nella scrittura su stream degli array, ma che ha portata generale: è il meccanismo dei handle.

Ad ogni oggetto serializzato, cioè scritto sull‘output stream, viene assegnato un handle, cioè un codice che è
in seguito usato per riferirsi all’oggetto. Ciò consente un potenziale risparmio sul volume dei dati.

I handle sono assegnati sequenzialmente, partendo dal valore 0x7E0000 (valore definito come
[Link], di tipo int); la numerazione ricomincia da 0x7E0000
quando lo stream è resettato.

Quando una classe ha due campi t1 e t2 dello stesso tipo T, con T non primitivo, la serializzazione implica la
descrizione del tipo T per quanto concerne t 1, mentre per la descrizione del tipo di t 2 viene usato un handle
che referenzia la precedente descrizione di T.

Mostro un primo esempio di utilizzo dei handle, è il caso di una classe con campi di tipo ripetuto:
package mix;
public class Sestupla implements [Link]
{
private static final long serialVersionUID = 1002L;
private String abc = "abc";
private [Link] fcx = new [Link](0.75,-0.25);
private int it = 10000;
private [Link] scx = new [Link](0.5,1.25);
private int tag = 1000000;
private String xyz = "xyz";
}

i campi sono sei, coi tipi ripetuti a coppie: it e tag sono campi dello stesso tipo primitivo int, abc e xyz sono
entrambi di tipo String e quindi vengono trattati come oggetti (sia pure sui generis), mentre i campi fcx e scx
sono entrambi istanze della classe Complex.

pag. 44
Advanced Java rev. 1.0 Novembre 2012

Segue l’output della serializzazione di un’istanza della classe [Link], creata col costruttore default
dato che i campi vengono comunque valorizzati all’inizializzazione (il significato dei numerini rossi tra
parentesi verrà chiarito nel seguito):

serializzazione di una variabile di tipo [Link] Campo

AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC (0)
00 0C Lunghezza del nome della classe
6D 69 78 2E 53 65 73 74 75 70 6C 61 Nome (completo) della classe: [Link]
00 00 00 00 00 00 03 EA SerialVersionUID: 1002
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 06 Numero di campi
49 Tipo del primo campo: ‘I’ – integer
00 02 Lunghezza del nome del primo campo
69 74 Nome del primo campo: it
49 Tipo del secondo campo: ‘I’ – integer
00 03 Lunghezza del nome del secondo campo
74 61 67 Nome del secondo campo: tag
4C Tipo del terzo campo: ‘L’ – object
00 03 Lunghezza del nome del terzo campo
61 62 63 Nome del terzo campo: abc
74 TC_STRING (1)
00 12 Lunghezza del nome del tipo
4C 6A 61 76 61 2F 6C 61 6E 67 2F 53 74
72 69 6E 67 3B Nome: Ljava/lang/String;
4C Tipo del quarto campo: ‘L’ – object
00 03 Lunghezza del nome del quarto campo
66 63 78 Nome del quarto campo: fcx
74 TC_ STRING (2)
00 0D Lunghezza del nome del tipo
4C 6E 75 6D 2F 43 6F 6D 70 6C 65 78 3B Nome: Lnum/Complex;
4C Tipo del quinto campo: ‘L’ – object
00 03 Lunghezza del nome del quinto campo
73 63 78 Nome del quinto campo: scx
71 TC_REFERENCE
00 7E 00 02 Handle a (2)
4C Tipo del sesto campo: ‘L’ – object
00 03 Lunghezza del nome del sesto campo
78 79 7A Nome del sesto campo: xyz
71 TC_REFERENCE
00 7E 00 01 Handle a (1)
78 Terminatore: TC_ENDBLOCKDATA
70 TC_NULL (3)
Stato dell’istanza
00 00 27 10 Valore del campo it: 10000
00 0F 42 40 Valore del campo tag: 1000000
Valore del campo abc

pag. 45
Advanced Java rev. 1.0 Novembre 2012

74 TC_STRING (4)
00 03 Lunghezza del valore
61 62 63 Valore: abc
Valore del campo fcx
73 TC_OBJECT
72 TC_CLASSDESC (5)
00 0B Lunghezza del nome del tipo del valore
6E 75 6D 2E 43 6F 6D 70 6C 65 78 Nome del tipo del valore: [Link]
C3 F4 C2 20 85 A4 98 4C SerialVersionUID
02 SC_SERIALIZABLE
00 02 Numero di campi
44 Tipo del primo campo: ‘D’ – double
00 03 Lunghezza del nome del primo campo
69 6D 67 Nome del primo campo: img
44 Tipo del secondo campo: ‘D’ – double
00 04 Lunghezza del nome del secondo campo
72 65 61 6C Nome del secondo campo: real
78 TC_ENDBLOCKDATA
70 TC_NULL (6)
BF D0 00 00 00 00 00 00 Valore del campo img: -0.25
3F E8 00 00 00 00 00 00 Valore del campo real: 0.75
Valore del campo scx
73 TC_OBJECT
71 TC_REFERENCE
00 7E 00 05 Handle a (5)
3F F4 00 00 00 00 00 00 Valore del campo img: 1.25
3F E0 00 00 00 00 00 00 Valore del campo real: 0.5
Valore del campo xyz
74 TC_STRING (7)
00 03 Lunghezza del valore
78 79 7A Valore: xyz

Si noti che, nella descrizione della classe Sestupla, vengono prima elencati i campi di tipo primitivo, in
ordine alfabetico, poi segue l’elencazione dei campi di tipo oggetto (istanze di String o di Complex, non fa
differenza), anch’essi in ordine alfabetico. Si tratta di una regola generale.

Il meccanismo dei handle non riguarda i tipi primitivi, in quanto un handle viene assegnato a un oggetto
serializzato, e un dato di tipo primitivo non è un oggetto.

Il valore iniziale 0x7E0000 (baseWireHandle) è assegnato sempre al primo oggetto scritto sull’output
stream, che qui è la sequenza descrittiva della classe [Link], sequenza iniziata dal byte 0x72 =
TC_CLASSDESC, qui referenziata come (0). Il secondo oggetto ad essere scritto sull’output stream è la
sequenza (1), iniziata da 0x74 = TC_STRING, perciò a questa sequenza viene associato un handle, e il valore
di tale handle è uguale al precedente più uno, e ciò spiega l’assegnazione del valore 0x7E0001.

Il terzo oggetto serializzato è la sequenza referenziata come (2), perciò il valore del suo handle è 0x7E0002.
La descrizione del campo fcx avviene come di consueto, ma quando si giunge alla descrizione del campo
successivo, scx, c’è la ripetizione del tipo Complex, e qui interviene il meccanismo dei handle: i primi tre
dati, ossia tipo = 0x4C seguito dal nome 0x73 0x63 0x78 = scx, vengono necessariamente scritti perché su
essi non c’è la ripetizione, poi dovrebbe seguire la descrizione del tipo Complex, ma questa è già stata
scritta, e al suo posto compare il suo handle 0x7E0002, preceduto da 0x71 = TC_REFERENCE (il quale
specifica che ciò che segue nello stream è un handle, su 4 byte).

pag. 46
Advanced Java rev. 1.0 Novembre 2012

Procedendo con la descrizione dei campi, incontro xyz di tipo String, e anche qui interviene l’uso
dell’handle: dopo il nome, xyz, dovrebbe seguire la sequenza 0x74 . . . 0x3B, ma essendo questa già
presente e contrassegnata (1), con handle 0x7E0001, nella descrizione del campo xyz viene scritto 0x71
0x00 0x7E 0x00 0x01.
Terminata la descrizione dei campi, giungo alla descrizione del supertipo, che consiste di un solo TC_NULL
perché la classe Sestupla discende direttamente da [Link]; comunque anche in questo caso
banalizzato siamo in presenza di scrittura d’un oggetto – il null object – sull’output stream, riferito come (3),
quindi ad anch’esso viene associato un handle, il cui valore è necessariamente 0x7E0003.
Procedendo, incontro la descrizione dello stato: i primi due campi sono di tipo primitivo e non implicano
assegnazioni di handle, ma il terzo campo è di tipo String e come descrizione del suo valore c’è la sequenza
0x74 . . . 0x63, referenziata come (4), alla quale viene associato l’handle di valore 0x7E0004.
Segue la descrizione del valore del quarto campo, fcx, di tipo Complex: qui c’è la descrizione del tipo,
[Link], cioè la sequenza referenziata come (5), cui viene associato l’handle di valore 0x7E0005.
Nella descrizione del valore del quinto campo, scx, anch’esso di tipo [Link], viene scritto il
riferimento alla sequenza (5), ossia TC_REFERENCE 0x7E0005.
Per ultimo, viene il valore del campo xyz di tipo String, che data la sua immediatezza non implica ripetizioni
e quindi non c’è uso di alcun handle.
L’uso dei handle interviene sia nella descrizione dei campi, sia nella descrizione dello stato cioè dei valori
dei campi, tuttavia in ambo i casi esso concerne la descrizione di tipi.

Serializzazione di una classe ricorsiva.

Considero la seguente classe, [Link] (sempre appartenente a [Link]):
public class Ricorsiva implements Serializable
{
private static final long serialVersionUID = 11000L;
private Ricorsiva mySelf = this;
}
La classe ha una natura ricorsiva, perché un suo campo ha come tipo la classe stessa, e l’istanza in fase di
creazione salva in tale campo il riferimento a se stessa.

Aggiungo un ramo al switch su nmCls, nel metodo main di Serial:

case "[Link]":
obj = new Ricorsiva();
break;
Posso quindi serializzare l’istanza della classe [Link] e studiare il risultato in output:
serializzazione di una variabile di tipo [Link] Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC (0)
00 0D Lunghezza del nome della classe
6D 69 78 2E 52 69 63 6F 72 73 69 76 61 Nome (completo) della classe: [Link]
00 00 00 00 00 00 2A F8 SerialVersionUID: 11000
02 Flag: SC_SERIALIZABLE
Descrizione dei campi
00 01 Numero di campi
4C Tipo del primo campo: ‘L’ – object
00 06 Lunghezza del nome del primo campo
6D 79 53 65 6C 66 Nome del primo campo: mySelf

pag. 47
Advanced Java rev. 1.0 Novembre 2012

74 TC_STRING (1)
00 0F Lunghezza del nome del tipo
4C 6D 69 78 2F 52 69 63 6F 72 73 69 76
61 3B Nome: Lmix/Ricorsiva;
78 TC_ENDBLOCKDATA
70 TC_NULL
71 TC_REFERENCE
00 7E 00 02 Handle a (?)
Come si vede, i handle sono utilizzati; c’è tuttavia un problema: mi sarei atteso il valore 0x7E0000
nell’ultimo campo, e non il valore 0x7E0002, che a me sembra puntare a TC_NULL.

Serializzazioni iterate.
È possibile invocare più volte l’istruzione [Link] (oos è l’oggetto di tipo ObjectOutputStream,
costruito sopra a un oggetto, fos, di tipo FileOutputStream), ossia effettuare due o più distinte operazioni di
scrittura sullo stesso output stream; anche in questo caso, può intervenire il meccanismo dei handle. È
anche possibile scrivere sullo stesso output stream un misto di oggetti e dati primitivi, ossia usare istruzioni
writeObj assieme ad istruzioni come writeInt, writeDouble etc.

Considero un esempio implementato in un ramo ad hoc dell’applicazione Serial:

[Link](new Complex(0.5,0.25));
[Link](new Complex(1.5,0.75));
[Link](12000);
è necessario chiudere oos prima che termini l’applicazione, non è sufficiente chiudere il file soggiacente,
perché l’ultima scrittura su oos è stata quella di un dato primitivo, come già spiegato.
Per deserializzare il risultato (scritto nel file Serials/[Link]), utilizzo un ramo ad hoc dell’applicazione
Deserial (ois è il consueto oggetto di tipo ObjectInputStream, costruito sopra a un oggetto, fis, di tipo
FileInputStream, che legge il file [Link]):
Complex c1 = (Complex) [Link]();
[Link]("c1 = "+c1);
Complex c2 = (Complex) [Link]();
[Link]("c2 = "+c2);
short s = [Link]();
[Link]("s = "+s);
Ecco l’output fornito dall’applicazione Deserial, leggendo Serials/[Link]:

Segue l’interpretazione dei risultati:

analisi di Serials/[Link] Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION

pag. 48
Advanced Java rev. 1.0 Novembre 2012

Oggetto generato da new Complex(0.5,0.25)

73 TC_OBJECT
72 TC_CLASSDESC (0)
00 0B Lunghezza del nome della classe
6E 75 6D 2E 43 6F 6D 70 6C 65 78 Nome (completo) della classe: [Link]
C3 F4 C2 20 85 A4 98 4C SerialVersionUID
02 SC_SERIALIZABLE
00 02 Numero di campi
44 Tipo del primo campo: ‘D’ – double
00 03 Lunghezza del nome del primo campo
69 6D 67 Nome del primo campo: img
44 Tipo del secondo campo: ‘D’ – double
00 04 Lunghezza del nome del secondo campo
72 65 61 6C Nome del secondo campo: real
78 TC_ENDBLOCKDATA
70 TC_NULL
3F D0 00 00 00 00 00 00 Valore del campo img: 0.5
3F E0 00 00 00 00 00 00 Valore del campo real: 0.25
Oggetto generato da new Complex(1.5,0.75)
73 TC_OBJECT
71 TC_REFERENCE
00 7E 00 00 Handle a (0)
3F E8 00 00 00 00 00 00 Valore del campo img: 1.5
3F F8 00 00 00 00 00 00 Valore del campo real: 0.75
Dato primitivo
77 TC_BLOCKDATA
02 Lunghezza del blocco di dati a seguire
2E E0 Dato, di tipo short, col valore 12000

Serializzazione di array.
In generale, un array T[] è sempre una classe, anche quando T è un tipo primitivo; con il termine classe
array indico T[], mentre con il termine classe item indico T.

Inoltre T[] è sempre subtipo diretto di [Link], indipendentemente dal tipo T. Il package, ricavabile
come T[].[Link], è sempre null.

Per scoprire ciò, non è necessario analizzare i risultati delle serializzazioni, si può giungere alle stesse
conclusioni anche per altra via, usando la reflection: scrivendo Class cls = T[].class, trovo che cls ha
nove metodi, nessun costruttore, nessun campo, ha supertipo [Link] e package null.

Il nome, cioè [Link], è sempre costituito dal carattere ‘[‘ seguito dal nome del tipo T scritto in
notazione stream protocol, cioè una sola lettera per i tipi primitivi e L<[Link]>; negli altri casi;
nella tabella che segue mostro alcuni esempi d’interesse, ossia array di tipi primitivi, array di stringhe e
array di classi applicative come [Link]:

T[] [Link] T[].[Link] T[].SerialVersionUID

boolean[] boolean [Z 578F203914B85DE2

byte[] byte [B ACF317F8060854E0

pag. 49
Advanced Java rev. 1.0 Novembre 2012

short[] short [S EF832E06E55DB0FA

int[] int [I 4DBA602676EAB2A5

long[] long [J 782004B512B17593

Integer[] [Link] [[Link]; FE97ADA00183E21B

String[] [Link] [[Link]; ADD256E7E91D7B47

Complex[] [Link] [[Link]; CD32D0ED8F0CCDDC

Nella quarta colonna ho riportato il SerialVersionUID della classe array, ricavato con il seguente codice:
ObjectStreamClass osc = [Link](T[].class);
long SerialVersionUID = [Link]();

Si noti che osc è null per i tipi primitivi, ma non per i loro array.

Nel caso di array di dati primitivi, ad esempio T = boolean, non c’è classe item perché boolean non è una
classe, però c’è la classe array, infatti boolean[] è una classe.

La classe array è sempre priva di campi, non importa quanti e quali campi abbia la classe item.

L’array T[] è serializzabile se e solo se T è serializzabile; ma la serializzazione degli array segue uno schema
un po’ diverso da quello proprio delle istanze di oggetti.

In generale, la sequenza descrittiva dell’array arr di tipo T[] può essere così schematizzata:
a) sottosequenza iniziale costituita dai byte AC ED 00 05
b) descrizione della classe array (cioè T[]), sempre iniziata dai byte 75 72 e terminata da 78 70, ove
il byte 0x70 rappresenta la descrizione del supertipo della classe array, cioè [Link]
c) rappresentazione della lista di valori arr[i].

Serializzazione di un array di dati primitivi.

Nell’applicazione Serial, siccome [Link]().getName() è [I, posso usare [I come valore di nmCls,
cioè, volendo serializzare un array di interi, l’operatore deve passare la stringa [I, che verrà assegnata a
nmCls; entro lo switch su nmCls, definisco il seguente ramo:
case "[I":
int[] ai = {-1, 100000, 1000000};
obj = ai;
break;
poi l’oggetto array viene serializzato dall’istruzione [Link](obj).
La deserializzazione viene compiuta dall’applicazione Deserial: oltre al solito dump, viene ricostruito
l’oggetto array tramite l’istruzione Object obj = [Link]();, ove ois è l’oggetto di tipo
ObjectInputStream, quindi viene visualizzato:
case "[I":
int[] ai = (int[])obj;
[Link]("Array di "+[Link]+" int");
for (int k=0;k<[Link];k++)
[Link]("ai["+k+"]="+ai[k]);
break;
il risultato è quello atteso, cioè i tre valori -1, 100000 e 1000000.

Mostro il dump dell’oggetto array serializzato:

analisi di Serials/[[Link] Campo
AC ED STREAM_MAGIC

pag. 50
Advanced Java rev. 1.0 Novembre 2012

00 05 STREAM_VERSION
75 TC_ARRAY
72 TC_CLASSDESC
00 02 Lunghezza del nome della classe array
5B 49 Nome della classe array: [I
4D BA 60 26 76 EA B2 A5 SerialVersionUID
02 SC_SERIALIZABLE
00 00 Numero di campi
78 TC_ENDBLOCKDATA
70 TC_NULL
00 00 00 03 Numero di item dell’array
FF FF FF FF Primo item = -1
00 01 86 A0 Secondo item = 100000
00 0F 42 40 Secondo item = 1000000

Siccome la classe item è int, che non è una vera classe, la scrittura dei valori è immediata (non c’è
descrizione di tipo).

Serializzazione di un array di stringhe.

Nell’applicazione Serial, siccome [Link]().getName() è [[Link];, posso usare
[[Link]; come valore di nmCls, cioè, volendo serializzare un array di stringhe, l’operatore deve
passare la stringa [[Link];, che verrà assegnata a nmCls; entro lo switch su nmCls, definisco il
seguente ramo:
case "[[Link];":
String[] as = {"Prova","seriale"};
obj = as;
break;
poi l’oggetto array viene serializzato dall’istruzione [Link](obj).
La deserializzazione viene compiuta dall’applicazione Deserial: oltre al solito dump, viene ricostruito
l’oggetto array tramite l’istruzione Object obj = [Link]();, ove ois è l’oggetto di tipo
ObjectInputStream, quindi viene visualizzato:
case "[[Link];":
String[] as = (String[])obj;
[Link]("Array di "+[Link]+" String");
for (int k=0;k<[Link];k++)
[Link]("as["+k+"]="+as[k]);
break;
il risultato è quello atteso, cioè i tre valori -1, 100000 e 1000000.

Mostro il dump dell’oggetto array serializzato:

analisi di Serials/[[Link];.obj Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
75 TC_ARRAY
72 TC_CLASSDESC
00 13 Lunghezza del nome della classe array
5B 4C 6A 61 76 61 2E 6C 61 6E 67 2E 53
74 72 69 6E 67 3B Nome della classe array: [[Link];
AD D2 56 E7 E9 1D 7B 47 SerialVersionUID
02 SC_SERIALIZABLE
00 00 Numero di campi
78 TC_ENDBLOCKDATA

pag. 51
Advanced Java rev. 1.0 Novembre 2012

70 TC_NULL
00 00 00 02 Numero di item dell’array
Primo item
74 TC_STRING
00 05 Lunghezza del valore
50 72 6F 76 61 Valore: Prova
Secondo item
74 TC_STRING
00 07 Lunghezza del valore
73 65 72 69 61 6C 65 Valore: seriale

La scrittura dei valori avviene nella modalità tipica del tipo String, diversa da tutte le altre; è comunque una
scrittura immediata, senza descrizioni di classe, e così non vengono usati i handle.

Serializzazione di un array di classi.

Nell’applicazione Serial, siccome [Link]().getName() è [[Link];, posso
usare [[Link]; come valore di nmCls, cioè, volendo serializzare un array di oggetti di tipo
[Link], l’operatore deve passare la stringa [[Link];, che verrà assegnata a nmCls; entro lo
switch su nmCls, definisco il seguente ramo:
case "[[Link];":
Complex[] acx = new Complex[3];
acx[0] = new [Link](1.5,-1);
acx[1] = new [Link](0.25,0.75);
acx[2] = new [Link](3,4);
obj = acx;
break;
poi l’oggetto array viene serializzato dall’istruzione [Link](obj).
La deserializzazione viene compiuta dall’applicazione Deserial: oltre al solito dump, viene ricostruito
l’oggetto array tramite l’istruzione Object obj = [Link]();, ove ois è l’oggetto di tipo
ObjectInputStream, quindi viene visualizzato:
case "[[Link];":
Complex[] acx = (Complex[])obj;
[Link]("Array di "+[Link]+" Complex");
for (int k=0;k<[Link];k++)
[Link]("acx["+k+"]="+acx[k]);
break;
il risultato è quello atteso, cioè i tre valori 1.5-i, 0.25+0.75i e 3+4i.

Mostro il dump dell’oggetto array serializzato:

analisi di Serials/[[Link];.obj Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
75 TC_ARRAY
72 TC_CLASSDESC (0)
00 0E Lunghezza del nome della classe array
5B 4C 6E 75 6D 2E 43 6F 6D 70 6C 65 78 3B Nome della classe array: [[Link];
CD 32 D0 ED 8F 0C CD DC SerialVersionUID
02 SC_SERIALIZABLE
00 00 Numero di campi
78 TC_ENDBLOCKDATA
70 TC_NULL (1)
00 00 00 03 Numero di item dell’array

pag. 52
Advanced Java rev. 1.0 Novembre 2012

Primo item
73 TC_OBJECT
72 TC_CLASSDESC (2)
00 0B Lunghezza del nome della classe
6E 75 6D 2E 43 6F 6D 70 6C 65 78 Nome (completo) della classe: [Link]
C3 F4 C2 20 85 A4 98 4C SerialVersionUID
02 SC_SERIALIZABLE
00 02 Numero di campi
44 Tipo del primo campo: ‘D’ – double
00 03 Lunghezza del nome del primo campo
69 6D 67 Nome del primo campo: img
44 Tipo del secondo campo: ‘D’ – double
00 04 Lunghezza del nome del secondo campo
72 65 61 6C Nome del secondo campo: real
78 TC_ENDBLOCKDATA
70 TC_NULL
BF F0 00 00 00 00 00 00 Valore del campo img: -1
3F F8 00 00 00 00 00 00 Valore del campo real: 1.5
Secondo item
73 TC_OBJECT
71 TC_REFERENCE
00 7E 00 02 Handle a (2)
3F E8 00 00 00 00 00 00 Valore del campo img: 0.75
3F D0 00 00 00 00 00 00 Valore del campo img: 0.25
Terzo item
73 TC_OBJECT
71 TC_REFERENCE
00 7E 00 02 Handle a (2)
40 10 00 00 00 00 00 00 Valore del campo img: 4
40 08 00 00 00 00 00 00 Valore del campo img: 3

Come si vede, i handle sono usati, in modo semplice; nel caso di array con molti item e classe item
voluminosa, dall’uso dei handle risulta una grande ottimizzazione.

Array come campi di classi serializzate.

Finora ho studiato serializzazione di classi con campi di tipo primitivo, oppure tipati tramite altre classi (ad
esempio, le classi Sestupla e Complessa hanno campi di tipo Complex); tuttavia una classe può avere campi
definiti come array, di dati primitivi oppure di classi.
Complessivamente, lo studio della serializzazione di classi con campi definiti come array non aggiunge vere
novità, ossia è riconducibile alla sintesi tra i casi di serializzazione di classi e di array.

Campo di tipo array di dati primitivi.

Comincio con un caso semplice, cioè la prima versione della classe [Link], che ha due campi, il
primo dei quali è definito come array di dati primitivi:

public class Classarray implements Serializable

{
private static final long serialVersionUID = 1030L;
private int molt = 0;
private long[] al = null;
public Classarray(int m,int v)
{
molt = m;

pag. 53
Advanced Java rev. 1.0 Novembre 2012

al = new long[molt];
for (int i=0;i<molt;i++) al[i] = 1000000*v*(i+1);
}
}

La sua serializzazione è gestita nell’applicazione Serial:

case "[Link]":
obj = new Classarray(3,12);
break;

cui segue la consueta [Link](obj); la sua deserializzazione è operata dall’applicazione Deserial, che
utilizza la consueta obj = [Link]() ed esegue il successivo codice:
case "[Link]":
[Link] clar = ([Link])obj;
[Link]("Classarray clar = "+clar);
break;

Mostro il dump dell’oggetto array serializzato:

analisi di Serials/[Link] Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC
00 0E Lunghezza del nome della classe
6D 69 78 2E 43 6C 61 73 73 61 72 72 61 79 Nome (completo) della classe: [Link]
00 00 00 00 00 00 04 06 SerialVersionUID
02 SC_SERIALIZABLE
00 02 Numero di campi
49 Tipo del primo campo: ‘I’ – integer
00 04 Lunghezza del nome del primo campo
6D 6F 6C 74 Nome del primo campo: molt
5B Tipo del secondo campo: ‘[‘ – array
00 02 Lunghezza del nome del secondo campo
61 6C Nome del secondo campo: al
Descrizione del tipo del secondo campo
74 TC_STRING
00 02 Lunghezza del nome del tipo
5B 4A Nome del tipo: [J
78 TC_ENDBLOCKDATA
70 TC_NULL
Descrizione dello stato
00 00 00 03 Valore del campo molt: 3
Valore del campo (array) al
75 TC_ARRAY
72 TC_CLASSDESC
00 02 Lunghezza del nome del tipo
5B 4A Nome del tipo: [J
78 20 04 B5 12 B1 75 93 SerialVersionUID
02 SC_SERIALIZABLE
00 00 Numero di campi = 0 (array)
78 TC_ENDBLOCKDATA
70 TC_NULL
00 00 00 03 Numero di item dell’array

pag. 54
Advanced Java rev. 1.0 Novembre 2012

00 00 00 00 00 B7 1B 00 Valore del primo item: 12000000

00 00 00 00 01 6E 36 00 Valore del primo item: 24000000
00 00 00 00 02 25 51 00 Valore del primo item: 36000000

Campo di tipo array di classi.

Uso la seconda versione della classe Classarray, avente un campo array di classi, [Link]:
public class Classarray implements Serializable
{
private static final long serialVersionUID = 1030L;
private int molt = 0;
private [Link][] acx = null;
public Classarray(int m,double v)
{
molt = m;
acx = new [Link][molt];
for (int i=0;i<molt;i++) acx[i] = new [Link](v*i,v*(i+1));
}
}

Entro il codice dell’applicazione Serial, adeguo il ramo nello switch su nmCls:

case "[Link]":
obj = new Classarray(3,0.25);
break;

il codice dell’applicazione Deserial resta invariato; viene correttamente ricostruito l’array di (tre) oggetti
Complex: 0.25i, 0.25+0.5i, 0.5+0.75i. Segue il dump dell’array serializzato:
analisi di Serials/[Link] Campo
AC ED STREAM_MAGIC
00 05 STREAM_VERSION
73 TC_OBJECT
72 TC_CLASSDESC (0)
00 0E Lunghezza del nome della classe
6D 69 78 2E 43 6C 61 73 73 61 72 72 61 79 Nome (completo) della classe: [Link]
00 00 00 00 00 00 04 06 SerialVersionUID
02 SC_SERIALIZABLE
00 02 Numero di campi
49 Tipo del primo campo: ‘I’ – integer
00 04 Lunghezza del nome del primo campo
6D 6F 6C 74 Nome del primo campo: molt
5B Tipo del secondo campo: ‘[‘ – array
00 03 Lunghezza del nome del secondo campo
61 63 78 Nome del secondo campo: acx
Descrizione del tipo del secondo campo
74 TC_STRING (1)
00 0E Lunghezza del nome del tipo
5B 4C 6E 75 6D 2F 43 6F 6D 70 6C 65 78 3B Nome del tipo: [Lnum/Complex;
78 TC_ENDBLOCKDATA
70 TC_NULL (2)
Descrizione dello stato
00 00 00 03 Valore del campo molt: 3
Valore del campo (array) acx
75 TC_ARRAY
Descrizione della classe array [Link][]
72 TC_CLASSDESC (3)

pag. 55
Advanced Java rev. 1.0 Novembre 2012

00 0E Lunghezza del nome della classe

5B 4C 6E 75 6D 2E 43 6F 6D 70 6C 65 78 3B Nome della classe: [[Link];
CD 32 D0 ED 8F 0C CD DC SerialVersionUID
02 SC_SERIALIZABLE
00 00 Numero di campi = 0 (array)
78 TC_ENDBLOCKDATA
70 TC_NULL (4)
00 00 00 03 Numero di item dell’array
Primo item
73 TC_OBJECT
Descrizione della classe item ([Link])
72 TC_CLASSDESC (5)
00 0B Lunghezza del nome della classe item
6E 75 6D 2E 43 6F 6D 70 6C 65 78 Nome della classe item: [Link]
C3 F4 C2 20 85 A4 98 4C SerialVersionUID
02 SC_SERIALIZABLE
00 02 Numero di campi
44 Tipo del primo campo: ‘D’ – double
00 03 Lunghezza del nome del primo campo
69 6D 67 Nome del primo campo: img
44 Tipo del secondo campo: ‘D’ – double
00 04 Lunghezza del nome del secondo campo
72 65 61 6C Nome del secondo campo: real
78 TC_ENDBLOCKDATA
70 TC_NULL
3F D0 00 00 00 00 00 00 Valore del campo img: 0.25
00 00 00 00 00 00 00 00 Valore del campo real: 0
Secondo item
73 TC_OBJECT
71 TC_REFERENCE
00 7E 00 05 Handle a (5)
3F E0 00 00 00 00 00 00 Valore del campo img: 0.5
3F D0 00 00 00 00 00 00 Valore del campo real: 0.25
Terzo item
73 TC_OBJECT
71 TC_REFERENCE
00 7E 00 05 Handle a (5)
3F E8 00 00 00 00 00 00 Valore del campo img: 0.75
3F E0 00 00 00 00 00 00 Valore del campo real: 0.5

L’uso dei handle è del tutto analogo a quanto si è visto nella serializzazione di un array di classi.

pag. 56
Advanced Java rev. 1.0 Novembre 2012

Introduzione all’utilizzo dei socket in Java.

Mi servirò dell’applicazione Telefono per studiare la gestione dei socket in Java.

L’applicazione Telefono permette a due computer connessi sulla stessa LAN di scambiarsi messaggi testuali
in tempo reale, è una applicazione chat di tipo console; è basata sull’uso diretto dei socket.

L’applicazione ha comportamento analogo a quello di un comune scambio telefonico: i due utenti, indicati
come A e B, sono rappresentati ciascuno da un endpoint, ossia una coppia <host:porta>; se ad esempio A
parte per primo, la sua chiamata resta appesa finchè non parte anche B: a questo punto i due utenti sono
connessi e possono scambiarsi messaggi6. Quando uno dei due chiude la comunicazione (inviando all’altro
la stringa “fine”), entrambi si scollegano, cioè terminano entrambe le applicazioni.

Se A chiama B, ma B non risponde, dopo un certo intervallo di tempo l’applicazione termina: è il timeout di
connessione non avvenuta.

L’applicazione Telefono è costruita mediante un progetto Java; il package app contiene quattro classi, le due
principali sono Telephone, munita di metodo main (è la classe scritta nel manifest), e Receiver, subtipo di
Thread; sono inoltre presenti le classi d’appoggio ExitObject e UnrespTask. Il build è standard, e produce in
ExeJar il file [Link], lanciabile come java –jar [Link] par1 par2 par3.

La struttura dell’applicazione.
Il metodo main della classe Telephone inizia recuperando gli eventuali parametri di passaggio da linea di
comando, poi istanzia le classi ExitObject, destinata alla chiusura ordinata dell’applicazione, e Receiver:
mentre l’invio dei messaggi avviene ad opera del main di Telephone, la ricezione avviene (in un thread
separato) ad opera dell’istanza della classe Receiver.

Poi il metodo main prosegue creando il client socket cs, ossia il socket destinato a inviare i messaggi; nel
frattempo, l’istanza di Receiver crea il server socket, destinato alla ricezione, e fa anche partire il timeout di
connessione non avvenuta.

Il metodo main passa all’istanza di Receiver l’istanza di ExitObject e il client socket, nel caso dovesse essere
l’istanza di ricezione ad occuparsi della chiusura dell’applicazione: mentre il passaggio dell’istanza di
ExitObject avviene già nel costruttore, quello del client socket avviene in un secondo tempo.

Fatto ciò, il metodo main entra nel ciclo di invio: attende l’input da operatore e lo scrive sull’output stream del
client socket. La classe Telephone ha, oltre al main, il metodo leggiBuffer, che recupera l’input da tastiera e
lo restituisce come una stringa; l’input da tastiera è terminato dal tasto Invio.

Il ciclo di invio ha durata indefinita, termina quando l’operatore digita “fine”: la stringa viene spedita, ma c’è
l’uscita dal loop; questo è uno dei due modi non patologici e non banali di chiusura dell’applicazione, diciamo
una chiusura attiva dal punto di vista dell’utente dell’applicazione (è lui che ha scritto “fine”); l’altro modo è la
chiusura passiva, esaminata nel seguito.

In uscita dal loop, il metodo main effettua le operazioni di chiusura: chiude l’output stream di cs, attende la
fine del thread di ricezione, e poi invoca il metodo termina dell’oggetto ExitObject, che chiude il client socket,
chiude il server socket, e forza la terminazione dell’intera applicazione (istruzione [Link](0)).

Mentre il metodo main di Telephone si trova nel ciclo di invio, il metodo run della classe Receiver esegue nel
suo thread separato. Come già detto, il codice del metodo run crea il server socket e lo pone in attesa di
connessioni; immediatamente prima dell’inizio dell’attesa di connessioni, viene attivato il timer di
connessione non avvenuta, che si serve dell’istanza di UnrespTask, classe subtipo di TimerTask: se il timer
scade prima che avvenga una connessione, il metodo run dell’oggetto UnrespTask chiude il server socket e
forza la terminazione dell’intera applicazione (istruzione [Link](0)); si tratta in questo caso di un
modo di chiusura banale dell’applicazione (per mancata risposta).

Se invece la connessione da parte di un’altra applicazione Telefono avviene prima che il timer scada, il
metodo run cancella il timer, passa il server socket all’istanza di ExitObject ed entra nel ciclo di ricezione. Il

6
Lo scambio dei messaggi è asincrono, ossia ogni utente può ricevere anche mentre sta scrivendo,
esattamente come in una telefonata gli utenti possono reciprocamente parlarsi addosso.

pag. 57
Advanced Java rev. 1.0 Novembre 2012

ciclo di ricezione legge dall’input stream del socket: ciò che viene letto, viene stampato a video; l’istruzione di
lettura è bloccante; il ciclo di ricezione ha durata indefinita, termina quando l’input stream riceve end of file.

L’uscita dal ciclo di ricezione può avvenire in due modi (non patologici): il primo modo è la chiusura attiva,
ossia l’operatore ha digitato “fine” nel ciclo di invio della stessa applicazione. Oltre alla chiusura attiva, è
possibile la chiusura passiva: questo si verifica quando l’applicazione riceve la stringa “fine” dalla sua
controparte, e questo evento accade proprio nel ciclo di ricezione.

Se A e B sono le due applicazioni interlocutorie, è ovvio che se A compie la chiusura attiva (cioè l’operatore
che usa A digita e invia “fine”), allora B compie una chiusura passiva, e viceversa.

Supponiamo che sia A a compiere la chiusura attiva: A spedisce a B la stringa “fine”, esce dal suo ciclo di
invio e chiude l’output stream del client socket; B riceve la stringa “fine”, che stampa, inoltre essendo stato
chiuso l’output stream del client socket di A, l’input stream di B in ricezione riceve un end of file e con ciò il
ciclo di ricezione termina. A sua volta B, chiudendo il proprio client socket, determina il verificarsi di un end of
file nel ciclo di ricezione di A, e così anche il ciclo di ricezione di A termina.

Una volta uscito dal ciclo di ricezione, il codice del metodo run chiude l’input stream, quindi verifica se si
tratta di chiusura passiva o attiva: nel primo caso, invoca il metodo termina dell’oggetto ExitObject, che
chiude il client socket, chiude il server socket, e forza la terminazione dell’intera applicazione (istruzione
[Link](0)). Nel caso di chiusura attiva, il codice del metodo run non compie azioni, in questo caso
sarà il metodo main di Telephone a preoccuparsi di chiamare il metodo termina dell’istanza di ExitObject.

Il caso di chiusura patologica più frequente, dovuto alla brusca caduta dell’applicazione remota, è trattato
adeguatamente; la sua trattazione verrà esposta studiando i dettagli del codice della classe Receiver.

La classe Telephone.
La classe Telephone ha, oltre al main, un solo altro metodo, private static String leggiBuffer(),
che recupera l’input da tastiera (terminato dal tasto Invio) e lo restituisce come una stringa.

Il main recupera gli eventuali tre parametri passati da linea di comando: par1 va nella variabile stringa
remHost (il default è “localhost”), par2 va nella variabile intera locPort (default 15000) e par3 va nella
variabile intera remPort (default 16000). È definita anche la variabile intera backlog, uguale a 50.

Le variabili remHost e remPort definiscono l’endpoint remoto, mentre locPort rappresenta la porta sull’host
locale: l’applicazione Telefono è in ascolto (riceve) sull’endpoint locale <localhost:locPort> e trasmette
all’endpoint remoto <remHost:remPort>.

Nello scenario d’esempio, ipotizzo che l’applicazione Telefono sia lanciata sui computer Ufficio-PC
(macchina Windows, di indirizzo [Link]) e sccver (macchina Linux, di indirizzo [Link]), in LAN
tra loro; la porta d’ascolto su Ufficio-PC è 15000, quella su sccver è 16000.

L’applicazione Telefono viene lanciata per prima in un command prompt sul computer Ufficio-PC, mediante
java –jar [Link] sccver 15000 16000, quindi remHost = sccver, remPort = 16000, locPort = 15000.

Recuperati i dati iniziali, il main prosegue creando l’istanza della classe Receiver e attivandola:
ExitObject exitObj = new ExitObject();
Receiver recv = new Receiver(locPort,backlog,exitObj);
[Link]();

La creazione dell’oggetto exitObj avviene tramite il costruttore implicito (la classe ExitObject non definisce un
costruttore); l’istanza di Receiver opera nel suo thread separato. Il main di Telephone prosegue creando il
client socket di trasmissione:
Socket cs = null;
boolean pass = false;
do
{
try
{
cs = new Socket(remHost,remPort);
pass = true;
}

pag. 58
Advanced Java rev. 1.0 Novembre 2012

catch (Exception e)
{
[Link](2000);
}
}
while (!pass);
[Link]("Connesso");
[Link](cs);

Nello scenario ipotizzato, il socket cs dovrebbe essere creato sull’endpoint <Ufficio-PC:door>, ove door è
una porta scelta dal sistema operativo. Il codice Socket cs = new Socket(remHost,remPort) opera
la creazione del socket e la sua connessione all’endpoint remoto <sccver:16000>7.

Tuttavia il socket cs non viene creato, perchè non ho ancora attivato l’applicazione Telefono su sccver,
quindi la connessione non va a buon fine: devo intercettare l’eccezione, fermarmi per un periodo di tempo
(due secondi) e ritentare. Così l’applicazione Telefono su Ufficio-PC ha il thread principale entro un loop di
durata indefinita, mentre il thread di ricezione è a sua volta bloccato, come si vedrà nel seguito; non c’è
alcun output visibile.

Lancio l’applicazione sul computer sccver: java –jar [Link] Ufficio-PC 16000 15000, quindi remHost =
Ufficio-PC e remPort = 15000, locPort = 16000. Così facendo, la creazione del socket cs e la sua
connessione all’endpoint remoto <sccver:16000> vanno a buon fine, il codice esce dal loop e prosegue
passando cs all’istanza di Receiver (sarà necessario nel caso di chiusura passiva).

Poi il metodo main entra nel ciclo di invio:

try
{
OutputStream os = [Link]();
String txt = "";
do
{
txt = leggiBuffer();
byte[] b = new byte[[Link]()];
for (int i=0;i<[Link]();i++) b[i] = (byte) [Link](i);
[Link](b);
}
while (![Link]("fine"));
while ([Link]())
{
[Link](500);
}
[Link](cs);
}
catch (IOException e1)
{
[Link]();
}

La prima parte del codice rappresenta il ciclo di invio vero e proprio; se non giunge la chiusura passiva,
attraverso il thread di ricezione, proveniente dall’operatore su sccver, allora l’uscita dal ciclo è determinata
dal passaggio della stringa “fine” da parte dell’operatore su Ufficio-PC.

Nel caso di chiusura attiva su Ufficio-PC (e quindi chiusura passiva su sccver), prima di tutto viene chiuso
l’output stream, viene poi attesa la fine del thread di ricezione (perché il thread di ricezione termini, verrà
spiegato studiando i dettagli del codice di Receiver), infine viene invocato il metodo termina dell’istanza di
ExitObject, che determina la fine dell’applicazione.

7
Il codice Socket cs = new Socket(remHost,remPort) equivale alle tre seguenti righe:
SocketAddress remEndpoint = new InetSocketAddress(remHost,remPort);
Socket cs = new Socket();
[Link](remEndpoint);

pag. 59
Advanced Java rev. 1.0 Novembre 2012

La classe Receiver.
La classe Receiver è subtipo di Thread; il suo costruttore, invocato dall’istanza di Telephone alla partenza,
salva i valori di locPort e backlog nei membri locali port e backlog, e salva il riferimento all’istanza di
ExitObject nel membro locale exitObj.

Il lavoro di ricezione è compiuto dal metodo run, che parte subito dopo l’istanziazione della classe Receiver:
@Override
public void run()
{
ServerSocket ascolto = null;
try
{
ascolto = new ServerSocket(port,backlog);
}
catch (IOException e)
{
[Link]("ServerSocket creation error:" +[Link]());
[Link](cs);
}
[Link]("ServerSocket creation: ascolto=" +ascolto);
Socket rets = null;
Timer tim = new Timer(true);
[Link](new UnrespTask(ascolto),1500000);
try
{
rets = [Link]();
}
catch (IOException e)
{
[Link]("accept error: "+[Link]());
[Link](cs);
}
[Link](rets, ascolto);
[Link]();
[Link]("Si e' connesso: rets=" + rets);
InputStream is = null;
try
{
is = [Link]();
}
catch (IOException e)
{
[Link]("rets getInputStream error: "+[Link]());
[Link](cs);
}
byte b[] = new byte[100];
boolean fine_ricevuta = false;
int n = 0;
do
{
try
{
n = [Link](b);
}
catch (IOException e)
{
[Link]("rets read error: "+[Link]());
[Link](cs);
}
if (n != -1)
{
StringBuffer sb = new StringBuffer("");
for (int i=0;i<n;i++) [Link]((char)b[i]);
[Link]("n="+n+": "+[Link]());
if ([Link]().matches("fine"))

pag. 60
Advanced Java rev. 1.0 Novembre 2012

{
[Link]("L'interlocutore ha riagganciato");
fine_ricevuta = true;
}
}
}
while (n != -1);
try
{
[Link]();
}
catch (IOException e)
{
[Link]("rets inputStream closing error: "+[Link]());
[Link](cs);
}
if (fine_ricevuta) [Link](cs);
}

La gestione errori viene trattata a parte, in un sottoparagrafo dedicato.

Viene creato il server socket ascolto8; il parametro backlog determina il massimo numero di connessioni che
il server socket è in grado di accodare.

Supponendo che il server socket ascolto sia stato creato senza problemi, viene richiamato il suo metodo
accept: questo resta bloccato in ascolto finchè un client non si connetterà all’endpoint locale d’ascolto
<localhost:locPort>, che nello scenario è <Ufficio-PC:15000>; la natura bloccante dei metodi accept e read
rende necessario l’uso di un thread di ricezione separato dal thread principale.

Tuttavia va previsto il caso in cui la controparte, cioè sccver nello scenario esaminato, non si connetta:
questo è il motivo per cui, prima di invocare il metodo accept, il codice del metodo run crea il timer tim e ne
schedula l’attivazione di lì a 15 secondi.

Nel caso sccver non si connetta, allo scadere del delay di 15 secondi viene eseguito il metodo run
dell’oggetto di tipo UnrespTask, subtipo di TimerTask: il server socket ascolto, passato come parametro nel
costruttore dell’oggetto UnrespTask, viene chiuso, e l’applicazione terminata dall’istruzione [Link](0).

Un task attivato da timer dev’essere implementato come un subtipo della classe astratta TimerTask, che
discende direttamente da Object e implementa l’interfaccia Runnable; bisogna quindi scrivere il metodo run.
Allo scadere del timer, il metodo run dell’oggetto entra in esecuzione, in un thread apposito (qui, un thread
diverso sia dal thread principale in cui esegue il metodo main di Telephone, sia dal thread di ricezione in cui
esegue il metodo run della classe Receiver).

Nel mio scenario di riferimento, lancio l’applicazione anche sul computer sccver: java –jar [Link]
Ufficio-PC 16000 15000, quindi remHost = Ufficio-PC e remPort = 15000, locPort = 16000; in questo modo,
nell’applicazione Telefono su Ufficio-PC il metodo accept va a buon fine, e restituisce il socket rets, detto
returning socket.

Il codice passa a exitObj i riferimenti ai socket rets e ascolto, invocando il metodo setServerSocket
dell’oggetto ExitObject, il metodo termina dell’oggetto exitObj chiude infatti rets e ascolto quando invocato.

Il timer viene cancellato, giunti a questo punto esso non serve più; trattandosi di un timer one-shot e non di
un timer ciclico, esso non scatterebbe più, tuttavia è buona norma eliminarlo in ogni caso.

Il socket rets è pronto alla ricezione; allo scopo, viene recuperato l’input stream entro la variabile is, e viene
allocato il buffer b (array di 100 byte) destinato a contenere la ricezione; se il messaggio ricevuto supera
l’ampiezza del buffer, vengono effettuate due letture consecutive.

Prima del codice che implementa il ciclo di ricezione, viene definita la variabile booleana fine_ricevuta,
settata a false.
8
Il codice ServerSocket ascolto = new ServerSocket(port) equivale alle tre seguenti righe:
SocketAddress locEndpoint = new InetSocketAddress(“localhost”,port);
ServerSocket ascolto = new ServerSocket();
[Link](locEndpoint);

pag. 61
Advanced Java rev. 1.0 Novembre 2012

Il ciclo di ricezione ha la forma di un do-while; l’istruzione centrale è la lettura dall’input stream di rets,
[Link], che è bloccante, ossia ritorna quando avviene la lettura, e restituisce in n, variabile intera, il numero
di byte letti. Ciò che è stato ricevuto viene quindi stampato a video, premettendo il numero n di byte ricevuti.

Tuttavia l’istruzione [Link] può restituire n = -1, valore che determina la fine del ciclo do-while; tale valore
rappresenta l’end of file, e viene ricevuto quando la controparte chiude l’output stream del client socket cs;
questo punto, molto importante, verrà ulteriormente discusso e chiarito nel seguito.

Se la stringa ricevuta coincide con “fine”, allora siamo nel caso di chiusura passiva: la variabile booleana
fine_ricevuta viene settata a true, mentre l’uscita dal ciclo avviene al ciclo seguente, quando [Link]
restituisce n = -1.

Nel caso di chiusura attiva, il ciclo di ricezione termina per lo stesso motivo, però in questo caso il valore di
fine_ricevuta rimane false.

In uscita dal ciclo di ricezione, il codice del metodo run chiude l’input stream is, poi, nel solo caso di
fine_ricevuta true, cioè chiusura passiva, invoca il metodo termina dell’istanza di ExitObject, che determina
la fine dell’applicazione; altrimenti, nel caso di chiusura attiva, il metodo run si limita a terminare, e con esso
termina il thread di ricezione.

Gestione degli errori.

La gestione degli errori presente entro Receiver è in buona parte funzionale, in quanto pone rimedio a
situazioni patologiche che possono verificarsi con una certa frequenza.

Può accadere che l’applicazione Telefono venga posta in ascolto su una porta già occupata da un’altra
applicazione, in questo caso la creazione del server socket ascolto non va a buon fine: l’eccezione che si
verifica, di tipo IOException, è intercettata dal codice di Receiver (tramite un costrutto try-catch) e gestita
dando un messaggio di errore e poi terminando sul nascere l’applicazione, mediante l’invocazione del
metodo termina dell’oggetto exitObj.

Un altro caso patologico importante concerne il comportamento che l’applicazione deve assumere quando la
comunicazione con l’interlocutore cade in modo non previsto, ad esempio a causa di un crash
dell’interlocutore oppure di una caduta della rete: in questi casi si verifica

Scenario di utilizzo.
Segue uno scenario concreto di utilizzo dell’applicazione tra due macchine distinte, poste sulla stessa rete.
Qui assumo che gli interlocutori siano newconfsrv e sccver, due macchine Linux, in rete locale.

Suppongo di lanciare per prima l’applicazione su newconfsrv: java –jar [Link] sccver 15000 16000, poi
(entro 15 secondi) quella su sccver: java –jar [Link] newconfsrv 16000 15000.

pag. 62
Advanced Java rev. 1.0 Novembre 2012

Come si vede dalle figure, newconfsrv crea il server socket sull’endpoint <newconfsrv:15000>; i tentativi di
creare il client socket cs non vanno a buon fine finchè sccver non parte e crea il suo server socket,
sull’endpoint <sccver:16000>. Quando ciò accade, la creazione del client socket cs su newconfsrv va a buon
fine, viene creato il socket che ha endpoint locale <newconfsrv:61287> ed è connesso all’endpoint remoto
<sccver:16000>.

Le cose vanno analogamente su sccver: qui la creazione del client socket va subito a buon fine, con
endpoint locale <sccver:43184>, e connessione all’endpoint remoto <newconfsrv:15000>.

Quando sccver ha creato il socket cs, il sistema ha assegnato la porta locale 43184, mentre l’endpoint
remoto è stato deciso dal codice – si tratta di <newconfsrv:15000>; il socket appena creato si è connesso
all’endpoint remoto: dal punto di vista dell’applicazione Telefono su newconfsrv, ciò si è tradotto in una
accept a buon fine del server socket ascolto: l’istruzione [Link] ha restituito il scoket rets. Il socket
rets su newconfsrv ha endpoint locale <newconfsrv:15000>, mentre l’endpoint remoto al quale è connesso è
l’endpoint locale del socket (remoto: è cs su sccver) che ha compiuto la accept, ossia <sccver:43184>.

Analogamente, il socket rets su sccver ha come endpoint locale <sccver:16000>, ed è connesso all’endpoint
remoto che è l’endpoint locale di cs su newconfsrv, cioè <newconfsrv:61287>.

Una volta avvenuta la creazione dei socket rets sulle due macchine, la comunicazione avviene tra questi
ultimi e i client socket cs; una volta stabilite le connessioni, potrei anche chiudere i server socket e la
comunicazione continuerebbe senza problemi.

15000 cs

rets 43184
L
ascolto

61287 rets

cs 16000
L

ascolto
newconfsrv sccver

pag. 63
Advanced Java rev. 1.0 Novembre 2012

Lo scambio di messaggi avviene quindi tra le coppie rets, cs. Nello scenario, il primo a scrivere è sccver
(scrive ciao, chi sei ?), ciò significa che la stringa è scritta sull’output stream di sccver-cs ed è ricevuta
sull’input stream di newconfsrv-rets. Analogamente, la risposta di newconfsrv (stringa ciao sccver, sono
newconfsrv) è scritta sull’output stream di newconfsrv-cs ed è ricevuta sull’input stream di sccver-rets. Non
c’è sincronismo, le due applicazioni possono parlarsi addosso.

Infine, l’operatore su sccver scrive la stringa fine: questa determina la fine del loop di invio e l’immediata
chiusura dell’output stream di sccver-cs; fatto ciò, l’applicazione su sccver attende l’attesa della fine del
proprio thread di ricezione, testando [Link], inizialmente true. Che accade nel frattempo ?

La stringa fine viene ricevuta sull’input stream di newconfsrv-rets: dopo la stampa a video e la scritta
L’interlocutore ha riagganciato, viene posta fine_ricevuta = true, quindi viene eseguito un altro ciclo:
stavolta l’istruzione [Link], lettura dall’input stream di newconfsrv-rets, restituisce -1, perché su sccver è
stato chiuso l’output stream di cs. Ciò provoca l’uscita dal ciclo di ricezione di newconfsrv.

Sempre su newconfsrv, dopo l’uscita dal ciclo di ricezione, il codice del metodo run di Receiver scopre che
fine_ricevuta è true, quindi chiude l’input stream di newconfsrv-rets e subito dopo invoca [Link],
che chiude tutti i socket ancora aperti e pone fine all’applicazione.

La chiusura dei socket e dei loro stream su newconfsrv fa sì che nel ciclo di ricezione su sccver, l’istruzione
[Link], lettura dall’input stream di sccver-rets, restituisca -1: così avviene l’uscita dal ciclo, con fine_ricevuta
a false; con ciò, il codice del metodo run di Receiver su sccver si limita a chiudere l’input stream di sccver-
rets e termina (senza invocare [Link]).

A questo punto, nel main di Telephone, sempre su sccver, l’istruzione [Link] restituisce false, così mil
codice prosegue invocando [Link], che pone fine all’applicazione anche su sccver.

Considerazioni finali sui socket in Java.

Un socket è uno strumento di comunicazione dati tra due endpoint, uno detto locale ed uno detto remoto; un
socket non esiste di per sé, esiste solo all’interno di un processo, e l’endpoint locale è sempre situato sulla
stessa macchina nella quale esegue il processo ospite; invece l’endpoint remoto può appartenere ad una
diversa macchina, anzi questo è il caso di maggior interesse.

Il socket permette lo scambio di dati tra i due endpoint, mediante uno stream di input e uno di output: lo
stream di input, sul quale si dice che il socket legge, va dall’endpoint remoto all’endpoint locale, mentre lo
stream di output, sul quale si dice che il socket scrive, va nel senso opposto.

Il server socket è una comodità messa a disposizione da alcune piattaforme, tra le quali Java; in pratica è un
socket che vede solamente un endpoint locale. Il server socket, una volta istanziato, attende connessioni da
parte dei (client) socket, che indirizzano l’endpoint gestito dal server socket come loro endpoint remoto:
quando il server socket accetta la connessione di un client socket, viene istanziato un socket, detto returning
socket, che da quel momento in poi dialoga con il client socket. Il returning socket vede come endpoint
locale quello del server socket, e come endpoint remoto l’endpoint locale del client socket connesso.

Il server socket restituisce un returning socket per ogni singola connessione, non per singolo client; se lo
stesso client effettua tre connessioni, vengono restituiti tre returning socket distinti.

La classe che implementa un socket è [Link], quella che implementa un server socket è
[Link].

pag. 64
Advanced Java rev. 1.0 Novembre 2012

Introduzione euristica al Remoting di Java.

Java dispone di gestione degli oggetti remoti senza bisogno di ricorrere a Corba, nemmeno al Corba system
embedded presente nelle piattaforme Java recenti; il suo remoting nativo è il framework RMI.

L’applicazione console EmployeeServer è costruita tramite un Java project; ha due package, app contenente
le classi Server e RemoteEmployeeClass, e rem, che contiene la classe Empl e l’interfaccia
RemoteEmployeeInterface.

Il build file è semplicissimo, minimale, con le voci <clean>, <init>, <compile> e <jarGen> minimali; c’è anche
il tag <copy>, che scrive il JAR file in ExeJar. In quanto al lancio, è sufficiente il comando seguente, eseguito
in un command prompt in ExeJar: java –jar [Link] %1.

La classe Server contiene il metodo main, ed è referenziata nel manifest.

Il metodo main alla partenza legge tutti i dati della table PEOPLE (database DBPeople) entro il membro
statico Empl[] employees della classe Server; la classe Empl appartiene al package rem:
public class Empl implements Serializable
{
public int m;
public String nome;
public String cognome;
public String CF;
public Empl()
{
m = 0;
nome = cognome = CF = "ND";
}
@Override
public String toString()
{
return m + " " + nome + " " + cognome + " " + CF;
}
}

Letti i dati, la connessione con Oracle viene chiusa, tutte le ricerche avverranno sui dati in memoria.

Ogni classe usata per il trasporto dei dati in RMI deve implementare l’interfaccia Serializable, altrimenti si
verifica un’eccezione runtime, NotSerializableException, ogni volta che un’istanza della classe viene inviata.

L’architettura RMI prevede un object registry, cioè una struttura temporanea nella quale le applicazioni
possono immagazzinare o reperire i riferimenti a oggetti remoti; il riferimento a un oggetto remoto nel registry
è di tipo nominativo: il server che vi scrive il riferimento all’oggetto assegna al riferimento un nome
(arbitrario), che i client dovranno utilizzare per accedere i metodi dell’oggetto remoto.

Il registry viene acceduto mediante un endpoint noto, con porta default 1099; l’applicazione EmployeeServer
utilizza localhost e porta 1000, tuttavia può essere passato un diverso valore della sola porta mediante il
parametro di passaggio %1 al lancio dell’applicazione, letto nel main come args[0].

Il registry non è una struttura permanente; il registry viene creato da un’applicazione server S, che lo mette a
disposizione sull’endpoint <localhost:port> e vi scrive dentro (operazione bind) riferimenti a uno o più oggetti
remoti. Ogni altra applicazione A può accedere il registry e referenziare gli oggetti, il che ne fa
un’applicazione client; ma se A, una volta acceduto il registry, cerca di comportarsi da server scrivendovi
dentro il riferimento ad un oggetto ossia tentando un’operazione bind, allora A riceve un errore bloccante, di
tipo BindException.

Quindi il registry è strettamente associato all’applicazione server S che l’ha creato, e quando S termina, il
registry viene disallocato e i tentativi dei client di referenziare in esso un oggetto falliscono. Alla ripartenza di
S, viene creato un nuovo registry, sia pure sullo stesso endpoint, vuoto: non è possibile salvare i riferimenti.

pag. 65
Advanced Java rev. 1.0 Novembre 2012

Le applicazioni accedono al registry mediante l’interfaccia [Link], mentre la

classe operativa è [Link]. Servendosi dei metodi di quest’ultima, il main
crea il registry: Registry registry = [Link](port).

Poi il main prosegue istanziando un oggetto server, di tipo RemoteEmployeeClass:

RemoteEmployeeClass remobj = new RemoteEmployeeClass(employees)

In generale, un oggetto remoto si presenta al mondo dei client tramite un’interfaccia, di cui l’applicazione
server fornisce un’implementazione attraverso una propria classe. Qui, l’interfaccia è definita nel package
rem, nel file [Link]; essa espone i metodi ammissibili di invocazione remota:
public interface RemoteEmployeeInterface extends Remote
{
public Empl getEmployeeByMatr(int m) throws RemoteException;
public Empl[] getEmployeeByRange(int mIni,int mFin) throws
RemoteException;
public Empl[] getEmployeeByName(String s) throws RemoteException;
}

ciascun metodo deve avere la clausola throws RemoteException, necessariamente, pena errori runtime
di tipo IllegalArgumentException che impediscono la partenza dell’applicazione.

La classe RemoteEmployeeClass che implementa l’interfaccia appartiene al package app.

Ha due membri privati, listaEmpl di tipo Empl[] e l’intero nEmpl; il costruttore riceve l’array con i dati, e con
tali dati riempie listaEmpl e valorizza nEmpl, così l’istanza di RemoteEmployeeClass dispone dei dati letti
dalla table PEOPLE, e i tre metodi ricavano di lì i dati richiesti.

Il primo metodo restituisce un oggetto di tipo Empl in base al match sulla matricola passata; il secondo
restituisce un array Empl[] che comprende tutti gli impiegati aventi matricola nel range passato; il terzo
restituisce un array Empl[] che comprende tutti gli impiegati il cui cognome inizia con il parametro s.

Torno al main di Server: una volta creato l’oggetto remobj, viene prodotto lo stub dell’oggetto da esporre nel
registry, si dice che l’oggetto viene esportato:
RemoteEmployeeInterface estub =
(RemoteEmployeeInterface)[Link](remobj,port);

Dopo l’esportazione, lo stub è già pronto sulla porta a ricevere le chiamate e girarle all’oggetto server, però
per raggiungerlo, un client dovrebbe spedire messaggi direttamente all’endpoint <localhost:port>, ciò che
manca è l’associazione del nome simbolico allo stub e quindi all’oggetto.

Si dice che il binding è il processo di assegnazione del nome simbolico all’oggetto, ma più precisamente il
binding è l’assegnazione di un nome simbolico visibile ai client allo stub già in ascolto sull’endpoint
<localhost:port> del registry. Il nome simbolico è una stringa qualsiasi; qui non esistono namespace: anche
se si possono scegliere nomi come [Link], non si può dire che esista poi un namespace
VirgoSpace indipendente dagli oggetti che contiene, come invece è in Corba.

L’istruzione che effettua il binding è [Link]("EmployeesObj",estub), essa agisce come la

bind, ma rimpiazza un eventuale binding precedente – mentre bind genererebbe un’eccezione.

Eseguita la bind, l’oggetto server è disponibile alle chiamate dei client, e l’applicazione resta in attesa.

Quando il ciclo d’attesa viene interrotto, il codice del main esegue l’unbind dell’oggetto dal registry, ciò che
viene eliminato è solo il nome simbolico dal registry, anche se l’oggetto resta attivo finchè l’applicazione host
non termina: ciò significa che un client già connesso può continuare a invocarne i metodi, sebbene un nuovo
client non possa più raggiungerlo – esattamente come in Corba.

Adesso studio un’applicazione client prototipale, EmployeeClient, anch’essa di tipo console; è costruita
tramite un Java project, ha due package, app contenente la classe Client, e rem, completamente copiato
dall’omonimo package dell’applicazione server – ogni client deve fare ciò.

Il build file è semplicissimo, minimale, con le voci <clean>, <init>, <compile> e <jarGen> minimali; c’è anche
il tag <copy>, che scrive il JAR file in ExeJar. In quanto al lancio, è sufficiente il comando seguente, eseguito
in un command prompt in ExeJar: java –jar [Link] %1 %2.

pag. 66
Advanced Java rev. 1.0 Novembre 2012

La classe Client contiene il metodo main, ed è referenziata nel manifest.

Il metodo main alla partenza recupera gli eventuali parametri di passaggio, nome del nodo e porta sui quali è
presente il registry creato da EmployeeServer, entro i membri registryHost e registryPort; i valori default
sono localhost e 1000. I due membri vengono usati per reperire il registry:
Registry reg = [Link](registryHost,registryPort);

In realtà, il successo dell’operazione non è garanzia di correttezza, non si verificano errori nemmeno se
l’applicazione server non è in esecuzione e quindi il registry non esiste. Gli eventuali errori si verificano al
passaggio successivo: stub = (RemoteEmployeeInterface)[Link]("EmployeesObj"), ove
stub è membro privato della classe Client, di tipo RemoteEmployeeInterface.

Il metodo lookup è l’analogo RMI del metodo resolve di Corba: se tutto va bene, crea un oggetto stub
dell’oggetto remoto.

A questo punto l’applicazione entra nel ciclo indefinito di chiamata dei metodi dell’oggetto remoto: l’operatore
passa da tastiera una certa stringa, il codice del main tenta di interpretarla come un numero; se si tratta
davvero di un numero, lo assegna alla variabile intera n che usa come matricola di ricerca:
Empl e = [Link](n);
if (e == null) [Link]("Impiegato inesistente");
else [Link]("Impiegato: " + e);

Se invece si verifica un errore di formato, il codice del main invoca un altro metodo dell’oggetto remoto:
Empl[] eList = [Link](txt);
if (eList == null) [Link]("Nessun impiegato trovato");
else for (int i=0;i<[Link];i++) [Link](eList[i]);

l’applicazione EmployeeClient termina quando l’operatore passa un input vuoto.

In ultimo, c’è ancora un metodo fornito dall’interfaccia Registry, molto utile, che non è stato usato dalle due
applicazioni: è il metodo list, che restituisce un array di stringhe contenente tutti i nomi simbolici presenti nel
registry; ecco un esempio d’uso, ove reg è oggetto di tipo Registry: String[] srvs = [Link]().

Eventi remoti.
Faccio una premessa: aggiungo un contatore di richieste ricevute all’oggetto remoto, istanza della classe
RemoteEmployeeClass. Aggiungo alla classe RemoteEmployeeClass il membro privato, intero, cReq: il
contatore parte da 0 e aumenta di un’unità ogni volta che un metodo remoto viene invocato.

Voglio che l’oggetto remoto, istanza della classe RemoteEmployeeClass, al verificarsi di certe condizioni al
suo interno, possa effettuare la raise di eventi verso i client connessi; i client riceveranno dati d’evento, e
attiveranno event handler.

Ad esempio, voglio che l’oggetto remoto, ogni volta che un suo metodo, eseguendo la ricerca voluta da un
client, si imbatta in un impiegato la cui matricola è un quadrato (ad esempio 1 oppure 100 o 900), sollevi un
evento nel quale passa il nominativo (cioè cognome e nome separati da un blank, in un’unica stringa) e il
numero della richiesta (cioè il valore di cReq) che ha provocato la raise dell’evento.

Aggiungo alla classe RemoteEmployeeClass il metodo privato int isSquare(int m): se la matricola m è
un quadrato, ne restituisce la radice; altrimenti restituisce -1.

Modifico il metodo getEmployeeByMatr, che viene ad assumere il codice seguente:

@Override
public Empl getEmployeeByMatr(int m) throws RemoteException
{
cReq++;
for (int i=0;i<nEmpl;i++)
if (listaEmpl[i].m == m)
{
int r = isSquare(m);
if (r != -1) fireSquareEvent(listaEmpl[i].cognome+"
"+listaEmpl[i].nome,r);
return listaEmpl[i];

pag. 67
Advanced Java rev. 1.0 Novembre 2012

}
return null;
}
Effettuo un’analoga modifica negli altri metodi, getEmployeeByRange e getEmployeeByName: anche in essi,
ogni volta che il valore della matricola trattata è un quadrato, viene invocato il metodo fireSquareEvent;
siccome possono esserci più casi di matricole quadrate, una sola chiamata può sollevare più eventi.

Lato server.
Ecco la definizione del metodo (privato, non serve che sia visibile al di fuori della classe):
private void fireSquareEvent(String nominativo, int r)
{
... codice applicativo ...
}

Cosa deve fare il metodo fireSquareEvent ? Deve:

i) creare un oggetto evento, contenente i dati d’evento, ossia nominativo, radice della matricola e
contatore della richiesta
ii) invocare l’event handler di ciascun client in lista, passandogli come parametro l’oggetto evento.

Il codice applicativo del metodo fireSquareEvent deve realizzare i punti sopra definiti.

La classe dalla quale vengono istanziati gli oggetti evento, che chiamerò SquareEventObject, dev’essere un
subtipo della classe [Link]; creo la classe nel package rem, in quanto dovrà essere
ovviamente utilizzata anche dai client. Non serve farle implementare l’interfaccia Serializable, in quanto lo fa
già il supertipo EventObject.

Ecco come viene generata la classe SquareEventObject, avendo chiesto alla IDE di creare gli stub per i
costruttori e i metodi astratti derivati dal supertipo:
public class SquareEventObject extends EventObject
{
public SquareEventObject(Object source,String nomen,int rad, int
cnt)
{
super(source);
// TODO Auto-generated constructor stub
}
}

Il parametro source è tipico delle classi evento. A tutti gli effetti, è un dato d’evento.

Definisco i campi corrispondenti ai dati d’evento e le proprietà readonly usate dai client per accederli, e
riscrivo il costruttore (quello ereditato non mi basta):
public class SquareEventObject extends EventObject
{
private Object source = null;
private String nominativo = "";
private int radice = 0;
private int cntReqs = 0;
public SquareEventObject(Object source,String nomen,int rad, int
cnt)
{
super(source);
[Link] = source;
[Link] = nomen;
[Link] = rad;
[Link] = cnt;
}
public Object getSource()
{ return [Link]; }
public String getNominativo()
{ return [Link]; }
public int getRadice()

pag. 68
Advanced Java rev. 1.0 Novembre 2012

{ return [Link]; }
public int getCntReqs()
{ return [Link]; }
}

Quindi la prima riga del codice del metodo fireSquareEvent, che realizza il punto i), è la seguente:
private void fireSquareEvent(String nominativo, int r)
{
SquareEventObject eve = new SquareEventObject(this, nominativo, r,
cReq);
...
}
Esamino il punto ii): ogni client dell’oggetto di tipo RemoteEmployeeClass, interessato a ricevere l’evento
SquareEventObject, deve presentarsi all’oggetto come un listener dell’evento; quindi devo definire
un’interfaccia unica attraverso la quale l’oggetto server vede tutti i client, al di là delle loro specificità.

Ciò si traduce nella definizione dell’interfaccia SquareEventListener, che pongo ovviamente in rem (la
useranno i client); essa deve contenere la dichiarazione dell’event handler:
public interface SquareEventListener extends Remote
{
public void SquareEventHandler(SquareEventObject e) throws
RemoteException;
}
L’interfaccia deve estendere Remote, per ovvi motivi.

Dal punto ii) si evince che l’oggetto remoto deve avere al suo interno una lista dei client ai quali dovrà
mandare gli eventi; inoltre, ogni client si presenta all’oggetto attraverso l’interfaccia SquareEventListener.
Mettendo assieme le due proposizioni, segue che la classe RemoteEmployeeClass deve avere un membro
definito come private Vector<SquareEventListener> vListeners = null.

L’oggetto deve creare il vettore, vuoto, quando viene istanziato; quindi aggiungo al costruttore di
RemoteEmployeeClass l’istruzione vListeners = new Vector<SquareEventListener>().

L’aggiunta degli elementi al vettore non è responsabilità dell’oggetto server, ma sarà fatta dai client che si
registreranno per ricevere gli eventi.

Ecco il codice finale del metodo fireSquareEvent, che scorre la lista dei listener e per ogni listener trovato
invoca l’event handler:
private void fireSquareEvent(String nominativo, int r)
{
SquareEventObject eve = new SquareEventObject(this, nominativo, r,
cReq);
ListIterator<SquareEventListener> ite = [Link]();
while ([Link]())
{
try
{
[Link]().SquareEventHandler(eve);
}
catch (Exception exc)
{
<segnalazione d’errore>
}
}
}
Resta ancora un punto importante: i client devono potersi registrare e anche deregistrare in merito alla
ricezione degli eventi, cioè aggiungere e togliere elementi al vettore vListeners. Quest’ultimo è privato, ed è
giusto che sia così, la soluzione corretta è fornire due metodi pubblici, li aggiungo all’interfaccia che l’oggetto
remoto espone ai client, ossia l’interfaccia RemoteEmployeeInterface del package rem:
public interface RemoteEmployeeInterface extends Remote

pag. 69
Advanced Java rev. 1.0 Novembre 2012

{
public void addSquareEventListener(SquareEventListener sel) throws
RemoteException;
public void removeSquareEventListener(SquareEventListener sel) throws
RemoteException;
public Empl getEmployeeByMatr(int m) throws RemoteException;
public Empl[] getEmployeeByRange(int mIni,int mFin) throws RemoteException;
public Empl[] getEmployeeByName(String s) throws RemoteException;
}
La classe RemoteEmployeeClass implementa i due nuovi metodi:
@Override
public void addSquareEventListener(SquareEventListener sel) throws
RemoteException
{
[Link](sel);
}
@Override
public void removeSquareEventListener(SquareEventListener sel) throws
RemoteException
{
[Link](sel);
}

Questo completa le modifiche necessarie alla gestione degli eventi remoti. Si noti che la classe Server è
rimasta inalterata.

Lato client.
Adesso passo all’applicazione client, EmployeeClient: prima di tutto, aggiorno il suo package rem,
copiandovi quello di EmployeeServer.

Per poter gestire gli eventi di tipo SquareEventObject, la classe Client deve implementare l’interfaccia
SquareEventListener, e deve quindi implementarne il metodo SquareEventHandler:
@Override
public void SquareEventHandler(SquareEventObject e)
{
[Link]("L’impiegato " + [Link]() +
" ha radice(matricola) = " + [Link]() +
" <richiesta n. " + [Link]() + ">");
}

Ecco come si presentano le applicazioni, una volta funzionanti – la figura seguente è un’anticipazione, la
prima finestra è quella in cui è attivo EmployeeServer, mentre le altre due mostrano due istanze
contemporanee dell’applicazione EmployeeClient:

pag. 70
Advanced Java rev. 1.0 Novembre 2012

Come si può vedere, la prima istanza client ha scatenato l’evento, invocando il metodo getEmployeeByMatr
su un impiegato avente matricola quadrata: l’evento è evidentemente giunto a entrambe le istanze client,
nonostante la seconda istanza non avesse ancora invocato alcun metodo.

Torno al codice del client. La classe client deve porre il proprio event listener nella lista dell’oggetto remoto,
per farlo deve invocare il metodo [Link], prima di entrare nel ciclo di chiamata
dei metodi remoti. Inoltre deve invocare il metodo [Link] una volta uscito
dal ciclo e prima di terminare, in modo da rimuovere l’event listener, che altrimenti resterebbe come un ramo
secco nella lista dell’oggetto remoto, causando anzi un’eccezione su EmployeeServer.
C’è un problema: i metodi [Link] e [Link]
devono ricevere in ingresso un oggetto di tipo SquareEventListener, verosimilmente il riferimento al client
stesso, per cui la scelta più semplice sarebbe la scrittura di un’istruzione come
[Link](this). Tuttavia il codice della classe Client è contenuto nel metodo
statico main, perciò non si può usare this.

L’ostacolo è facilmente aggirabile, mediante il seguente codice (non serve definire un costruttore esplicito):
public static void main(String[] args)
{
... codice iniziale ...
Client cli = new Client();
[Link](cli);
... ciclo di chiamata dei metodi remoti ...
[Link](cli);
... codice finale ...
}

Tuttavia questo codice non funziona: l’esecuzione dell’istruzione [Link](cli)

causa l’eccezione NotSerializableException. A rigore, il messaggio d’errore non è illuminante, perché il
problema non sta nella serializzabilità o meno dell’oggetto [Link]. Il vero problema è il seguente: affinchè
un oggetto sia utilizzabile in operazioni remote, non basta che l’oggetto implementi l’interfaccia Remote,
bisogna che l’oggetto venga esportato. Ecco quindi il codice funzionante:
public static void main(String[] args)
{
... codice iniziale ...
Client cli = new Client();
[Link](cli,0);
[Link](cli);
... ciclo di chiamata dei metodi remoti ...
[Link](cli);
... codice finale ...
}

Passando 0 come secondo parametro nella chiamata [Link], viene

affidata al sistema la scelta della porta: il sistema utilizza una porta libera di sua scelta. Una volta assegnata,
viene comunque utilizzata la stessa porta per tutta la durata dell’applicazione9.
Con ciò, le modifiche all’applicazione EmployeeClient sono finite.
Notare: la chiamata al metodo exportObject restituisce un oggetto di tipo Remote, che è un riferimento
all’oggetto esportato cli; avrei potuto quindi scrivere il seguente codice:
public static void main(String[] args)
{
9
Avrei potuto scegliere nel codice una porta libera, ad esempio la 2000; anche in questo caso, la porta
persisterebbe per tutta la durata dell’applicazione.

pag. 71
Advanced Java rev. 1.0 Novembre 2012

... codice iniziale ...

Client cli = new Client();
SquareEventListener estub =
(SquareEventListener)[Link](cli,0);
[Link](estub);
... ciclo di chiamata dei metodi remoti ...
[Link](estub);
... codice finale ...
}

Di solito si preferisce scrivere questo secondo tipo di codice.

Miglioria alla gestione eventi sul lato server.

Come si è detto, se un client che riceve gli eventi termina senza aver effettuato la rimozione del proprio
listener, oppure se il client esce regolarmente ma nel suo codice manca l’istruzione di rimozione, allora si
verifica un’eccezione nell’oggetto remoto di tipo RemoteEmployeeClass; l’eccezione si ripresenta ogni volta
che l’oggetto effettua la raise dell’evento, ossia ogni volta che, eseguendo il metodo fireSquareEvent, tenta
di richiamare tra gli altri l’event handler del client non più presente.

Posso far proseguire l’oggetto remoto, però il ripetersi dell’eccezione è causa di forte rallentamento.

Per ovviare a questo problema, è sufficiente che nel codice del metodo fireSquareEvent della classe
RemoteEmployeeClass venga effettuata la rimozione dell’event listener causa dell’errore:
private void fireSquareEvent(String nominativo, int r)
{
SquareEventObject eve = new SquareEventObject(this,
nominativo,r,cReq);
ListIterator<SquareEventListener> ite = [Link]();
while ([Link]())
{
try
{
[Link]().SquareEventHandler(eve);
}
catch (Exception exc)
{
<segnalazione d’errore>
[Link]();
}
}
}

In questo modo l’eccezione si verifica una sola volta.

La gestione degli eventi remoti nell’applicazione AppReflex.

L’applicazione AppReflex, basata su una Swing dialog, è client dell’oggetto server RemoteEmployeeClass,
di cui EmployeeServer è host, e può o meno gestire gli eventi remoti di tipo SquareEventObject. Il progetto
AppReflex include una copia del package rem tra i sorgenti, e la classe AppReflex ovviamente deve
implementare l’interfaccia [Link].

La classe AppReflex ha i membri statici remEmplHost e remEmplPort, i cui default sono rispettivamente
localhost e 1000, ma possono assumere valori diversi, passati dalla riga di comando e assegnati nel main; i
due membri servono per localizzare il registry messo a disposizione da EmployeeServer.

Oltre ad essi, la classe dispone del membro privato: RemoteEmployeeInterface estub = null.
Alla partenza, viene eseguita la routine initialize, che alla fine compie la connessione col registry, la
risoluzione dell’oggetto server e l’export dell’istanza di AppReflex (this) come fruitore d’eventi:
Registry ereg = [Link](remEmplHost,remEmplPort);
estub = (RemoteEmployeeInterface)[Link]("EmployeesObj");
[Link](this,0);
ho trascurato la possibilità di errori.

pag. 72
Advanced Java rev. 1.0 Novembre 2012

La classe AppReflex implementa il metodo SquareEventHandler, cioè l’event handler:

@Override
public void SquareEventHandler(SquareEventObject e) throws
RemoteException
{
[Link]("<Query> Impiegato " + [Link]() +
" ha radice(matricola) = " + [Link]() + " <richiesta n. " +
[Link]() + ">");
}
Questo metodo mostra nella lista centrale della dialog i dati d’evento, quando essi vengono ricevuti.

Si può notare che manca ancora un tassello nella gestione degli eventi, cioè la registrazione dell’event
handler: quest’operazione tuttavia alla partenza non viene effettuata, per cui gli eventi non vengono ricevuti.

La dialog dispone di un tasto, eveBtn, e di una label affiancata, lblGE, che permettono ciclicamente
l’attivazione/disattivazione della ricezione eventi: inizialmente lblGE ha valore (scritta) Non attivi,
concordemente all’inattività della ricezione eventi; premendo il tasto, la label commuta il suo testo a Attivi,
e viene invocato il metodo (privato, della dialog) listenEvent, il quale esegue il codice di inizio della ricezione
eventi, ossia: [Link](this), al netto della gestione degli errori.

Se in seguito il tasto eveBtn viene premuto ancora, la label torna alla scritta Non attivi, e viene invocato il
metodo (privato, della dialog) disposeEvent, il quale esegue il codice di terminazione della ricezione eventi,
ossia: [Link](this), al netto della gestione degli errori.

Così, la ricezione degli eventi nell’applicazione AppReflex può essere abilitata o disabilitata a runtime quante
volte si vuole.

Nella figura soprastante, AppReflex ha la ricezione eventi attiva; la dialog non ha eseguito query sugli
impiegati (le textbox sono vuote), però un altro client di EmployeeServer l’ha fatto, e AppReflex riceve i dati
d’evento e li visualizza nella lista centrale.

pag. 73
Advanced Java rev. 1.0 Novembre 2012

Introduzione euristica a Corba nativo in Java.

Il framework di Java fornisce una propria implementazione di Corba, che chiamo Corba nativo in Java;
l’implementazione fa parte di Java SE e non si limita a fornire API, oltre a queste fornisce anche programmi
e tool: in particolare, entro <JAVA_HOME>/bin sono presenti [Link], [Link], [Link].

Il programma [Link] (ORB Daemon) è un runtime Corba, ne è parte integrante il servizio di naming
persistente NameService. Il programma [Link] è un’applicazione console che permette le operazioni
di registrazione, deregistrazione, startup e shutdown di server persistenti. Il programma [Link] è l’utility
usata per generare le classi Java da un file IDL.

Attraverso due applicazioni, NativeServer e NativeClient, mostrerò le principali feature di Corba nativo. Prima
di operare con Corba nativo, è necessario attivare orbd; nel mio modus operandi, mi posiziono con un
command prompt in ExeJar e do il comando d’attivazione: orbd –ORBInitialPort 1050, che attiva il
programma sull’host locale e sulla porta 1050, quest’ultima diviene la porta d’ascolto di NameService.

Il programma orbd è bloccante; se voglio lasciar libero il command prompt, devo premettere start al
comando d’attivazione; in ogni caso, orbd dev’essere terminato con ^C.

L’applicazione server NativeServer.

L’applicazione, di tipo console, consiste di un oggetto Corba server e del suo host. È sviluppata mediante un
Java project; in esso è definito il folder IDL, contenente [Link]:
module cheers
{ interface Greetings
{ string say_hello(in string nomeCli,in string msg);
string say_cnthello(in string msg,in long long cnt);
};
};
nel progetto c’è il build file, con il target <idlGen> che richiama [Link] per creare le classi Java dal file IDL:
<target name="idlGen" description="idlj activation">
<exec executable="idlj">
<arg line="-fall" />
<arg line="-td src"/>
<arg value="IDL/*.idl"/>
</exec>
</target>

L’opzione –fall garantisce la generazione di tutte le classi, sia lato client sia lato server; l’opzione –td sta per
target directory, usandola compare il package cheers entro src. All’interno del package cheers compaiono i
tipici file Corba: le classi GreetingsHelper, GreetingsHolder, _GreetingsStub, GreetingsPOA, e le interfacce
GreetingsOperations e Greetings.

Implementazione dell’oggetto server.

La classe da cui si istanzierà l’oggetto server è GreetingsImpl, nel package app. Servendomi della IDE, la
creo come subtipo di GreetingsPOA:
package app;
import [Link];
public class GreetingsImpl extends GreetingsPOA
{
@Override
public String say_hello(String nomeCli, String msg)
{
return null;
}
@Override
public String say_cnthello(String nomeCli, long cnt)
{
return null;
}

pag. 74
Advanced Java rev. 1.0 Novembre 2012

al posto del predefinito return null, scrivo il codice effettivo dei due metodi:
public String say_hello(String nomeCli, String msg)
{
return "Hello Client " + nomeCli + ", hai scritto " +
new StringBuilder(msg).reverse();
}
public String say_cnthello(String nomeCli, long cnt)
{
return "Hello Client " + nomeCli + ", hai passato il numero " +
[Link](cnt);
}

Il progetto NativeServer referenzia LibJar/[Link].

Partenza e collegamento al NameService.

Nel package app creo la classe Server, dotata di metodo main, avente funzione di hosting dell’oggetto
remoto. La classe ha i membri NShost e NSdoor, coi valori default rispettivamente localhost e 1050, ma
riassegnabili tramite parametri di lancio passati dalla riga di comando; questi vengono usati per
l’inizializzazione dell’oggetto ORB, e serviranno per il collegamento al NameService:
Properties props = new Properties();
String corbalocNS = "corbaloc:iiop:1.2@"+NShost+":"+[Link](NSdoor)
+"/NameService";
[Link]("[Link]",corbalocNS);
ORB orb = [Link](new String[]{}, props);

Qui ho usato il sistema d’indirizzamento corbaloc, con la specificazione d’uso di GIOP 1.2 (il default sarebbe
GIOP 1.0). Avrei potuto usare due diverse proprietà:
[Link]("[Link]", [Link](NSdoor));
[Link]("[Link]", NShost);

in questo caso il protocollo utilizzato sarebbe stato GIOP 1.0.

Notare: a differenza di quanto accade con Orbacus, scrivendo [Link]((String[])null, props) non ci
sarebbero stati problemi.

Seguono la risoluzione e il narrow di RootPOA, quindi l’invocazione del metodo activate del POAManager
(con omissione della gestione errori):
[Link] obj = orb.resolve_initial_references("RootPOA");
[Link] rootPOA =
[Link](obj);
[Link] manager = rootPOA.the_POAManager();
[Link]();

se non venisse chiamato il metodo activate, tutto andrebbe apparentemente bene, ma alla fine le chiamate
dei client ai metodi dell’oggetto server resterebbero inservite.

C’è la risoluzione della root del NameService, servizio di naming di ORBD:

[Link] obj = orb.resolve_initial_references("NameService");
[Link] nsRoot =
[Link](obj);

Creazione o risoluzione di un namespace (contesto) applicativo.

Il codice del metodo main prosegue, tentando la risoluzione del namespace (anche detto contesto)
applicativo SpazioNativo; se il contesto non esiste, allora tenta di crearlo:
String ctxName = "SpazioNativo";
[Link][] myCtx = new
[Link][1];
myCtx[0] = new [Link]();
myCtx[0].id = ctxName;
myCtx[0].kind = "";
[Link] vs = null;

pag. 75
Advanced Java rev. 1.0 Novembre 2012

try
{
obj = [Link](myCtx);
vs = [Link](obj);
}
catch ([Link]>[Link] e)
{
vs = nsRoot.bind_new_context(myCtx);
}

ho lasciato la sola gestione errori relativa alla non esistenza del contesto. In uscita dal codice precedente,
se non ci sono stati altri errori rispetto all’eventuale NotFound, l’oggetto vs rappresenta il contesto.

Creazione e bind dell’oggetto server.

Dopo la risoluzione (o creazione) del contesto SpazioNativo, viene creata un’istanza della classe
GreetingsImpl, e viene ricavato da essa lo stub lato server, greetings:
GreetingsImpl greetingsImpl = new GreetingsImpl();
Greetings greetings = greetingsImpl._this(orb);

Segue quindi il vero e proprio bind dell’oggetto, ossia l’esposizione dello stub greetings nello spazio dei nomi
di NameService, all’interno del contesto SpazioNativo, con il nome simbolico ServerGreetings:
String srvName = "ServerGreetings";
NameComponent[] myObj = new NameComponent[1];
myObj[0] = new NameComponent();
myObj[0].id = srvName;
myObj[0].kind = "Singleton";
[Link](myObj, greetings);

il metodo rebind agisce come bind, ma non dà errore se c’è già un’istanza dell’oggetto server (cioè, dello
stub), si limita a rimpiazzarla; questa scelta è utile se si teme la presenza di possibili stub rami secchi.

Per effetto dell’operazione di bind, l’oggetto server viene associato ad un nome simbolico, che i client
potranno utilizzare per accedere all’oggetto, servendosi ovviamente del servizio di naming.

Ingresso nello stato d’attesa e terminazione.

L’oggetto server è pronto a servire le richieste dei client. Per evitare che l’applicazione host termini, invoco
[Link], che blocca il thread corrent; prima di ciò, mi predispongo all’uscita ordinata dell’applicazione:
seguendo un sistema usuale, creo un timer task – istruzione new Taskent, che si attiva ogni 10 secondi:
[Link] tmr = new [Link]();
Taskent task = new Taskent(orb,srvName,vs,act,duo);
[Link](task,10000,10000);
[Link]();

La classe Taskent, appartenente al package app, estende TimerTask; il suo costruttore si limita a valorizzare
i membri interni, poi ogni volta che il timer scade (cioè ogni 10 secondi) viene eseguito il metodo run della
classe: viene eseguito il test di esistenza del file [Link], nella directory di lancio dell’applicazione (cioè in
ExeJar), e se il file non esiste, il metodo run termina; se invece il file esiste, viene cancellato e viene eseguito
il codice seguente:
NameComponent[] myObj = new NameComponent[1];
myObj[0] = new NameComponent();
myObj[0].id = srvName;
myObj[0].kind = "Singleton";
[Link](myObj);
[Link](true);
[Link]();

la prima parte si occupa dell’operazione di unbind dell’oggetto server, ossia cancella il riferimento simbolico
all’oggetto dallo spazio dei nomi, più precisamente dal contesto SpazioNativo. L’oggetto server è ancora
vivo, un client già connesso può continuare a invocarne i metodi, ma nessuna nuova connessione all’oggetto
tramite il suo nome simbolico può essere effettuata.

pag. 76
Advanced Java rev. 1.0 Novembre 2012

Poi viene invocato il metodo shutdown dell’oggetto ORB, e dopo viene invocato il metodo destroy
dell’oggetto ORB: l’oggetto ORB viene distrutto e quindi il thread precedentemente bloccato nella [Link]
viene sbloccato, e l’applicazione NativeServer termina.

Costruzione e lancio dell’applicazione.

L’esposizione del codice applicativo è completa, passo adesso alla costruzione (build) dell’applicazione,
quindi passo all’analisi del build file, [Link].

Finora ho esposto il solo target <idlGen>; altri target sono <clean>, <init>, <compile>, <jarGen> e <copy>.

In caso di primo build, devo eseguire per primi <idlGen> e <init>, non importa in quale ordine; il target <init>
crea la consueta directory build.

Se si tratta di un build completo ma successivo al primo, allora inizio con il target <clean>, che elimina le
directory build e src/cheers, quest’ultima è la directory generata in src dall’azione del target <idlGen>; poi
eseguo <idlGen> e <init>, non importa l’ordine, come nel caso di primo build.

In caso di build completo, non importa se sia il primo o meno, proseguo con i target <compile>, <jarGen> e
<copy>, nell’ordine. Segue il codice ant, molto semplice:
<property name="[Link]" value="C:/LibJar/[Link]" />
<path id="[Link]">
<pathelement location="${[Link]}"/>
</path>
<target name="compile" description="Compilation target">
<javac includeantruntime="false" destdir="build" encoding="ISO-8859-
1">
<classpath>
<path refid="[Link]"/>
</classpath>
<src path="." />
</javac>
</target>
<target name="jarGen" description="Compression target">
<jar manifest="[Link]" jarfile="${appname}.jar"
basedir="build">
<zipfileset src="${[Link]}" />
</jar>
</target>

L’encoding in <javac> evita problemi di lettere accentate, che compaiono nei file generati da <idlGen>:
utilizzo come set di caratteri gli stessi usati dal progetto Eclipse. Il manifest si limita a referenziare laclasse
[Link] come starting point dell’applicazione.

Il target <copy> copia [Link] in ExeJar.

Il lancio dell’applicazione è immediato: java –jar [Link] orbdHost orbdPort, se ho lanciato [Link]
sullo stesso host dell’applicazione e la porta è 1050 posso omettere i due parametri di lancio.

L’applicazione client NativeClient.

L’applicazione, di tipo console, è sviluppata mediante un Java project; in esso è definito il folder IDL,
contenente [Link], preso dal progetto NativeServer.

Il build file ha il target <idlGen>, identico all’omonimo presente nel build file del progetto NativeServer.

Partenza e collegamento al NameService.

Nel package app creo la classe Client, dotata di metodo main. La classe ha i membri nomeClient, NShost e
NSdoor, coi valori default rispettivamente ClienteNativo, localhost e 1050, ma riassegnabili (nell’ordine)
tramite parametri di lancio passati dalla riga di comando; i valori di NShost e NSdoor vengono usati per
l’inizializzazione dell’oggetto ORB, e serviranno per il collegamento al NameService. Il codice di
inizializzazione dell’oggetto ORB è identico a quello utilizzato nel progetto NativeServer.

pag. 77
Advanced Java rev. 1.0 Novembre 2012

Trattandosi di applicazione client, è assente tutto il codice di gestione relativo a RootPOA e POAManager, si
passa direttamente al collegamento al NameService, che avviene con lo stesso codice impiegato nell’ambito
del progetto NativeServer.

Poi il codice del metodo main di Client risolve il contesto SpazioNativo, è lo stesso codice impiegato
nell’ambito del progetto NativeServer – con la differenza che stavolta il contesto deve essere presente, se
non lo fosse l’applicazione terminerebbe, anziché tentare di creare il contesto mancante.

Risoluzione dell’oggetto server e invocazione dei suoi metodi.

Dopo la risoluzione del contesto SpazioNativo, viene tentata la risoluzione dell’oggetto server:
String srvName = "ServerGreetings";
NameComponent[] myObj = new NameComponent[1];
myObj[0] = new NameComponent();
myObj[0].id = srvName;
myObj[0].kind = "Singleton";
obj = [Link](myObj);
Greetings greetings = [Link](obj);

Se la risoluzione,comprensiva di narrow, va a buon fine, greetings è un valido stub per l’oggetto remoto, ed è
possibile l’invocazione dei metodi servendosi di esso; ciò viene fatto nel ciclo di funzionamento a regime
dell’applicazione NativeClient: si tratta di un ciclo di durata indefinita, nel quale l’applicazione entra appena
ha risolto l’oggetto server; nel ciclo, l’applicazione attende l’input da tastiera: se viene passato il carattere x,
l’applicazione esce dal ciclo, altrimenti utilizza l’input (stringa) come parametro di passaggio da passare al
metodo invocato.

L’input da tastiera, contenuto nella variabile stringa input, viene convertito come se si trattasse di un intero
lungo (cioè di tipo long): se la conversione riesce, il valore viene assegnato alla variabile cnt di tipo long e la
chiamata è String result = greetings.say_cnthello(nomeClient,cnt); se la conversione fallisce, viene eseguita
String result = greetings.say_hello(nomeClient,input). Segue in ambo i casi la stampa a video di result.

Uscendo dal ciclo, viene eseguita l’istruzione [Link], e l’applicazione termina.

Costruzione e lancio dell’applicazione.

L’esposizione del codice applicativo è completa, passo adesso alla costruzione (build) dell’applicazione,
quindi passo all’analisi del build file, [Link].

Il file [Link] del progetto NativeClient è uguale al file [Link] del progetto NativeServer, con un’unica
differenza, cioè il nome del progetto. Anche le sequenze d’uso dei vari target sono identiche. Rimando quindi
alla descrizione data nel progetto NativeServer.

Il lancio dell’applicazione è immediato: java –jar [Link] nomeClient orbdHost orbdPort; se accetto il
nome default del client, ClientNativo, posso omettere il primo parametro di lancio, mentre se ho lanciato
[Link] sullo stesso host dell’applicazione e la porta è 1050 posso omettere gli ultimi due parametri.

Scenario semplice di funzionamento.

Inizio lanciando [Link] sulla porta 1050, poi apro un command prompt in ExeJar e lancio NativeServer,
con il comando java –jar [Link]. Una volta che NativeServer ha raggiunto lo stato di attesa delle
chiamate da parte dei client, apro un secondo command prompt in ExeJar e lancio NativeClient, utilizzando
il comando java –jar [Link] (accettando implicitamente nomeClient = ClientNativo).

Messaggi GIOP utilizzati da Corba nativo in Java.

In questo capitolo vengono esposti i messaggi GIOP utilizzati dai programmi NativeServer e NativeClient, e
anche da ORBD; per le descrizioni generali dei messaggi GIOP, rimando al documento [Link], qui
viene effettuato lo studio delle particolarità inerenti a Corba nativo in Java.

Modifiche al software volte ad effettuare il dump dei messaggi GIOP.

Il software di Corba nativo in Java è già predisposto alla possibilità di dump dei messaggi GIOP, tuttavia si
sono resi necessari alcuni studi preliminari, che hanno portato all’individuazione del punto in cui intervenire,
e poi la realizzazione di un espediente.

pag. 78
Advanced Java rev. 1.0 Novembre 2012

Individuazione del punto in cui intervenire.

Inizialmente, intendevo sostituire la classe ORB e/o qualche altra classe ad essa correlata con una classe da
me riscritta, in grado di effettuare il dump dei messaggi GIOP. La classe sostitutiva doveva essere in grado
di effettuare le operazioni compiute dall’originale, perciò mi serviva il codice della classe originale, anzi mi
servivano i sorgenti delle classi Java volte all’implementazione di Corba.

Ho scaricato i sorgenti di Java, disponibili nel download di JDK (versione 1.7). Poi ho richiesto ad un
programma che usa Corba nativo, ad esempio NativeClient, di informare a quale classe appartenga l’oggetto
restituito dalla chiamata [Link]:
ORB orb = [Link](new String[]{}, props);
[Link]("ORB type = "+[Link]().getName());

Ne risulta che il tipo è [Link], appartenente a [Link]; a questo punto, so quale

sia il sorgente da esaminare: detta JavaSrc la directory radice in cui ho scaricato i sorgenti, trovo il sorgente
desiderato in JavaSrc/com/sun/corba/se/impl/orb/[Link].

Ecco la definizione della classe: public class ORBImpl extends [Link].

Nel codice della classe ORBImpl non trovo riferimenti interessanti al protocollo GIOP, così provo a
esaminare il suo supertipo, la classe [Link], della quale trovo il sorgente in
JavaSrc/com/sun/corba/se/spi/orb/[Link]. Questa classe non va confusa con la classe astratta
[Link], importata nel codice applicativo di NativeServer e NativeClient.

Esaminando JavaSrc/com/sun/corba/se/spi/orb/[Link], scopro che la classe (astratta) ha il membro

public boolean giopDebugFlag = false, che suona promettente… in effetti, tramite una ricerca
scopro che ne fanno uso le classi MessageBase e CDROutputObject.

La classe (astratta) [Link] è alla base

di tutti i messaggi GIOP ricevuti dalle applicazioni: i metodi readGIOPHeader, readGIOPBody della classe
MessageBase stampano il dump esadecimale dei messaggi GIOP se e solo se giopDebugFlag è true.

La classe [Link] è alla base di tutti i messaggi GIOP

spediti dalle applicazioni: il metodo writeTo della classe CDROutputObject stampa il dump esadecimale
dei messaggi GIOP se e solo se giopDebugFlag è true.

Perciò, per stampare i messaggi GIOP è sufficiente ridefinire il membro giopDebugFlag della classe
[Link], come public boolean giopDebugFlag = true.

Soluzione adottata.
Non ho voluto modificare i sorgenti originali di Java e rigenerare la JVM, via assai discutibile; ho preferito
creare una mia versione della classe [Link], identica all’originale tranne che
nel valore del membro pubblico giopDebugFlag.

Entro il progetto Uti, ho creato il package [Link] e in esso ho creato la classe ORB,
copiando il codice dell’originale e modificando solamente il valore di giopDebugFlag, posto true. Ho quindi
rigenerato la libreria [Link] in LibJar.

Per poter vedere il dump dei messaggi GIOP, mi basta lanciare le applicazioni (NativeServer, NativeClient)
usando l’opzione –Xbootclasspath/p:LibJar/[Link].

Messaggi GIOP scambiati con ORBD NameService.

Nell’esempio, ho attivato [Link] sulla porta 1050; sullo stesso computer, lancio NativeServer:
java –Xbootclasspath/p:LibJar/[Link] –jar [Link] > [Link]

l’output viene scritto entro il file di testo [Link], consentendo una comoda analisi dei messaggi GIOP.

Le chiamate [Link], resolve_initial_references(“RootPOA”), narrow di RootPOA, [Link] e

resolve_initial_references(“NameService”) non danno luogo a scambio di messaggi.

pag. 79
Advanced Java rev. 1.0 Novembre 2012

La narrow di NameService invece porta ad uno scambio di quattro messaggi tra NativeServer e ORBD: una
prima richiesta da parte di NativeServer, al quale ORBD risponde con un location forward, quindi seconda
richiesta da parte di NativeServer e risposta finale da parte di ORBD.

Primo messaggio di richiesta.

Ecco il dump del messaggio:
47 49 4F 50 01 02 00 00 00 00 01 2B GIOP message header
00 00 00 05 03 00 00 00 00 00 00 00 00 00 00 0B
4E 61 6D 65 53 65 72 76 69 63 65 00 00 00 00 06
5F 69 73 5F 61 00 00 00 00 00 00 03 00 00 00 11
00 00 00 02 00 02 00 00 4E 45 4F 00 00 00 00 02
00 14 00 00 00 00 00 06 00 00 00 AA 00 00 00 00
00 00 00 28 49 44 4C 3A 6F 6D 67 2E 6F 72 67 2F
53 65 6E 64 69 6E 67 43 6F 6E 74 65 78 74 2F 43
6F 64 65 42 61 73 65 3A 31 2E 30 00 00 00 00 01
00 00 00 00 00 00 00 6E 00 01 02 00 00 00 00 0C Request header
31 39 32 2E 31 36 38 2E 31 2E 33 00 1A 40 00 00
00 00 00 19 AF AB CB 00 00 00 00 02 5D DD 3A 12
00 00 00 08 00 00 00 00 00 00 00 00 14 00 00 00
00 00 00 02 00 00 00 01 00 00 00 20 00 00 00 00
00 01 00 01 00 00 00 02 05 01 00 01 00 01 00 20
00 01 01 09 00 00 00 01 00 01 01 00 00 00 00 26
00 00 00 02 00 02 00 00 00 00 00 00
00 00 00 2B 49 44 4C 3A 6F 6D 67 2E 6F 72 67 2F
43 6F 73 4E 61 6D 69 6E 67 2F 4E 61 6D 69 6E 67 Request body
43 6F 6E 74 65 78 74 45 78 74 3A 31 2E 30 00

Dal GIOP message header si vede che la versione di protocollo utilizzata è proprio la 1.2, e che si tratta di
un messaggio di richiesta.
Analizzando il Request header, si scopre che come Addressing Disposition è usata la object key, però viene
passata da NativeServer non l’effettivo valore di object key (quale potrei leggere dal IOR di ORBD), ma la
sola stringa NameService. L’operazione richiesta è _is_a, e il suo parametro è passato nel Request body, ed
è IDL:[Link]/CosNaming/NamingContextExt:1.0. Tornando al Request header, dopo il nome
dell’operazione e l’allineamento al paragrafo di 4 byte, segue la ServiceContextList, molto lunga.

pag. 80
Advanced Java rev. 1.0 Novembre 2012

Realizzazione diretta di siti web con Tomcat.

Apache Tomcat è sia un web server, sia un application server J2EE, capace quindi di ospitare servlet,
pagine JSP e web service. La versione che utilizzerò è Tomcat 7; è installata su una macchina Windows,
ove è presente Java EE con JDK, versione 1.7.
In generale, con Tomcat è possibile gestire applicazioni web sia statiche, ossia composte da sole pagine
HTML (con eventuali sezioni <script>), sia dinamiche, nelle quali cioè oltre al contenuto statico sono presenti
servlet o pagine JSP. Tomcat può ospitare applicazioni web sia statiche sia dinamiche.
Normalmente un sito, ossia un’applicazione web (uso i due termini come sinonimi), non viene costruito
manualmente, ma mediante un apposito tool; nel seguito, utilizzerò prevalentemente Eclipse Juno for JEE
developers. Tuttavia in questo capitolo creerò un’applicazione web direttamente, cioè senza ricorrere a tool;
si tratta dell’ applicazione web First, molto semplice ma non triviale.

L’applicazione web First.

È un sito ospitato da Tomcat, che può essere acceduto da browser come [Link]

Apparenza e navigazione.
La pagina iniziale del sito consente l’accesso a una pagina JSP, a un servlet e alla pagina statica
[Link]; da ciascuno dei tre rami, è possibile solamente il ritorno alla pagina iniziale (home page):

Scegliendo il link alla pagina JSP, ottengo:

pag. 81
Advanced Java rev. 1.0 Novembre 2012

Posso, dalla pagina JSP, tornare alla home page e di lì accedere il servlet oppure la pagina Others.

Seguono le visualizzazioni delle due scelte, rispettivamente la servlet e la pagina Others:

Costruzione dell’applicazione web First.

Nella costruzione diretta che intendo operare, parto dalla directory dalla quale originerà il sito First: chiamo
First questa directory (per semplicità, non è obbligatorio); non la creo direttamente sotto C:\, solamente per
ragioni di ordine, ma all’interno di un’altra directory, per cui mi ritrovo con C:/tomcat-apps/First.

All’interno della directory First, creo tre file: [Link], [Link], [Link] – posso anche pensarli
inizialmente vuoti; poi creo le cartelle images, META-INF e WEB-INF, e dentro WEB-INF creo le
sottodirectory classes e lib.

pag. 82
Advanced Java rev. 1.0 Novembre 2012

La struttura delineata contiene alcuni elementi obbligati, ossia tali che la loro mancanza impedisce alla
directory di fungere da ricettacolo per un sito ospitabile da Tomcat; il resto è opzionale; evidenzierò man
mano gli elementi obbligatori. Un analogo discorso varrà per i contenuti: ce ne saranno di obbligati, senza i
quali Tomcat non accetterà il sito, e di opzionali.

Il welcome file [Link] e le altre pagine del sito.

La directory First, per essere candidata a ricettacolo di un sito Tomcat, deve contenere un welcome file,
ossia un file di nome index oppure default, e di estensione .html oppure .htm oppure .jsp; in First, il welcome
file è [Link]. Non ci sono requisiti particolari sui contenuti del welcome file.

In First, il welcome file consiste di hyperlink alle altre due pagine e al servlet; inoltre [Link] carica
un’immagine, [Link], e contiene testo statico. Ecco il codice HTML di [Link]:
<html>
<head><title>Applicazione First</title></head>
<body bgcolor=white>
<table border="0">
<tr>
<td><img src="images/[Link]" width=125 height=200></td>
<td>
<h1>Applicazione web First</h1>
<p>Home page di un'applicazione accademica usata per<BR>
dimostrare l'organizzazione di un'applicazione web
dinamica.
</td>
</tr>
</table>
<p>Per provare che l'applicazione funziona, si possono usare i seguenti
link:
<ul>
<li>A una <a href="[Link]">pagina JSP</a>.
<li>A un <a href="Bye">servlet</a>.
</ul>
<p>...oppure si può provare questo:<br>
<a href="[Link]">Accesso a Others</a>
</body>
</html>

pag. 83
Advanced Java rev. 1.0 Novembre 2012

La presenza della sottodirectory images non è obbligatoria, in quanto non sono obbligatorie le immagini e
non è obbligatorio porle in una directory separata; è convenzione comune tuttavia porre le immagini, quando
presenti, in una sottodirectory separata, e il nome images è il più comunemente scelto.
Il codice HTML per l’indirizzamento delle pagine [Link] e [Link] è del tutto evidente; tratterò più
avanti il codice di indirizzamento del servlet, meno immediato.
La pagina [Link] è davvero banale, non serve esporne il codice HTML.
Anche la pagina [Link] è molto semplice, con un minimo di codice Java in mezzo al codice HTML:
<html>
<head><title>Pagina JSP di saluti</title></head>
<body bgcolor=white>
<table border="0">
<tr>
<td align=center><img src="images/[Link]"></td>
<td>
<h1>Pagina JSP di saluti</h1>
output di una pagina JSP di prova
</td>
</tr>
</table>
<%= new String("Ciao, mondo Java") %>
<BR><A HREF="[Link]">Torna alla Home Page</A>
</body>
</html>
Ogni spiegazione sulla natura delle pagine JSP verrà fornita nel seguito.

La directory META-INF.
La directory META-INF non è necessaria, tuttavia è quasi sempre presente, e contiene (almeno) il manifest,
cioè il file [Link]; nel caso di First, il manifest è di nessun interesse.

La directory WEB-INF .
La directory WEB-INF non è strettamente necessaria, a meno che non siano presenti servlet o altre feature
che ne richiedono la presenza; la pagina [Link] non ne richiede la presenza. Nel caso di First, il servlet è
presente ed è usato dalla pagina [Link]; in tal caso, è obbligatorio che la directory WEB-INF esista e che
contenga la sottodirectory classes, a sua volta contenente la classe che implementa il servlet.

Inoltre WEB-INF contiene anche il file descrittivo [Link], file avente certi contenuti obbligatori; questo file
non è obbligatorio: nelle ultime versioni di servlet, conformi alle specifiche Servlet 3.0 – che Tomcat 7
implementa, il file [Link] può essere rimpiazzato (tutto o in parte) da apposite annotazioni. Tuttavia
l’applicazione web First non usa le annotazioni, quindi deve usare [Link].

Il servlet di First.
In generale, un servlet è un’applicazione, attiva in un web application server (come Tomcat), scritta in Java; il
servlet è quindi un componente server, capace di rispondere alle richieste dei client.

Dal punto di vista del sito First, il servlet è l’insieme di una classe entro WEB-INF/classes, completa del
proprio package, e di un file descrittivo entro WEB-INF, di nome [Link]; la classe che implementa il servlet
non può essere generica, ma deve soddisfare alcuni requisiti.

La locazione del codice sorgente della classe servlet è arbitraria, ma io seguo la seguente regola: creo la
sottodirectory sources entro tomcat-apps, e dentro sources creo la sottodirectory First, destinata ad ospitare
i sorgenti Java relativi al sito First.

Intendo assegnare il package [Link] alla classe servlet, perciò entro First creo le due sottodirectory,
poi creo la classe servlet (entro tomcat-apps/sources/First/app/servlets), che chiamo [Link].

La classe Ciao dev’essere subtipo di [Link]; la classe HttpServlet è astratta, ha

svariati metodi che un suo subtipo, come Ciao, deve implementare. Tra questi metodi, i più importanti sono
doGet e doPost, che gestiscono rispettivamente le richieste HTTP GET e HTTP POST; nel caso del sito

pag. 84
Advanced Java rev. 1.0 Novembre 2012

First, il servlet viene acceduto tramite hyperlink dalla pagina [Link], quindi tramite HTTP GET, con ciò la
classe Ciao implementa il solo metodo doGet.

Ecco il codice completo della classe Ciao:

package [Link];

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];

@SuppressWarnings("serial")
public class Ciao extends HttpServlet
{
@Override
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
[Link]("text/html");
PrintWriter out = [Link]();
[Link]("<html>");
[Link]("<body>");
[Link]("<h1>Ciao, mondo Java</h1>");
[Link]("<h2>è il migliore dei mondi possibili</h2>");
[Link]("<p><A HREF='[Link]'>Torna alla Home Page</A>");
[Link]("</body>");
[Link]("</html>");
}
}

Le interfacce HttpServletRequest e HttpServletResponse rappresentano rispettivamente una richiesta in

ingresso al servlet e la successiva risposta del servlet; il codice del metodo doGet usa solo response.

L’istanza response dispone del metodo getWriter, che ritorna un oggetto di tipo PrintWriter, in grado di
spedire caratteri verso il client: tutto ciò che viene scritto sullo stream di output viene passato al browser, che
lo visualizza – ecco perché dev’essere formattato HTML. La risposta che il servlet dà al browser è una
pagina HTML, completa di hyperlink di ritorno all’home page.

Allo scopo di poter compilare la classe Ciao, è necessario che il classpath referenzi la libreria
Tomcat/lib/[Link], infatti le classi dei package [Link].* appartengono ad essa; segue il
comando di compilazione, dato da un command prompt posizionato in tomcat-apps/sources/First:
javac –classpath Tomcat/lib/[Link] app/servlets/[Link]
con ciò, viene creato il file [Link] nella directory tomcat-apps/sources/First/app/servlets. Il file [Link]
va quindi copiato nella directory tomcat-apps/First/WEB-INF/classes/app/servlets.

Il file descrittivo [Link].

Scopo essenziale del file [Link] è il collegamento tra la classe presente in WEB-INF/classes e il (resto del)
sito del quale il servlet fa parte. Ecco [Link] del sito First, che è davvero ridotto all’osso:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="[Link]
xmlns:xsi="[Link]
xsi:schemaLocation="[Link]
[Link]
version="3.0">
<servlet>
<servlet-name>CiaoServlet</servlet-name>
<servlet-class>[Link]</servlet-class>
</servlet>

pag. 85
Advanced Java rev. 1.0 Novembre 2012

<servlet-mapping>
<servlet-name>CiaoServlet</servlet-name>
<url-pattern>/Bye</url-pattern>
</servlet-mapping>
</web-app>

Il servlet name è arbitrario, ma dev’essere lo stesso tra i due elementi, <servlet> e <servlet-mapping>.
L’elemento <servlet-class> entro <servlet> specifica quale sia la classe servlet, che deve trovarsi entro
WEB-INF/classes; l’elemento <url-pattern> all’interno di <servlet-mapping> assegna il link simbolico con cui
va referenziato il servlet da parte delle pagine client: assegnando /Bye (arbitrario), i client possono
raggiungere il servlet come [Link]

Ciò spiega perché la pagina [Link] acceda il servlet come <A HREF="Bye">: per una pagina che si
trova in First, il path relativo Bye equivale a First/Bye all’interno della root di Tomcat installato su user-pc, in
ascolto sulla porta 8081.

Anche un client sui generis come SocketClient può dialogare con il servlet, spedendo sulla porta 8081 di
USER-PC il seguente messaggio: GET /First/Bye HTTP/1.1
Host: user-pc

Tomcat risponde con un messaggio HTTP/1.1 200 OK, il cui body è la pagina HTML di risposta della servlet.

Passaggio dalla directory First al sito First.

Bisogna generare un WAR file contenente tutto ciò che sta dentro alla directory First; per farlo, prima creo
[Link] (vuoto) mediante WinZip o WinRar, poi gli aggiungo tutti i contenuti della directory First – cioè le
pagine HTML e JSP, e le directory images, META-INF e WEB-INF. Infine, ridenomino il file come [Link].

Effettuo il deployment di
[Link] utilizzando Tomcat
Manager: il sito First viene
creato ed è accessibile ai
client browser come un
qualsiasi sito Tomcat.

In Tomcat/webapps, trovo sia

la directory First, sia [Link].

Nota Bene: il nome del sito non dipende assolutamente da quello della directory che conteneva inizialmente
i materiali, ma solamente dal nome del WAR file di cui s’è fatto il deployment.

Se avessi chiamato Primo la directory entro tomcat-apps, continuando però a chiamare First il WAR file
contenente i materiali della directory Primo, il sito continuerebbe a chiamarsi First (e in Tomcat/webapps
troverei ancora la directory First). Infatti il WAR file contiene i materiali della directory Primo, ma non la
directory Primo, per cui l’informazione sulla directory iniziale va persa.

L’applicazione web Second.

È un sito ospitato da Tomcat, che può essere acceduto da browser come [Link]
Esteriormente e funzionalmente, il sito Second differisce molto poco dal sito First, ma dal punto di vista
programmatico introduce alcune novità importanti: prima di tutto, la possibilità di evitare l’uso del file
[Link], sostituendolo con opportune annotazioni (in accordo con la specifica Servlet versione 3.0); in
secondo luogo, viene mostrato l’uso di una libreria applicativa.

Costruzione dell’applicazione web Second.

All’interno di tomcat-apps, creo la directory First2 come copia della directory First, poi opero alcune
modifiche: elimino [Link], cambio il nome del sito da First in Second entro [Link], e cambio il codice
della classe servlet, [Link].

pag. 86
Advanced Java rev. 1.0 Novembre 2012

Uso dell’annotazione.
Allo scopo di modificare il codice di [Link], creo la directory First2 entro tomcat-apps/sources,
inizialmente copia di tomcat-apps/sources/First, poi modifico [Link] introducendo l’annotazione:
@WebServlet("/Bye")
public class Ciao extends HttpServlet
{ ... }

A parte l’uso dell’annotazione, che definisce l’URL del servlet, analogamente a quanto fatto in First da
[Link], il codice della classe resta invariato. L’annotazione @WebServlet appartiene al package
[Link], e si trova nella libreria [Link].

Il comando di compilazione, dato da un command prompt posizionato in tomcat-apps/sources/First2, rimane

uguale al comando usato nella costruzione del sito First:
javac –classpath Tomcat/lib/[Link] app/servlets/[Link]
il file [Link] viene copiato nella directory tomcat-apps/First2/WEB-INF/classes/app/servlets.

Passaggio dalla directory First2 al sito Second.

Creo un file .zip coi contenuti della directory First2, e lo chiamo [Link]; ne faccio il deploy con il Tomcat
Manager, e così facendo viene creato il sito Second.

Seconda versione del sito Second.

Modifico il servlet affinchè dia una risposta che sfrutti le informazioni contenute nella richiesta ricevuta: il
servlet deve essere in grado di interpretare una query string.

Allo scopo, modifico la chiamata al servlet nella pagina [Link]: anziché <a
href="Bye">servlet</a>, scrivo <a href="Bye?
paruno=11&pardue=22&partre=Virgi">servlet</a>. La nuova chiamata pone cioè una query string
dopo il path del servlet: il carattere ? funge da separatore tra il path del servlet e la query string; la forma
della query string è una successione di coppie key=value, separate tra loro dal carattere &. Nel mio esempio,
la query string è paruno=11&pardue=22&partre=Virgi.

Modifico il codice del metodo doGet della classe Ciao:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
String qs = [Link]();
[Link]("text/html");
PrintWriter out = [Link]();
[Link]("<html><body>");
[Link]("<h2>Ciao, mondo Java</h1>");
[Link]("<h3>è il migliore dei mondi possibili</h2>");
if (qs != null)
{
Vector<KeyVal> pars = [Link](qs);
if ([Link]() > 0)
for (KeyVal kv : pars)
[Link]("<h3>"+[Link]+"="+[Link]+"</h3>");
else [Link]("<h3>QueryString difettosa</h3>");
}
[Link]("<p><A HREF='[Link]'>Torna alla Home Page</A>");
[Link]("</body></html>");
}

L’oggetto request ha il metodo getQueryString: se il servlet è stato invocato senza query string, come
continua ad essere nel caso venga chiamato dalla pagina [Link], allora qs è null e tutto va come nel
caso della vecchia applicazione, altrimenti mi aspetto che qs sia una successione di coppie key=value
separate da &; la classe MultiUso (package uti) della libreria LibJar/[Link] ha il metodo statico
QueryStringDecomposta, che trasforma la query string in un array di coppie key-value. Il codice del metodo
doGet effettua la stampa (formattata HTML) delle coppie presenti nella hash table.

pag. 87
Advanced Java rev. 1.0 Novembre 2012

Compilazione e costruzione del WAR file.

Il comando di compilazione, dato da un command prompt posizionato in tomcat-apps/sources/First2, deve
tener conto della libreria [Link]:
javac –classpath Tomcat/lib/[Link];LibJar/[Link] app/servlets/[Link]
il file [Link] viene copiato nella directory tomcat-apps/First2/WEB-INF/classes/app/servlets.

Devo copiare la libreria

LibJar/[Link] all’interno della
directory
tomcat-apps/First2/WEB-INF/lib:
ogni libreria aggiuntiva (rispetto a
quelle di sistema di Java e a quelle
di Tomcat) va posta in questa
directory.

Fatto ciò, rigenero [Link], che

poi ridenomino [Link].

Aggiorno il sito Second su Tomcat, quindi lo accedo da un client, ecco il risultato:

Servlet standalone.
Finora ho considerato il servlet come parte integrante di un sito, sia esso First oppure Second nelle sue varie
versioni, tuttavia un servlet può anche essere standalone, ossia stare per conto suo. Di seguito, realizzo una
versione di servlet simile a quella finora utilizzata, ma standalone.

Costruzione ingenua del servlet standalone Ciao e del sito client LightSite.
Creo in tomcat-apps la directory Ciao, contenente la consueta META-INF con il manifest banale, e WEB-INF
contenente le directory lib e classes; entro classes creo la sottodirectory app/servlets, e in questa
sottodirectory copio il file [Link] già utilizzato nell’ultima versione del sito Second. Di conseguenza,
pongo la libreria LibJar/[Link] entro WEB-INF/lib.
Creo quindi [Link]:

pag. 88
Advanced Java rev. 1.0 Novembre 2012

Ridenomino [Link] in [Link] e ne faccio il deployment usando Tomcat Manager: il servlet standalone
Ciao è pronto a servire le richieste dei client.
Come primo client utilizzo SocketClient, che invia sulla porta 8081 di USER-PC il seguente messaggio:
GET /Ciao/Bye?paruno=11&pardue=22 HTTP/1.1
Host: user-pc

Tomcat risponde con un messaggio HTTP/1.1 200 OK, il cui body è la pagina HTML di risposta del servlet:
<html><body>
<h2>Ciao, mondo Java</h1>
<h3>è il migliore dei mondi possibili</h2>
<h3>paruno=11</h3>
<h3>pardue=22</h3>
<p><A HREF='[Link]'>Torna alla Home Page</A>
</body></html>
L’unico cambiamento è il mapping del servlet, non più /First/Bye ma /Ciao/Bye, ed è un cambiamento quasi
scontato, adesso il servlet “fa sito da sé”, è standalone.
Costruisco un sito client del servlet Ciao, il sito LightSite. Allo scopo, creo la directory tomcat-apps/Light
come copia dell’ultima versione di tomcat-apps/First2, quindi elimino la directory WEB-INF perché il sito non
utilizza servlet propri.
Modifico anche la pagina [Link]: al posto di <a href="Bye?
paruno=11&pardue=22&partre=Virgi">, scrivo <a href="[Link]
paruno=11&pardue=22&partre=Virgi">, in concordanza con quanto fatto usando SocketClient.
Un’analoga modifica va riportata in [Link].

Creo [Link], con i contenuti della directory tomcat-apps/Litght, poi lo ridenomino in [Link], e compio
il deployment con Tomcat Manager: il sito LightSite è pronto all’uso.

Tramite browser, accedo al sito: [Link] appare la pagina default [Link], e di qui
chiamo il servlet, che restituisce la pagina già vista. Quando però utilizzo l’hyperlink di ritorno alla home
page, ottengo un errore grave di pagina non trovata, con la descrizione The requested resource
(/Ciao/[Link]) is not available.
La spiegazione dell’errore è evidente, dopo la chiamata al servlet ci si trova nel contesto di quest’ultimo,
cioè /Ciao, non più in /LightSite.

Costruzione corretta del servlet standalone Ciao e del sito client LightSite.
Una soluzione correttamente funzionante e piuttosto elegante è quella basata sul passaggio al servlet, da
parte del client, del path della pagina cui fare ritorno.
Comincio con il servlet: la costruzione della directory tomcat-apps/Ciao e successivamente del file [Link]
resta invariata, ma cambia la classe Ciao e quindi cambia [Link] in WEB-INF/classes/app/servlets.

Creo in tomcat-apps/sources la directory Ciao, e al suo interno creo app/servlets, e vi copio la classe
[Link] già usata in precedenza, poi modifico il codice del metodo doGet:
protected void doGet(HttpServletRequest request, HttpServletResponse response)

pag. 89
Advanced Java rev. 1.0 Novembre 2012

throws ServletException, IOException

{ String qs = [Link]();
[Link]("text/html");
PrintWriter out = [Link]();
[Link]("<html><body>");
[Link]("<h2>Ciao, mondo Java,</h2>");
[Link]("<h3>io sono un servlet standalone</h3>");
String back = "";
if (qs != null)
{ Vector<KeyVal> pars = [Link](qs);
if ([Link]() > 0)
for (KeyVal kv : pars)
{
[Link]("<h3>"+[Link]+"="+[Link]+"</h3>");
if ([Link]("caller")) back = [Link];
}
else [Link]("<h3>QueryString difettosa</h3>");
}
[Link]("<p><A HREF='"+back+"'>Torna indietro</A>");
[Link]("</body></html>");
}

Si suppone che il client abbia passato il proprio path nella query string, come valore della chiave caller: il
valore viene salvato in una variabile stringa locale e poi usato per comporre l’hyperlink di ritorno.

La classe [Link] viene compilata, mediante il comando già usato nell’ultima versione del sito Second,
dopodichè [Link] viene copiata entro tomcat-apps/Ciao/WEB-INF/classes/app/servlets, viene rigenerato
il file [Link] e viene compiuto il suo deployment tramite Tomcat Manager.

Per provare la modifica, riutilizzo SocketClient, che invia sulla porta 8081 di USER-PC il messaggio:
GET /Ciao/Bye?caller=[Link] HTTP/1.1
Host: user-pc

Tomcat risponde con un messaggio HTTP/1.1 200 OK, il cui body è la pagina HTML di risposta del servlet:
<html><body>
<h2>Ciao, mondo Java,</h2>
<h3>io sono un servlet standalone</h3>
<h3>caller=[Link]
<h3>par=val</h3>
<p><A HREF='http:// USER-PC:8081/LightSite/[Link]'>Torna indietro</A>
</body></html>

È il risultato desiderato, per cui il servlet Ciao può ritenersi correttamente modificato.

Adesso passo al sito client del servlet, LightSite. Mantengo la struttura già adottata al tentativo precedente,
ma apporto alcune modifiche alle pagine che indirizzano il servlet, ossia [Link] e [Link]. Ecco
come riscrivo [Link], in modo che essa passi il proprio path al servlet:
<html>
<head>
<Title>Pagina del subsito Other</Title>
<SCRIPT language=JavaScript>
function CallServlet()
{ var ego = [Link];
[Link]("[Link]
"&paruno=11&pardue=22&partre=Virgilio",'_self');
}
</SCRIPT>
</head>
<body>
<ul>
<li><A onclick="return CallServlet();"><U>Vai al servlet</U></A>
<li><A HREF="[Link]">Torna alla Home Page</A>
</ul>
</body>
</html>

pag. 90
Advanced Java rev. 1.0 Novembre 2012

Ho “svuotato” il tag <A> del suo attributo centrale, HREF, usandolo come se fosse un HTML button, cioè
demandando l’azione a uno script sull’evento di click; lo script effettua l’accesso al servlet; anzi, è
certamente consigliabile l’uso di un HTML button, sebbene al di fuori del mio attuale interesse.

Ecco come si presentano le pagine, a sinistra [Link] e a destra la pagina di risposta del servlet:

Stavolta l’hyperlink di ritorno funziona perfettamente, c’è il ritorno alla pagina chiamante, [Link].

Una modifica analoga dev’essere effettuata all’interno di [Link]; in questo caso tuttavia vedrei come
valore di caller la stringa [Link] il che ha senso trattandosi della pagina default del
sito, comunque il buon funzionamento del ritorno dalla pagina del servlet è ancora garantito.

Servlet (standalone) che restituisce dati e non pagine HTML.

Finora ho studiato servlet che, invocate dalle pagine di un sito, restituiscono una pagina HTML completa
(dalla quale è possibile tornare alla pagina chiamante). Tuttavia è possibile, e di solito preferibile, pensare ad
una servlet che restituisca solamente un pacchetto di dati al client: in questo modo il servlet è molto più
versatile, essendo la sua risposta molto meno “ingombrante”.

Mostro nel seguito il servlet Matema, standalone, che fornisce dati e non pagine in risposta alle chiamate dei
client. Anche per questo servlet ho realizzato il solo metodo doGet; il client che lo interroga passa nella
query string il nome di una funzione e un valore, e il servlet restituisce il valore calcolato dalla funzione.

Costruzione del servlet.

In tomcat-apps/sources, creo la directory Matema con la sottodirectory app, contenente [Link], la
classe servlet; ho tolto la sottodirectory servlets, per semplicità. Ecco il codice per esteso:
package app;

import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
import [Link];
@SuppressWarnings("serial")
@WebServlet("/Eval")
public class Matema extends HttpServlet
{
@Override
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException

pag. 91
Advanced Java rev. 1.0 Novembre 2012

{ PrintWriter out = [Link]();

String fun = [Link]("Funzione");
if (fun == null)
{
[Link]("Manca la funzione");
return;
}
String val = [Link]("Valore");
if (val == null)
{
[Link]("Manca il valore");
return;
}
switch(fun)
{
case "Fattoriale":
try
{
int v = [Link](val);
long res = [Link](v);
[Link](res);
}
catch (NumberFormatException e)
{
[Link]("L'argomento "+val+" non e' un
numero");
return;
}
break;
case "CreaComplesso":
try
{
int v = [Link](val);
[Link] res = [Link](v-1,v+1);
[Link](res);
}
catch (NumberFormatException e)
{
[Link]("L'argomento "+val+" non e' un
numero");
return;
}
break;
default:
[Link]("La funzione "+fun+" non e' prevista");
return;
}
}
}

Compilo col comando già usato nell’ultima versione del sito Second, ottenendo [Link]. Poi creo in
tomcat-apps la directory Matema con le sottodirectory META-INF, banale, e WEB-INF, che contiene
LibJar/[Link] in lib e la classe [Link] in classes/app. Genero come al solito [Link] e ne faccio il
deployment con Tomcat Manager: il servlet Matema è disponibile ai client.

Come primo client utilizzo SocketClient, che invia sulla porta 8081 di USER-PC il messaggio:
GET /Matema/Eval?Funzione=Fattoriale&Valore=7 HTTP/1.1
Host: user-pc

Tomcat risponde con un messaggio HTTP/1.1 200 OK, il cui body è semplicemente 5040; non si tratta di una
rappresentazione binaria del numero 5040, ma di una sua rappresentazione testuale come flusso di byte: se

pag. 92
Advanced Java rev. 1.0 Novembre 2012

esamino il dump della risposta del servlet, scopro che il body consiste della sequenza (lunga 4 byte) 35 30
34 30, seguita dal solito accapo 0D 0A.

Il fatto che viaggi la rappresentazione testuale del dato, originariamente del tipo primitivo long, è dovuto
all’uso dell’istruzione [Link](res) da parte del codice del metodo doGet del servlet, che opera una
implicita trasformazione testuale del dato binario.

Questo meccanismo è ancora più evidente se SocketClient richiama la funzione CreaComplesso, che opera
su oggetti di tipo [Link] e non su dati primitivi:
GET /Matema/Eval?Funzione=CreaComplesso&Valore=7 HTTP/1.1
Host: user-pc

Tomcat risponde con un messaggio HTTP/1.1 200 OK, il cui body è 6+8i; questa è la rappresentazione
testuale dell’oggetto di tipo Complex: l’istruzione [Link](res) implicitamente ha chiamato il metodo
toString dell’oggetto res di tipo Complex, quindi ha scritto la stringa risultante come sequenza di byte nel
body del messaggio poi spedito al client.

Notare: non tutti i servlet rispondono ai client passando i dati testualmente; è possibile che un servlet passi i
dati di risposta in formato XML, oppure in formato binario; in seguito, vedrò esempi di questi tipi.

Un esempio di client che utilizza JavaScript.

Parto da una versione modificata del sito Light: [Link] resta la stessa, ma cambia [Link]; la nuova
pagina interloquisce con il servlet Matema.
Nella pagina ci sono: la input box argo, in cui
l’utente inserisce un valore; la lista a tendina
Funzione (controllo SELECT HTML) con cui
sceglie una funzione da richiamare, come
Fattoriale (item selezionato di default) oppure
CreaComplesso; il button HTML Bottone, che
quando premuto invia la richiesta al servlet
Matema, di tipo HTTP GET; l’input box result,
readonly, che visualizza la risposta del servlet.

Sull’evento di click del button, viene eseguita una routine scritta in JavaScript
<SCRIPT language=JavaScript>
function CallServlet()
{
var xmlHttp = null;
xmlHttp = new XMLHttpRequest();
var conn = "[Link]
Matema/Eval?Funzione="+[Link]+"&Valore="+[Link];
[Link]("GET",conn,false);
[Link](null);
var result = [Link];
[Link] = res;
}
</SCRIPT>

Lo script utilizza l’oggetto XMLHttpRequest, di cui si è parlato nel documento [Link].

Qui a sinistra, l’utente ha passato il valore 4

e ha scelto la funzione CreaComplesso, e il
risultato dell’interrogazione del servlet viene
scritto nell’input box readonly.

Osservazione importante: il metodo di passaggio dati usato dal servlet Matema è applicabile quando è
disponibile un metodo toString adeguato per la classe del dato, e quando ci si accontenta di visualizzare i
dati, senza elaborarli ulteriormente. Ciò dipende dalla scelta implementata nel codice della classe servlet, la

pag. 93
Advanced Java rev. 1.0 Novembre 2012

classe scrive il dato direttamente sull’output stream; come si vedrà a breve, nel caso del servlet Booklet, un
servlet può passare dati in formato binario, spesso vantaggioso.

pag. 94
Advanced Java rev. 1.0 Novembre 2012

Il servlet Booklet.
Prima ho realizzato alcuni servlet direttamente, senza l’uso di tool; invece il servlet Booklet è realizzato
utilizzando Eclipse. L’uso di Eclipse semplifica moltissimo le operazioni.

Il servlet Booklet fornisce informazioni relative ai contenuti del database Libreria; al momento, gestisce
quattro tipi di interrogazione: la lista dei libri (denormalizzati) per range di codici libro oppure per nominativo
dell’autore, la lista degli autori il cui cognome inizia con una certa stringa data e la lista dei generi. Si tratta di
un sottoinsieme delle funzionalità dell’applicazione desktop GestioneLibreria; per ogni chiarimento sul
database Libreria, per i dettagli sulle interrogazioni effettuabili e per le osservazioni programmatiche
sull’accesso ai dati, rimando al documento L’applicazione [Link].

Impostazione del progetto Eclipse.

Posso costruire il mio servlet, chiamato Booklet, utilizzando Eclipse nella prospettiva Java EE.
Parto da un progetto di tipo Dynamic Web project, al quale assegno il nome Booklet; per il resto, mantengo i
default proposti dal wizard:
 il target runtime è Tomcat v7.0, corrispondente al web server effettivamente presente sul computer;
 la dynamic web module version, impostata a 3.0, rappresenta la servlet API specification supportata:
l’ultima è la versione 3.1, che però richiederebbe Tomcat 8, quindi mantengo il valore default 3.0;
 alla voce Configuration, lascio il default proposto, Default configuration for Apache Tomcat v7.0, che
rappresenta la scelta più ovvia nello sviluppo di una servlet ospitata da Tomcat. In alternativa, potrei
usare JSF, Java Server Faces, il framework Java che implementa il paradigma MVC.

Lascio che il wizard non generi [Link] (la non generazione è il default, avendo scelto le specifiche 3.0).

A sinistra, viene mostrata l’organizzazione del

progetto in Eclipse.

Il nodo Java Resources contiene la directory src,

destinata ad ospitare i package sorgenti, e il nodo
Libraries, in cui, oltre al riferimento alle solite librerie
del Java runtime, si trova il riferimento a Tomcat/lib.

A livello di file system, trovo:

La directory .settings contiene file di progetto, che non m’interessano, mentre la directory WebContent ha la
stessa struttura e gli stessi contenuti della sua omologa di progetto; invece build è differente: in Eclipse si
vede vuota, mentre nel file system è presente la sottodirectory classes, vuota.

I file sorgenti applicativi vengono ospitati entro src; prima creo il package app, poi in esso creo la classe
servlet, tramite il wizard NewOtherWebServlet; come sempre, la classe creata dal wizard è subtipo
della classe [Link].

Passo il nome della classe, Maine; non definisco parametri di inizializzazione nella seconda pagina del
wizard, e come URL Mappings cambio il default proposto dal wizard, ossia /Maine, in /Answers.

Vado alla terza pagina del wizard, che si presenta come nella figura seguente.

pag. 95
Advanced Java rev. 1.0 Novembre 2012

Oltre alle scelte proposte di default, doGet e doPost, aggiungo anche la generazione dei method stub per init
e destroy.

Quindi lascio che il wizard generi il codice della classe:

@WebServlet("/Answers")
public class Maine extends HttpServlet
{
private static final long serialVersionUID = 1L;
public Maine()
{ super(); }
public void init(ServletConfig config) throws ServletException
{}
public void destroy()
{}
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException
{}
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException
{}
}

Per quanto concerne init e destroy, il codice si limita a scrivere in un log file l’atto della chiamata del metodo,
che in ambo i casi è associato ad un certo evento.

pag. 96
Advanced Java rev. 1.0 Novembre 2012

Come di consueto, in doGet e doPost viene scritto lo stesso codice, quindi un solo metodo viene
effettivamente implementato, ad esempio doGet, e l’altro metodo, in questo caso doPost, si limita a
richiamare il primo.

La gestione dei messaggi di richiesta e di risposta è presente entro il metodo doGet.

I metodi doGet e doPost.

Ecco il codice del metodo doGet:.
protected void doGet(HttpServletRequest request,HttpServletResponse
response)
throws ServletException, IOException
{
String fun = [Link]("Funzione");
Object writable = null;
switch(fun)
{
case "ListaLibrodnByAutore":
String cgn = [Link]("Nominativo");
writable = [Link](cgn);
break;
case "ListaLibrodnByRangeCod":
int ci =
[Link]([Link]("CodiceIniziale"));
int cf =
[Link]([Link]("CodiceFinale"));
writable = [Link](ci, cf);
break;
case "ListaGeneri":
writable = [Link]();
break;
case "ListaAutoreByNome":
cgn = [Link]("Nominativo");
writable = [Link](cgn);
break;
}
if (writable != null)
{
ObjectOutputStream oos = new
ObjectOutputStream([Link]());
[Link](writable);
[Link]();
[Link]();
}
}

Ed ecco il codice del metodo do Post:

protected void doPost(HttpServletRequest request,HttpServletResponse
response)
throws ServletException, IOException
{
doGet(request,response);
}

La gestione degli errori applicativi, come la mancanza di parametri di richiesta attesi, è stata omessa.

A prescindere che la richiesta sia di tipo GET oppure POST, il servlet si aspetta che venga sempre passato
un parametro chiamato Funzione. Le interrogazioni possibili sono quattro, una per ciascun valore
ammissibile del parametro Funzione, e ciascuna prevede parametri diversi, però la trattazione è
praticamente la stessa in tutti e quattro i casi.

pag. 97
Advanced Java rev. 1.0 Novembre 2012

Per l’accesso al database, vengono usati i metodi statici della classe DAO, appartenente al package dao; il
package dao è allo stesso livello del package app.

Considero il caso in cui il client abbia richiesto la funzione ListaLibrodnByAutore: il codice del metodo doGet
si attende che sia stato passato anche un parametro di nome Nominativo e ne recupera il valore, quindi
invoca il metodo apposito della classe DAO.

Il metodo public static Librodn[] listaLibrodnByAutore(String s) della classe DAO apre

una connessione al database, usando la classe OracleDriver appartenente alla libreria [Link] ed effettua
la query, cercando tutti i libri scritti da autori il cui cognome inizia con la stringa s (cioè, il valore del
parametro Nominativo passato dal client): prepara un array di tipo Librodn[], un item per ciascun libro
trovato, e lo restituisce al chiamante (cioè alla classe servlet), non prima però di avere chiuso la connessione
al database – si tratta di accesso puntuale.

La classe Librodn appartiene al package dao e deve, ovviamente, essere serializzabile; analogamente,
devono esserlo le classi Autore e Genere, insomma le classi che viaggiano (DAO non ha bisogno di essere
serializzabile perché non viaggia).

Se la query non restituisce alcun item, l’array Librodn[] restituito è vuoto ma non null; è invece null in caso di
errori di varia natura.

Il codice del metodo doGet salva il risultato entro una variabile oggetto generico, writable, in modo da non
perdere di generalità: nel caso corrente, e di Funzione = ListaLibrodnByRangeCod, writable prende il
riferimento a un oggetto di tipo Librodn[]; nel caso di Funzione = ListaAutoreByNome, writbale prende il
riferimento a un array Autore[]; quando Funzione = ListaGeneri, ad un array Genere[].

Posto che writable non sia null, viene scritto sull’output stream dell’oggetto response, si tratta di una
serializzazione di un array d’oggetti; il metodo getWriter restituisce un oggetto PrintWriter, che scrive
caratteri (testo) su uno stream, invece il metodo getOutputStream restituisce un oggetto di tipo
ServletOutputStream10, che scrive dati binari.

La chiamata al metodo flush è necessaria, in quanto effettua il commit della risposta; la chiamata al metodo
close è comunque buona norma.

Deployment e librerie necessarie.

La scrittura del codice è completa, si tratta adesso di produrre il WAR file; per farlo, in Eclipse è sufficiente
selezionare il nodo root di progetto (Booklet nella IDE), poi tasto destro e ExportWAR file:

10
La classe ServletOutputStream è astratta, la classe effettivamente usata per l’oggetto restituito dal metodo
getOutputStream è [Link] (una classe di Tomcat).

pag. 98
Advanced Java rev. 1.0 Novembre 2012

:.

A questo punto, il deployment viene come di consueto effettuato usando Tomcat Manager.

Esaminando il WAR file, noto che la sua dimensione è molto contenuta; le librerie di Tomcat non servono,
essendo già disponibili in Tomcat/lib. Serve però la libreria [Link] per l’accesso al database Oracle.

Essendo di uso assai diffuso, ho copiato [Link] entro la directory Tomcat/shared/lib, ciò ne garantisce la
visibilità a tutte le applicazioni che la necessitano, come il servlet Booklet.

Richieste e risposte.
Il servlet Booklet è pronto a ricevere le richieste dai client, ma il metodo init non viene eseguito finchè non
giunge la prima richiesta da parte di un client, cioè Tomcat istanzia la classe servlet solamente quando
giunge una richiesta client. Questo comportamento, che è il default, può essere modificato utilizzando il
parametro loadOnStartup dell’annotazione WebServlet:
@WebServlet(urlPatterns="/Answers", loadOnStartup=1)

Con ciò, Tomcat istanzia la classe servlet di Booklet alla partenza, senza attendere richieste da parte dei
client; comunque non utilizzo questa possibilità.

Come client, utilizzo SocketClient, ed invio il seguente messaggio:

GET /Booklet/Answers?Funzione=ListaGeneri HTTP/1.1
Host: user-pc
Il body della risposta è illeggibile, essendo binario; comunque, a parte tre byte precedenti (31 62 65) e
sette byte successivi (0D 0A 30 0D 0A 0D 0A), il grosso del body consiste nella serializzazione di un
array di 13 oggetti di tipo [Link], ove la classe Genere ha due campi, l’intero Codice e la stringa
descrizione; segue il dump binario, da paragonare con quanto già visto sulla serializzazione di array:
AC ED 00 05 75 72 00 0D 5B 4C 64 61 6F 2E 47 65 Intestazione e descrizione del tipo
6E 65 72 65 3B 7B 48 00 26 C5 62 EE 59 02 00 00 array, [Link][]
78 70
00 00 00 0D Numero di item dell’array
73 72 00 0A 64 61 6F 2E 47 65 6E 65 72 65 E2 C4 Descrizione del tipo [Link]
AF 2A 91 B1 55 53 02 00 02 49 00 06 43 6F 64 69
63 65 4C 00 0B 64 65 73 63 72 69 7A 69 6F 6E 65
74 00 12 4C 6A 61 76 61 2F 6C 61 6E 67 2F 53 74
72 69 6E 67 3B 78 70
00 00 00 01 74 00 0F 53 63 69 65 6E 63 65 20 46 Valori dei campi del primo item:

pag. 99
Advanced Java rev. 1.0 Novembre 2012

69 63 74 69 6F 6E Codice=1,descrizione=Science Fiction
73 71 00 7E 00 02 Riferimento alla descrizione del tipo
00 00 00 02 74 00 06 48 6F 72 72 6F 72 Valori dei campi del secondo item:
Codice=2,descrizione=Horror
...
73 71 00 7E 00 02 Riferimento alla descrizione del tipo
00 00 03 E8 74 00 05 61 6C 74 72 6F Valori dei campi dell’ultimo item:
Codice=1000,descrizione=Altro

È evidente che una comune pagina HTML non può essere un buon client; ma può esserlo un applet.

Un problema nell’implementazione delle Servlet Specifications 3.0 ?

Voglio che il servlet Booklet abbia un display name definito, in modo che venga visualizzato nella finestra di
Tomcat Manager, ad esempio Servlet Booklet. La soluzione più semplice è usare ancora l’annotazione:
@WebServlet(urlPatterns="/Answers",displayName="Booklet Servlet")

Tuttavia non vedo apparire alcunchè nella colonna Display Name di Tomcat Manager.

Se invece aggiungo al progetto Eclipse, entro WebContent/WEB-INF, un file [Link] banale, come segue:
<web-app>
<display-name>Booklet Servlet</display-name>
</web-app>

allora in Tomcat Manager appare il nome desiderato nella colonna Display Name.

pag. 100
Advanced Java rev. 1.0 Novembre 2012

L’applet BookletApplet.
Così come un servlet è un’applicazione Java che opera entro un web server, un applet è un’applicazione
Java che opera entro un browser. Così come il web server deve avere una infrastruttura adeguata ad
ospitare il servlet, deve cioè essere un web application server, sul lato client, cioè nel browser, dev’essere
disponibile il Java plug-in allo scopo di mettere in esecuzione l’applet.

Costruzione mediante Eclipse.

Creo un semplice Java project, che chiamo BookletAppletClass; creo il package app, e in esso creo la
classe applet usando il menu FileNewOtherWindowBuilderSwing DesignerJApplet: passo il nome
BookletAppletClass, e come supertipo lascio il default proposto, cioè [Link].

Ecco come si presenta inizialmente la classe BookletAppletClass:

public class BookletAppletClass extends JApplet
{
public BookletAppletClasa()
{
}
}
La classe JApplet implementa l’interfaccia Serializable, quindi si dovrebbe in generale definire un Serial ID
per ogni suo subtipo; la classe ha una sua intrinseca apparenza grafica: JApplet ha un default pane di tipo
JPanel, accessibile tramite il metodo getContentPane, che è non null fin dall’inizio; i controlli grafici in
generale vengono aggiunti al default pane, non c’è bisogno di aggiungere un nuovo pane.

Il layout default del pane è di tipo BorderLayout, ma io uso un absolute layout per comodità. Utilizzando
WindowBuilder disegno i controlli, che automaticamente vengono aggiunti al default pane.

Il codice dei controlli aggiunti con la IDE finirebbe nel costruttore; tuttavia, dopo aver aggiunto un primo
controllo, la label statica “Cognome”, il cui codice va nel costruttore, sovrascrivo il metodo init e sposto il
codice relativo al controllo inserito, dal costruttore al metodo init
@Override
public void init()
{
[Link]();
JLabel lblNewLabel = new JLabel("Cognome:");
[Link](10, 47, 57, 21);
getContentPane().add(lblNewLabel);
}

di qui in poi, il codice di ogni controllo inserito con la IDE va entro il metodo init. Il metodo init non dev’essere
chiamato dal codice applicativo, in quanto viene già invocato dal browser al caricamento dell’applet.

pag. 101
Advanced Java rev. 1.0 Novembre 2012

Il layout default del content

pane è di tipo BorderLayout,
ma io uso un absolute layout
per comodità.

Utilizzando WindowBuilder,
disegno i controlli, che
automaticamente vengono
aggiunti al content pane,
mentre il loro codice viene
scritto nel metodo init.

L’utente può introdurre una

stringa nella textbox, o
premere uno dei tre button di
ricerca: i dati vengono
visualizzati nella JTable,
dotata di 11 righe, mentre il
numero di item trovati appare
nella label in alto.
Il button Libri permette la ricerca di tutti i libri (denormalizzati) il cui autore ha cognome che inizia con la
stringa passata dall’utente nella textbox; il tasto Autori permette la ricerca di tutti gli autori il cui cognome
inizia con la stringa passata dall’utente nella textbox; il tasto Generi permette la rcierca di tutti i generi, senza
tener conto del contenuto della textbox.

Analisi del codice del metodo gestData.

Tutti e tre i button invocano il metodo gestData: private void gestData(String fun,String par)
con parametrizzazioni differenti; considero l’esempio del button Autori per illustrare il funzionamento del
codice: qui fun = ListaAutoreByNome, par = &Nominativo="+[Link]().
Il codice del metodo gestData costruisce l’URI al quale indirizzare la richiesta:
String BookletURI = BookletURIfix + fun + par;
ove la parte fissa è [Link] mentre il resto viene
composto in base ai valori dei parametri.
Seguono la connessione al servlet e l’aggancio allo stream dal quale leggere la risposta:
URL BookletURL = new URL(BookletURI);
URLConnection bkConn = [Link]();
[Link](false);
[Link](false);
InputStream rea = [Link]();
sono settate alcune proprietà della connessione, in modo che non venga usato il caching – voglio che
l’applet fornisca risposte sempre aggiornate in base ai dati ricevuti dal servlet.
La richiesta da parte del client (l’applet) viene inviata al servlet all’apertura della connessione, e la modalità
di ricezione della risposta è quella default, cioè sincrona.
Il codice successivo legge i dati contenuti nel body della risposta; il servlet ha scritto i dati in formato binario
sull’output stream, che è l’input stream dell’applet, quindi anche la lettura dev’essere in formato binario:
ObjectInputStream ostream = new ObjectInputStream(rea);
Object[] info = (Object[]) [Link]();
[Link]();
si tratta di una deserializzazione, nella quale, per mantenere la generalità del codice, il recipiente info è
definito come un array di oggetti generici (tutte le ricerche restituiscono un array).

Se si sono verificati dei problemi, ad esempio se il database era inaccessibile, info è null, viene data una
segnalazione d’errore nella label in alto, e il metodo termina. Suppongo non sia andata così nel seguito.
Definisco la matrice dei dati da passare al costruttore del table model, sempre in generale:
Object[][] objs = new Object[[Link]][[Link]];

se la ricerca non ha dato risultati, allora info è vuoto (ma non null), però la trattazione non cambia.

pag. 102
Advanced Java rev. 1.0 Novembre 2012

Segue il codice di assegnazione dei nomi delle colonne e del caricamento della matrice objs, specifico della
ricerca degli autori (è un ramo di uno switch sulla funzione, cioè sul valore del parametro fun):
nomicols[1] = "Nome";
nomicols[2] = "Cognome";
for (Autore au : (Autore[])info)
{
objs[r][0] = [Link];
objs[r][1] = [Link];
objs[r][2] = [Link];
r++;
}
L’ultima parte del codice è ancora comune:
ldnTBM = new ReadonlyTableModel(objs,nomicols);
[Link](ldnTBM);
ColumnsSizing(fun);
AggiornaLabel(fun,[Link]);
il table model viene creato con i dati e i nomi delle colonne corretti, e viene assegnato alla table; vengono
infine aggiustate le ampiezze delle colonne della table (metodo ColumnsSizing) e viene aggiornato il testo
della label in alto, che riporta il numero di item trovati:

Con ciò, l’esposizione analitica del codice è completa.

Build e deployment.
Il build file di un applet non presenta particolarità rispetto ai comuni build dei Java project: i tag sono i soliti,
nella sequenza nominale <init>, <compile>, <jarGen>; c’è il solito tag <clean>, per l’eliminazione della
working directory build.
In generale, gli applet vengono salvati in una directory virtuale del web server; io ho deciso di salvarli entro la
directory Tomcat/webapps/applets, così ho aggiunto al build file il tag <copy>, che salva l’applet nella
directory di cui sopra.
Non si può quindi parlare di un vero deployment.

Utilizzo dell’applet da una pagina HTML.

Aggiungo al sito LightSite la pagina [Link]. In generale, una pagina HTML che utilizza un
applet ha il seguente tag nel proprio codice:
<object id=BookAppl codebase="[Link]
archive="[Link]" code="[Link]"
width=450 height=290>
</object>

pag. 103
Advanced Java rev. 1.0 Novembre 2012

Avrei potuto usare il tag <applet>, esattamente con la stessa parametrizzazione, ma le versioni più recenti di
HTML deprecano il tag <applet>, che nel seguito non sarà più supportato.

pag. 104
Advanced Java rev. 1.0 Novembre 2012

Uso di Ajax per realizzare pagine HTML client di servlet.

È possibile, sotto certe condizioni, realizzare pagine HTML che accedono a servlet senza bisogno di
utilizzare applet, e quanto segue ne è un esempio semplice ma completo.

Definizione di Ajax.
Con Ajax, si intende un’architettura software, comprensiva di un certo insieme di componenti, rivolta allo
sviluppo della comunicazione tra browser e web server; l’architettura si colloca sul solo lato client.

Posto che l’obiettivo sia la realizzazione di pagine HTML che compiono interrogazioni a servizi web (siano
essi servlet o web service), le componenti essenziali dell’architettura Ajax sono tre:
 HTML (con o senza l’ausilio di CSS) per la costruzione generale della pagina;
 DOM (Document Object Model) per l’accesso agli oggetti HTML della pagina;
 l’oggetto XMLHttpRequest per l’invio di richieste e la ricezione delle relative risposte.

In quanto a JavaScript e XML, si può parlare di componenti non strettamente essenziali, ma assai frequenti.
Per utilizzare l’oggetto XMLHttpRequest e anche il DOM, è necessario uno script language, e JavaScript è
una scelta non obbligata ma assai frequente. In quanto a XML, è certamente il formato più diffuso per i
messaggi di richiesta e risposta scambiati tra l’oggetto XMLHttpRequest e i servizi sul lato server, sebbene
possano essere usati anche altri standard, come JSON.

Modifiche al servlet Booklet.

L’oggetto XMLHttpRequest consente l’invio di richieste e la ricezione di risposte; le risposte attese
dall’oggetto XMLHttpRequest possono essere di due tipi: testuali, nel qual caso la risposta è contenuta nella
proprietà responseText, oppure in formato XML, nel qual caso la risposta sta nella proprietà responseXML.

Prima si è utilizzato XMLHttpServlet per recuperare dati di tipo testuale, che infatti venivano restituiti nella
proprietà responseText; tuttavia il servlet Booklet restituisce dati binari, inadatti ad essere gestiti dall’oggetto
XMLHttpRequest. Volendo usare quest’ultimo, bisogna far sì che Booklet restituisca dati in formato XML,
oltre che in formato binario.

Allo scopo, introduco un nuovo parametro alle richieste: i client di Booklet potranno specificare l’aspettativa
di un formato XML della risposta; segue un esempio basato su una query string:

Booklet/Answers?Funzione=ListaLibrodnByAutore&Nominativo=S&XML=Y

Qui la funzione richiesta è la ricerca dei libri il cui autore ha cognome che inizia per S, e il client specifica al
servlet che vuole una risposta in formato XML.

Il codice del metodo doGet della classe servlet compie il test sul nuovo parametro XML: se e solo se il
parametro è presente ed ha valore Y, oppure y, la risposta avrà il formato XML; in caso contrario, la risposta
sarà in formato binario, e il codice non cambia rispetto alla precedente versione.

Nel caso di formato XML, viene usato il seguente codice:

PrintWriter pw = [Link]();
[Link]("text/xml");
[Link]("<doc>");
switch(fun)
{
case "ListaLibrodnByAutore":
case "ListaLibrodnByRangeCod":
...
break;
case "ListaAutoreByNome":
...
break;
case "ListaGeneri":
Genere[] lg = (Genere[])writable;
for (int i=0;i<[Link];i++)
{

pag. 105
Advanced Java rev. 1.0 Novembre 2012

[Link]("<"+recTag+">");
[Link]("<"+recIte1+">"+lg[i].Codice+"</"+recIte1+">");
[Link]("<"+recIte2+">"+lg[i].descrizione+"</"+recIte2+">");
[Link]("</"+recTag+">");
}
break;
}
[Link]("</doc>");
[Link]();

ho mostrato il codice in dettaglio per la sola funzione ListaGeneri, ma è del tutto analogo negli altri casi,
cambiano solo i tag XML. Si tratta di un codice alquanto chiaro, autoesplicativo.

È molto importante settare il content type della risposta al valore text/xml (non è il default), altrimenti la
proprietà responseXML dell’oggetto XMLHttpRequest risulterà null. Va detto che la proprietà responseText
contiene comunque la risposta, sempre, come una lunga stringa XML, in effetti il servlet invia la risposta,
però rimane null la proprietà responseXML e quindi, a meno di non usare i dati in forma di stringa XML,
contenuti in responseText, il client non sa gestire la risposta ricevuta.

Di seguito, ecco la risposta del servlet all’interrogazione di SocketClient:

Come si vede, il body del messaggio è in formato XML.

La pagina HTML PaginaAjax.

Aggiungo al sito LightSite il file [Link], richiamabile dalla home page del sito. La pagina è
funzionalmente simile all’applet BookletApplet, cioè permette di compiere tre ricerche: la lista dei libri scritti
da un autore il cui cognome comincia con una stringa passata da utente, la lista degli autori il cui cognome
comincia con una stringa passata da utente, e la lista dei generi letterari presenti nel database.

La pagina, all’ingresso, si presenta come segue:

pag. 106
Advanced Java rev. 1.0 Novembre 2012

L’utente digita la stringa con la quale intende compiere la ricerca nella textbox presso Valore, seleziona la
funzione di ricerca desiderata usando la tendina a destra, e preme il button in basso: i risultati della ricerca
appaiono in una HTML table (inizialmente non visibile), e il numero di item trovati viene scritto nella textbox
readonly presso Risultato.

Nella figura successiva, ipotizzo che l’utente abbia compiuto la ricerca su tutti i libri il cui autore ha cognome
che inizia con la lettera M.

Si tratta di una pagina veramente dinamica, in quanto non ci sono controlli nascosti che divengono visibili,
ma il codice JavaScript riscrive il codice HTML della pagina in tempo reale, in base ai risultati ottenuti dalla
interrogazione effettuata.

Le performance della pagina sono decisamente soddisfacenti, inoltre, poiché la formattazione dei dati è
effettuata dal codice JavaScript della pagina client, il servlet si limita a fornire i dati grezzi (in formato XML),
evitando quindi un sovraccarico al web server.

Struttura del codice.

La pagina è composta solamente da HTML e codice JavaScript; il tag <hml> racchiude <head> e <body>,
ove <head> contiene tutto il codice JavaScript della pagina, mentre <body> contiene solo i controlli HTML.

pag. 107
Advanced Java rev. 1.0 Novembre 2012

Codice HTML.
Comincio da <head>, lasciando per adesso indicato il tag <script>:
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-
8859-1">
<meta http-equiv="Cache-Control" content='no-cache'>
<title>Pagina client Ajax/XML di Booklet</title>
<script language="JavaScript">
...
</script>
</head>

Lo header Cache-Control settato a no-cache fa sì che la pagina sia sempre fresca, senza avvalersi di copie
in cache eventualmente presenti.

Segue quindi <body>:

<body>
<table width=600px border=1>
<tr>
<td>Valore:</td>
<td><input NAME="argo" TYPE="Text"></td>
<td><select style="width: 210px;" NAME="Funzione">
<option VALUE="ListaGeneri">Generi</option>
<option selected VALUE="ListaLibrodnByAutore">Libri per
autore</option>
<option VALUE="ListaAutoreByNome">Autori per nominativo</option>
</select></td>
</tr>
<tr>
<td>Risultato:</td>
<td><input SIZE="42" NAME="risu" TYPE="Text" readonly style="width:
264px;">
</td>
<td></td>
</tr>
</table>
<hr>
<table border=1 id="Griglia" width=600px></table>
<hr>
<ul>
<li><INPUT NAME=Bottone TYPE=Button VALUE="Al servlet remoto"
onclick="return CallServlet();">
<li><A HREF="[Link]">Torna alla Home Page</A>
</ul>
</body>

La prima table è senza nome e serve solamente come contenitore dei controlli HTML argo (ove l’utente
scrive la stringa di ricerca), Funzione (che permette di scegliere la funzione di ricerca) e risu (che mostra il
numero di item restituiti dalla ricerca).

La seconda table ha l’identificativo Griglia, in modo da essere facilmente indirizzabile dal codice JavaScript;
ha la stessa larghezza della prima table, per ragioni grafiche, ma nient’altro è definito, visto che la sua
gestione è dinamica, da parte del codice JavaScript.

L’ultima sezione della pagina definisce il button HTML utilizzato per compiere la ricerca: è qui che viene
chiamata la funzione JavaScript, CallServlet.

Codice JavaScript.
La function CallServlet prima prepara la richiesta, componendo l’URL con la query string, quindi invia la
richiesta, e poi processa la risposta: con i dati ricevuti dal servlet, costruisce le righe dati e le aggiunge alla
HTML table Griglia.

pag. 108
Advanced Java rev. 1.0 Novembre 2012

Segue il codice JavaScript di function CallServlet(), analizzato a blocchi:

a) preparazione della richiesta
var xmlHttp = new XMLHttpRequest();
var conn = "[Link]
switch([Link])
{
case "ListaLibrodnByAutore":
case "ListaAutoreByNome":
conn = conn + "&Nominativo="+[Link];
break;
case "ListaGeneri":
break;
}
Viene istanziato l’oggetto XMLHttprequest e viene composto l’URL con la query string al seguito; viene
richiesto il formato XML per la risposta.

b) invio della richiesta

[Link]("GET",conn,false);
[Link](null);
il metodo open apre una connessione al servlet, specificando che la richiesta è di tipo GET, che l’URL e la
query string da utilizzare sono quelli contenuti nella variabile conn, e che la modalità di colloquio è sincrona.
L’invio effettivo del messaggio avviene all’esecuzione del metodo send, la cui chiamata non ha parametri
trattandosi di una richiesta di tipo GET.

c) ricezione della risposta

var domus = null;
if ([Link] == null) [Link] = "xml is null";
else domus = [Link];
la risposta del servlet sta nella proprietà responseXML, ed è un oggetto XML DOM; mentre un oggetto DOM
rappresenta un documento HTML, un oggetto XML DOM rappresenta un documento XML.

d) cancellazione della HTML table di presentazione dati

var nr = [Link];
for (var i = 0;i < nr;i++) [Link](0);
tutte le righe della HTML table Griglia eventualmente presenti devono essere eliminate: al primo ingresso
nella pagina non ci saranno righe, ma saranno presenti dopo aver effettuato almeno una ricerca.

Notare: avrei potuto usare un codice alternativo, cioè:

var prgTable = [Link]("Griglia");
var nr = [Link];
for (var i = 0 ; i < nr; i++) [Link](0);
è possibile accedere i controlli HTML da codice JavaScript sia direttamente, sia mediante apposite funzioni.

e) recupero dei dati (prima parte)

var arrDati = null;
var recTag = "",oggetto = "",oggetti = "";
var ite = ["Codice","",""], w = ["10%","50%","40%"];
switch([Link])
{
case "ListaLibrodnByAutore":
recTag = "Libro";
oggetto = "libro";
oggetti = "libri";
ite[1] = "Titolo";
ite[2] = "Autore";
break;
case "ListaAutoreByNome":
recTag = "Autore";
oggetto = "autore";
oggetti = "autori";
ite[1] = "Nome";
ite[2] = "Cognome";
w[1] = w[2] = "45%";

pag. 109
Advanced Java rev. 1.0 Novembre 2012

break;
case "ListaGeneri":
recTag = "Genere";
oggetto = "genere";
oggetti = "generi";
ite[1] = "Descrizione";
ite[2] = "";
w[1] = "90%";
w[2] = "0%";
break;
}
arrDati = [Link](recTag);
var nDati = [Link];
if (nDati == 0)
{ [Link] = "Nessun "+oggetto+" trovato";
return;
}
else [Link] = "Trovati "+nDati+" "+oggetti;
i dati in Domus sono organizzati per nodi XML: il root node è <doc>, che contiene una sequenza di nodi tutti
strutturalmente uguali, ad esempio nel caso di ricerca libri per autore, i nodi entro <doc> sono tutti
organizzati come <Libro>, che a sua volta contiene i nodi <Codice>, <Titolo> e <Autore>. Il nodo <Codice> è
presente in tutti i casi, sempre in prima posizione, ecco perché lo preassegno nel literal array ite.

L’istruzione [Link] crea l’array di nodi di secondo livello, figli di <doc>; il numero
di elementi dell’array, che è il numero di item trovati dalla ricerca, viene visualizzato entro risu. Se il numero
di item trovati è zero, è inutile proseguire con la costruzione della table.

f) composizione del table header

[Link]();
var header = [Link]();
var row = [Link](0);
for (var j=0;j<[Link];j++)
if (ite[j].length > 0)
{
var cell = [Link](j);
[Link] = "<B>"+ite[j]+"</B>";
}
[Link] = "<B>"+ite3+"</B>";
per sicurezza, cancello comunque l’header (al primo ingresso non c’è), lo creo e assegno così i nomi delle
colonne della HTML table Griglia, concordi col tipo di ricerca richiesta.

g) recupero dei dati (seconda parte)

var dato,cNode,code,v,tr,td,txt;
for (var i = 0;i < nDati;i++)
{
dato = arrDati[i];
tr = [Link]("tr");
for (var k=0;k < [Link];k++)
if (ite[k].length > 0)
{
td = [Link]("td");
[Link]=w[k];
cNode = [Link](ite[k]);
v = cNode[0].childNodes[0].nodeValue;
txt = [Link](v);
[Link](txt);
[Link](td);
}
[Link](tr);
}
Il codice è autoesplicativo.

pag. 110
Advanced Java rev. 1.0 Novembre 2012

Pagina in versione asincrona.

Finora ho utilizzato l’oggetto XMLHttpRequest in modalità sincrona: la pagina client invia la richiesta (metodo
send), e attende la risposta: nel mentre, la pagina è bloccata. Solitamente Ajax viene usato in modalità
asincrona, per evitare il blocco delle pagine.

Come esempio, creo la pagina [Link], partendo da [Link], ma modificandola

affinchè operi in modalità asincrona. Dal punto di vista funzionale, le due pagine sono uguali, ma quella
asincrona non si blocca quando il servlet tarda a rispondere.

Il codice HTML delle due pagine è identico, cambia però il codice JavaScript, che necessita una
riorganizzazione profonda: la funzione CallServlet in [Link] spedisce la richiesta e processa la
risposta; in [Link] la funzione CallServlet si limita a spedire la richiesta, mentre la ricezione
della risposta e il suo processing sono compiuti da un’altra funzione, la callback function resultProcessing.

Riorganizzazione del codice JavaScript per la modalità asincrona.

Entro il tag <script>, il codice JavaScript è distinto in tre sezioni:
a) variabili comuni
b) funzione di preparazione e invio della richiesta
c) funzione di ricezione e gestione della risposta.

La sezione a) contiene la dichiarazione var xmlHttp = null; sia la funzione di richiesta, CallServlet, che
la callback function, utilizzano l’oggetto XMLHttpRequest, e devono usare lo stesso oggetto, non due istanze
diverse. Quindi la dichiarazione dell’oggetto xmlHttp dev’essere condivisa11.

Il codice della funzione CallServlet è ancora suddivisibile in preparazione della richiesta e invio della
richiesta, con alcune sottili differenze rispetto alla funzione omonima in [Link]:
a) preparazione della richiesta
if (!xmlHttp) xmlHttp = new XMLHttpRequest();
...dalla seconda riga compresa in poi, come la sezione a) del caso sincrono

b) invio della richiesta

[Link]("GET",conn,true);
[Link] = resultProcessing;
[Link](null);

stavolta la connessione al servlet aperta dal metodo open ha modalità di colloquio asincrona, in base al
valore del terzo parametro.

L’oggetto XMLHttpRequest ha la proprietà readyState, che rappresenta l’evoluzione dello stato della
richiesta; la proprietà passa attraverso una sequenza di valori interi, da 0 (prima dell’invocazione del metodo
open) fino a 4, assunto al completamento della richiesta, ossia alla avvenuta risposta, con o senza errori. La
proprietà onreadystatechange rappresenta l’evento di variazione del valore della proprietà readyState, e la
callback function è un event handler, che viene eseguito ogni volta che readyState cambia valore.

Il codice della funzione resultProcessing ha la seguente struttura:

if ([Link] == 4 && [Link] == 200)
{
...processing della risposta...
}
else if ([Link] == 4 && [Link] != 200)
alert("Errore di codice "+[Link]);

la funzione viene invocata anche quando readyState passa (da 0) al valore 1 etc, ma deve fare qualcosa
solamente quando la richiesta è stata completata. Inoltre deve distinguere tra completamento corretto
(valore 200, tipico del protocollo HTTP) e casi di errore: il processing dei dati di risposta ha senso solamente
in caso di assenza d’errori.

Il processing della richiesta è identico alla sequenza c)  g), estremi compresi, già visto nel caso sincrono.

11
Non è necessario che la sezione a) preceda le altre sezioni, infatti il codice JavaScript non è posizionale;
tuttavia il codice è più leggibile se organizzato con la sezione a) in testa.

pag. 111
Advanced Java rev. 1.0 Novembre 2012

pag. 112
Advanced Java rev. 1.0 Novembre 2012

Utilizzo della libreria axis2 per la realizzazione di Web Service e client.

La web service LibreriaWS è stata realizzata usando la libreria axis2, realizzata da Apache, predisposta
all’integrazione in Tomcat. Ho usato la metodologia bottom–up, ossia sono partito dai metodi della classe
candidata a diventare la web service, e non dalla descrizione WSDL, alla quale giungo solamente alla fine.

Quanto segue fornisce ben poche nozioni teoriche sul funzionamento delle web service in axis2, e ancor
meno sul funzionamento delle web service in generale, è invece la descrizione operativa di come si possa
scrivere una web service partendo da zero, in metodologia bottom–up, usando la libreria axis2.

Installazione di axis2.
Ho scaricato la distribuzione binaria [Link] dal sito di Apache, e ne ho unzippato i contenuti
direttamente sotto C:\; così facendo, è stata creata la directory C:\axis2-1.6.2.

Ho definito la variabile d’ambiente AXIS2_HOME, con il valore C:\axis2-1.6.2.

La directory AXIS2_HOME/webapp contiene un ant build file, [Link]; ho aperto un command prompt nella
directory, e ho dato il comando ant [Link], che ha creato la directory AXIS2_HOME/dist, contenente il
file [Link]. Per completare l’installazione, è sufficiente copiare il file [Link] entro la directory webapps
di Tomcat, con Tomcat attivo: viene creato il nodo axis2 in webapps.

Entro la directory AXIS2_HOME, sono presenti due directory di particolare interesse per lo sviluppatore: bin,
che contiene tool, e lib, contenente le librerie di axis2.

Impostazione del progetto Eclipse LibreriaWS.

È stato utilizzato un Java project, di nome LibreriaWS; creo il package ws, e all’interno di ws creo la classe
LibreriaWS, destinata ad implementare la web service: si tratta di una classe senza particolarità, non è
subipo di altre classi e non implementa alcuna interfaccia. Oltre ad essa, creo il package dao contenente le
solite classi dei dati: Autore, Libro, Librodn e MixLibro.

Poi creo il folder META-INF, allo stesso livello di src; entro META-INF creo il file [Link]. Questo file
stabilisce quale sia la classe web service, e inoltre definisce la lista dei web method (detti “operation”):

<service name="LibreriaWS">
<description>Libreria data provider</description>
<parameter name="ServiceClass">[Link]</parameter>
<operation name="DataRefresh">
<messageReceiver class="[Link]"/>
</operation>
...
<operation name="SystemInfo">
<messageReceiver class="[Link]"/>
</operation>
</service>

La classe LibreriaWS deve contenere tutti i web method elencati in [Link], definiti come pubblici. In
generale, questi metodi potrebbero anche essere vuoti, e non servirebbero nemmeno le classi dati.

Build.
Il file [Link] è composto dai target clean, init, compile, jarGen, copy.

Come di regola, utilizzo la directory build per costruire il JAR, tuttavia c’è una peculiarità legata alle Axis2
web service: build contiene la solita directory classes, ma quest’ultima, oltre ai package omonimi della
directory src – qui ws, contiene anche la directory META-INF. La directory META-INF deve contenere
[Link], in modo che quest’ultimo possa essere incluso nella generazione del JAR.

pag. 113
Advanced Java rev. 1.0 Novembre 2012

Con ciò, il target <compile> contiene, oltre al comando javac, che popola [Link] con le classi dei
package ws e dao, anche il comando di copia del file [Link] da <dir_progetto>/META-INF a
<dir_progetto>/build/classes/META-INF.

Poi il target <jarGen> si preoccupa della generazione del file [Link] (entro build); per quanto
riguarda il driver JDBC per Oracle, [Link], sono possibili due scelte: inclusione del driver nel JAR di ogni
web service che ne ha bisogno, oppure porre il driver nella directory shared/lib di Tomcat.

Ho optato per la seconda scelta, dato che quasi tutte le web service sviluppate accedono al database
Oracle; la scelta è decisamente conveniente in termini di risparmio dello spazio disco, poiché i JAR delle
web service risultano molto più piccoli. È certamente la scelta migliore quando i server Tomcat e Oracle
risiedono sullo stesso host, come nel mio caso.

Il target finale, <copy>, scrive il file nella directory repository, qui C:\aar files, cambiandone l’estensione
da .jar a .aar: ottengo così C:\aar files\[Link].

Installazione.
L’archivio C:\aar files\[Link] è la Axis2 web service, ma per funzionare deve essere inserita nel
giusto contesto. Con Tomcat attivo, lancio l’utility Axis2 Manager: passando [Link] nel
web browser, accedo alla console Axis2.

Utilizzo il link Administration, con i default Username = admin e password = axis2; nel menu Tools a sinistra,
scelgo Upload Service: tramite la form, accedo l’archivio C:\aar files\[Link] e ne faccio l’upload.

Dopo l’operazione di upload, trovo la web service copiata entro la struttura di Tomcat: il file [Link] è
presente in webapps/axis2/WEB-INF/services (webapps è il root site, in Tomcat).

Se dovessi in seguito aggiornare la web service, dovrei prima di tutto cancellare il file [Link] dalla
directory di Tomcat, poi ripetere la procedura di installazione già descritta.

WSDL, l’interfaccia verso i client.

La descrizione della web service, nel linguaggio WSDL, messa a disposizione per i client, è la seguente:
[Link] accessibile ad esempio tramite browser.

A differenza dei servizi Windows e delle web service ASMX, non viene fornita un’interfaccia direttamente
accessibile da browser, che esponga i web methods.

Modalità di accesso client alla web service.

Una web service viene acceduta dai client mediante chiamata dei metodi, detti web method: si tratta di tutti e
soli i metodi pubblici dichiarati in [Link]; sono anche detti operazioni. Nel caso di accesso a un
comune servlet, come Booklet, il client si limita a spedire un messaggio HTTP, GET o POST, contenente
tutti i parametri necessari: un servlet non ha metodi, si limita a processare messaggi di richiesta.

Una web service invece non può essere acceduta se non richiamandone i singoli web method; ci sono due
fondamentali tipi di accesso, e quindi di client: la spedizione, più o meno diretta, di un messaggio HTTP
POST alla web service, oppure l’uso di uno stub, cioè un oggetto interno all’applicazione client, che nel
contesto del client rappresenta la web service e ne espone i web method: il codice client chiama i metodi
dell’oggetto stub come se chiamasse i web method.

Di seguito mostrerò due esempi di client del primo tipo, ossia diretti; esempi di client del secondo tipo
saranno mostrati in paragrafi appositi. In seguito, chiamerò stub client i client del secondo tipo.

SocketClient.
Tramite l’applicazione SocketClient, è possibile chiamare un metodo della web service, ad esempio il
metodo GetVotoLibro: public int GetVotoLibro(int c), con c = 1003 (c è il codice del libro di cui si
vuole conoscere il voto), spedendo il seguente messaggio alla porta 8081 di user-pc:
POST /axis2/services/LibreriaWS HTTP/1.1
Content-Type: text/xml; charset=utf-8
Host: user-pc
Content-Length: 162

pag. 114
Advanced Java rev. 1.0 Novembre 2012

<s:Envelope xmlns:s='[Link]
<s:Body>
<GetVotoLibro xmlns='[Link]
<Codice>1003</Codice>
</GetVotoLibro>
</s:Body>
</s:Envelope>

L’esempio è molto istruttivo. Intanto, la richiesta è un messaggio di tipo POST che veicola un messaggio
SOAP come proprio body; non è l’unico mezzo di comunicazione con una web service, ma di certo è il più
comunemente usato. È interessante il modo di indirizzare la web service, cioè il suo endpoint: in sostanza,
una axis2 web service è un subsito (di secondo livello) del sito axis2. L’attributo Content-Type non è
strettamente necessario, ma è bene specificarlo.

Il body, che è il messaggio SOAP, è nel mio esempio ridotto all’osso: entro il tag <Body> dev’essere scritto il
nome dell’operazione (web method) come un tag XML, con il namespace proprio della web service;
quest’ultimo è determinato da ciò che viene scritto in [Link], perciò, in assenza di ridefinizioni, coincide
con [Link] ove pkg è il package al quale appartiene la classe che implementa la web service: nel caso di
LibreriaWS, il package è ws. I parametri dell’operazione, se presenti, devono essere sottonodi del nodo
operazione; il tag name dei parametri non è obbligato.

Ecco la risposta della web service:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 22 Dec 2013 16:12:59 GMT

104
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="[Link]
<soapenv:Body>
<ns:GetVotoLibroResponse xmlns:ns="[Link]
<ns:return>750</ns:return>
</ns:GetVotoLibroResponse>
</soapenv:Body>
</soapenv:Envelope>
0

La risposta, o meglio il suo body, ha il formato SOAP; il numero che precede il messaggio SOAP è la sua
lunghezza in esadecimale (260 byte).

Adesso chiamo un web method che restituisce un array di oggetti anziché un singolo valore, ad esempio
public Librodn[] BooksDnListByAuthor(String nom), con nom = Z; ecco il messaggio di
richiesta:
POST /axis2/services/LibreriaWS HTTP/1.1
Content-Type: text/xml; charset=utf-8
Host: user-pc
Content-Length: 175

<s:Envelope xmlns:s='[Link]
<s:Body>
< BooksDnListByAuthor xmlns='[Link]
<Cognome>Z</Cognome>
</ BooksDnListByAuthor>
</s:Body>
</s:Envelope>

Ecco la risposta della web service:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked

pag. 115
Advanced Java rev. 1.0 Novembre 2012

Date: Sun, 22 Dec 2013 22:05:56 GMT

2bd
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="[Link]
<soapenv:Body>
<ns:BooksDnListByAuthorResponse xmlns:ns="[Link]
xmnls:ax23="[Link]
<ns:return xmlns:xsi="[Link]
xsi:type="ax23:Librodn">
<ax23:autore>Roger Zelazny</ax23:autore>
<ax23:codice>17</ax23:codice>
<ax23:titolo>Io, l’immortale</ax23:titolo>
</ns:return>
<ns:return xmlns:xsi="[Link]
xsi:type="ax23:Librodn">
<ax23:autore>Roger Zelazny</ax23:autore>
<ax23:codice>42</ax23:codice>
<ax23:titolo>The master</ax23:titolo>
</ns:return>
</ns:BooksDnListByAuthorResponse>
</soapenv:Body>
</soapenv:Envelope>
0

I dati d’interesse, ossia gli oggetti di tipo Librodn, sono ancora contenuti nei nodi <ns:return>, però il nodo
<ns:return> è a sua volta un nodo complesso e non un semplice text node come nel caso di GetVotoLibro;
devo indirizzarne i sottonodi, però questi hanno tag name prefissato, cioè non <autore> ma <ax23:autore>, e
il prefisso non è costante: la parte ax2 è fissa, ma la parte seguente, che nell’esempio è 3, può variare. La
stessa web service, invocata sullo stesso metodo, può rispondere usando prefissi diversi nel tempo.

Queste considerazioni sono importanti ai fini dello sviluppo di client ancora diretti ma più evoluti, come la
pagina [Link], descritta nel seguito.

PaginaAjaxWS.
La pagina [Link], aggiunta al sito LightSite, somiglia molto alla pagina [Link], client
sincrono del servlet Booklet; però PaginaAjaxWS interroga (in mdalità sincrona) la web service LibreriaWS.

Il codice HTML delle due pagine è quasi identico, cambiano il titolo della pagina, il testo del button e i tag
della tendina Funzione – LibreriaWS dispone di alcuni metodi diversi da quelli di Booklet. Anche buona parte
del codice JavaScript è strettamente analoga, per cui riprenderò quant già visto per PaginaAjax.

La funzione richiamata dal button è stata ribattezzata CallWS; lo schema in sezioni adottato per CallServlet
di PaginaAjax è ancora applicabile

a) preparazione della richiesta

var xmlHttp = new XMLHttpRequest();
var conn = "[Link]
var ope = "",nPars = 0;
switch([Link])
{
case "ListaLibrodnByAutore":
ope = "BooksDnListByAuthor";
nPars = 1;
break;
case "ListaAutoreByNome":
ope = "AuthorsListBySurname";
nPars = 1;
break;
case "ListaGeneri":
ope = "GenresList";
break;
case "ListaLibroByGenere":

pag. 116
Advanced Java rev. 1.0 Novembre 2012

ope = "BooksListByGenre";
nPars = 1;
break;
case "RicaricaDati":
var resp = confirm("Sei sicuro di voler ricaricare i dati ?");
if (!resp)
{
[Link] = "Nessuna operazione";
return;
}
ope = "DataRefresh";
break;
}
var bodySoap = "<s:Envelope
xmlns:s='[Link]
"<s:Body><"+ope+" xmlns='[Link]
if (nPars == 1) bodySoap += "<p>"+[Link]+"</p>";
bodySoap += "</"+ope+"></s:Body></s:Envelope>";

Viene istanziato l’oggetto XMLHttprequest e viene assegnato conn, in conformità con quanto si è visto
nell’utilizzo di SocketClient; poi viene composto il messaggio SOAP, entro la variabile bodySoap (anche qui,
è utile il confronto con quanto si è fatto nel caso di SocketClient).

b) invio della richiesta

[Link]("POST",conn,false);
[Link](bodySoap);

il metodo open apre una connessione alla web service, specificando che la richiesta è di tipo POST, che
l’URL da utilizzare è quello contenuto nella variabile conn, e che la modalità di colloquio è sincrona. L’invio
effettivo del messaggio avviene all’esecuzione del metodo send, la cui chiamata ha come parametro il SOAP
message, che diverrà il body della richiesta HTTP POST.

Le sezioni auccessive restano inalterate, o meglio, variano solamente perché è diversa la struttura dei dati,
sia quelli in formato XML ricevuti in risposta dalla web service, sia quelli da rappresentare nella table Griglia.
Così, le sezioni c), d), f) restano identiche, mentre cambiano le sezioni e) e g): prima di tutto, l’array
contenente i dati di risposta ha un unico tag name, <ns:return>, anziché tag name distinti come <Libro>,
<Autore> e <Genere>; poi, è necessario sapere quale prefisso utilizzi la web service, allo scopo utilizzo il
codice seguente, che calcola il prefisso in prefix:
var prefix = "";
var px = [Link]("xmlns:ax2");
var py = [Link]("=",px)
prefix = [Link](px+6,py-px-6);

fatto ciò, uso il prefisso per accedere i dati, ossia:

cNode = [Link](prefix+":"+ite[k]);

con queste considerazioni, il codice delle sezioni e), g) di recupero dati continua a valere.

Notare: nel caso del servlet Booklet, il codice applicativo del servlet scrive i dati di risposta in formato XML,
perciò so esattamente quali tag sono stati usati; nel caso della web service LibreriaWS, il formato XML dei
dati non è deciso dal codice applicativo, perciò non so a priori i tag usati, ne ho un’idea di massima grazie
all’impiego di SocketClient, e devo scrivere un certo codice client per decifrare le informazioni mancanti.

Realizzazione di un client di LibreriaWS utilizzando axis2.

Prima di tutto, è importante chiarire perché sia utile sviluppare client di web service del tipo stub client. Un
client diretto, come [Link], non ha alcun legame con axis2, funziona con ogni web service,
però tratta la web service come tratterebbe un servlet, non ha la capacità di invocarne i metodi remoti.

Nel seguito mostro la realizzazione di un stub client; un client del genere è strettamente legato all’architettura
axis2, quindi lo chiamerò axis2 client – un sottoinsieme di stub client operante con axis2.

pag. 117
Advanced Java rev. 1.0 Novembre 2012

Il progetto di LibreriaWS non si riferisce mai esplicitamente a axis2: non vengono usate le librerie presenti in
axis2/lib, né i tool presenti in axis2/bin. L’aggancio all’ambiente axis2 è “automatico”, in buona parte
posizionale e in parte dichiarativo (il file, di estensione particolare .aar, deve stare in una certa directory di
Tomcat, sul quale è stato installato il sistema axis2, inoltre dev’essere presente [Link]).

Il discorso è completamente diverso per i axis2 client: questi sono applicazioni di natura qualsiasi, non hanno
alcun legame automatico al mondo axis2, nemmeno a Tomcat, quindi la costruzione del legame tra il client e
la web service è per così dire a carico del client, ed è realizzato tramite le librerie e i tool di axis2.

L’applicazione LibreriaWSClient.
Il client LibreriaWSClient è un’applicazione console, molto semplice, ma il meccanismo di riferimento
all’ambiente axis2 è del tutto generale, valido per ogni client.

L’applicazione è costruita con un Java project e il solo sorgente applicativo è [Link], nel package app.
Per la sua descrizione conviene attenersi alle diverse fasi del build file, [Link]; le prime due sono di
routine: il tag <init> genera la solita directory build, con la sottodirectory classes, il tag <clean> la cancella.

Prima di creare la classe client, posso generare le classi stub; allo scopo, definisco preliminarmente alcune
proprietà e un classpath in [Link]:
<property name="wsdlSource"
value="[Link]
<property name="[Link]" value="${env.AXIS2_HOME}/lib"/>
<property name="srcdir" value="${basedir}/src"/>
<property name="stubPkg" value="stubLibWS"/>
<path id="[Link]">
<fileset dir="${[Link]}">
<include name="*.jar"/>
</fileset>
</path>

Il loro impiego sarà evidente nel seguito.

Generazione delle classi stub per il colloquio con la web service.

Il terzo tag del build file è <WSDL2JAVA>:
<target name="WSDL2JAVA" description="Stub generation">
<echo>Creating java classes from WSDL ${wsdlSource}</echo>
<java classname="[Link].WSDL2Java" fork="true">
<classpath refid="[Link]"/>
<arg value="-uri"/>
<arg value="${wsdlSource}"/>
<arg value="-p"/>
<arg value="${stubPkg}"/>
<arg value="-d"/>
<arg value="adb"/>
<arg value="-s"/>
</java>
</target>

Viene messa in esecuzione la classe [Link] contenuta nel package [Link] della
libreria [Link]; il classpath è l’insieme dei file JAR contenuti in axis2-1.6.2/lib. In sostanza,
equivale al seguente comando, passato al command prompt (non importa la directory di lancio):
java –cp “%AXIS2_HOME%/lib/[Link];%AXIS2_HOME%/lib/[Link];
%AXIS2_HOME%/lib/[Link]” [Link].WSDL2Java

Questa è la forma minima del comando, che lancia la classe senza passarle alcun parametro; l’output del
comando si limita a mostrare l’elenco dei parametri e delle opzioni attese.

L’oggetto sul quale agisce la classe WSDL2Java è il file WSDL, introdotto dall’opzione –uri, però quando
l’aggiungo si verificano eccezioni dovute a mancanza di librerie, che aggiungo progressivamente. Alla fine, la
forma definitiva del comando, se passato al command prompt, è la seguente:
java -cp "%AXIS2_HOME%/lib/[Link];%AXIS2_HOME%/lib/[Link];
%AXIS2_HOME%/lib/[Link];%AXIS2_HOME%/lib/[Link];

pag. 118
Advanced Java rev. 1.0 Novembre 2012

%AXIS2_HOME%/lib/[Link];%AXIS2_HOME%/lib/[Link];
%AXIS2_HOME%/lib/[Link];%AXIS2_HOME%/lib/[Link];
%AXIS2_HOME%/lib/[Link];%AXIS2_HOME%/lib/[Link]"
[Link].WSDL2Java
-uri "[Link] -p stubLibWS -d adb -s

Questa forma è equivalente alla sintassi ant del target <WSDL2JAVA>, in cui parametri e opzioni sono
passati mediante la lista dei subtarget <arg>, mentre le librerie sono rintracciabili grazie al classpath.

Il file WSDL descrittivo della web service è specificato dall’opzione –uri; il nome del package a cui
appartengono i file generati dalla classe WSDL2Java è specificato tramite l’opzione –p; il tipo di
databinding12 scelto è adb (axis2 databinding), come specificato dall’opzione –d; l’opzione –s stabilisce la
modalità sincrona di colloquio (il client dopo aver effettuato una chiamata, si blocca in attesa della risposta):
se avessi omesso l’opzione –s, sarebbero stati generati classi e metodi relativi alle chiamate asincrone.

Come risultato, viene generato il file [Link] entro il package stubLibWS (situato entro la
directory src); se non avessi usato l’opzione –p, il file sarebbe stato generato entro la directory ws, creata al
momento se non già esistente, sempre interna a src.

Nella IDE appaiono alcuni errori relativi al file [Link]; possono essere risolti tramite aggiunta di
tre librerie axis2 al build path (Configure Build Pathadd external JARs, nella directory AXIS2_HOME/lib
(vedi anche la figura successiva per i nomi delle tre librerie).
Poi creo il package app e in esso la classe Client, dotata di metodo main, senza particolarità.
Supponendo di aver già compilato e generato il file JAR,
il progetto si presenta come a sinistra.

Il target <compile> non presenta peculiarità: compila le

classi dei package app e stubLibWS e le pone entro la
directory build.

Il target <jarGen> come si vedrà prevede una lista di

librerie axis2, necessarie. Il file [Link] definisce la
main class, che è [Link]. Il risultato della fase
<jarGen> è build/[Link].

Le librerie presenti nel nodo Referenced Libraries sono

un sottoinsieme ridotto di tutte quelle realmente
necessarie al funzionamento corretto dell’applicazione
(presenti nel target <jarGen>); servono solamente per
evitare errori nella IDE.

In ultimo, il target <copy> copia il JAR file in ExeJar.

Utilizzo delle classi stub nel codice dell’applicazione client.

Il codice d’interesse del programma client risiede nel main; ci sono quattro variabili, che si suppone vengano
valorizzate come parametri di lancio: ci e cf, estremi dei codici libro tra i quali compiere la ricerca (default 2 e
8, rispettivamente); host ossia il nome dell’host su cui risiede la web service (default user-pc), port ossia la
porta sulla quale la web service sta in ascolto (default 8081).

Per poter accedere ai metodi della web service, il client deve creare uno stub:
String link = "[Link]
+"/axis2/services/LibreriaWS?wsdl";
12
Nel mondo delle web service, il termine databinding si riferisce alle tecniche di conversione dei dati,
passando dai dati XML alle strutture dati applicative (interne alle applicazioni client e server), e viceversa. Il
framework axis2 ha un databinding proprio, che è adb (axis2 data binding), ma può operare anche con altri
tipi di databinding, come XMLBeans e JiBX; l’opzione –d dice alla classe WSDL2Java quale modello di
databinding utilizzare.

pag. 119
Advanced Java rev. 1.0 Novembre 2012

stub = new LibreriaWSStub(link);

La classe [Link], subtipo di [Link], è la classe creata tramite

l’utility WSDL2Java. Il costruttore riceve l’indirizzo, o meglio la descrizione, della web service, rappresentato
dal WSDL file reperito online (ma potrebbe funzionare anche un file statico).

In analogia con il caso di Corba, si può ancora dire che il client chiami il web method BooksDnListByRange,
passando i codici ci e cf, e si aspetti in ritorno un array di record di tipo Librodn; ma ci sono differenze
importanti tra l’accesso ai metodi di un oggetto via Corba e l’accesso ai metodi di una web service.

L’accesso client ai metodi di una web service è peculiare: nella classe LibreriaWS, il metodo è dichiarato
come public Librodn[] BooksDnListByRange(int ci,int cf); però la chiamata del metodo
mediante lo stub non è una semplice invocazione, come accade in Corba, ma è un’operazione più
complessa, che segue le strutture del file WSDL.

Conviene esaminare la dichiarazione del metodo nella classe Stub:

public BooksDnListByRangeResponse booksDnListByRange(BooksDnListByRange
booksDnListByRange)
throws [Link]

non esiste nella classe Stub un metodo esattamente omonimo con quello (BooksDnListByRange) della web
service, l’iniziale è minuscola anziché maiuscola (se però il metodo della web service avesse iniziale
minuscola, resterebbe inalterata); soprattutto, la signature è assai diversa: anziché due parametri di
passaggio ci e cf, è presente un solo parametro di tipo BooksDnListByRange, che è una classe statica,
interna alla classe Stub, definita public in modo da risultare visibile; il tipo del valore di risposta non è
Librodn, ma BooksDnListByRangeResponse, altra classe statica, pubblica, interna alla classe Stub.

Ecco il codice di invocazione del metodo:

BooksDnListByRange req = new BooksDnListByRange();
req.setArgs0(ci);
req.setArgs1(cf);
BooksDnListByRangeResponse resp = [Link](req);
Librodn[] ldn = resp.get_return();

Il client alloca un oggetto richiesta, di tipo BooksDnListByRange, definito anch’esso, come pure i seguenti,
entro la classe LibreriaWSStub, che contiene svariate classi al proprio interno. Se sono previsti parametri di
passaggio, come in questo caso, essi sono campi interni all’oggetto richiesta e possono essere settati
usando gli appositi metodi che l’oggetto fornisce (cioè setArgs0 e setArgs1).

Nel caso il web method preveda un oggetto di ritorno, allora la chiamata al metodo via stub restituisce un
oggetto risposta, di tipo BooksDnListByRangeResponse; l’oggetto risposta resp contiene al proprio interno
un membro di tipo Librodn[], quest’ultimo è proprio ciò che interessa al client ed è accessibile mediante il
metodo get_return dell’oggetto risposta.

Il resto del codice dell’applicazione LibreriaWSClient non presenta interesse particolare; in ultimo, uscendo
dall’applicazione, è bene invocare il metodo [Link] per liberare tutte le risorse, ma non è mandatario.

Build dell’applicazione client.

Il target <compile> di [Link] si limita a compilare sia le classi applicative (Client) sia le classi generate a
partire dal file WSDL (LibreriaWSStub). Il target <jarGen> che genera il file [Link] include una
lunga lista di librerie del framework axis2:
<target name="jarGen" description="JAR generation">
<jar manifest="[Link]" destfile="${build}/${appName}.jar">
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>

pag. 120
Advanced Java rev. 1.0 Novembre 2012

<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<fileset dir="${classes}"/>
</jar>
</target>

Queste 14 librerie devono essere sempre disponibili ad ogni applicazione client di una web service axis2,
non importa quanto semplici siano l’applicazione client e la web service.

L’applet LibreriaWSApplet.
Lo sviluppo di un applet client della web service LibreriaWS avviene in modo analogo da un lato allo sviluppo
di BookletApplet, dall’altro lato allo sviluppo di LibreriaWSClient. In sintesi, utilizzo un Java project con il
package app, nel quale creo la classe LibreriaWSAppletClass subtipo di JApplet, e il package models nel
quale è presente la classe ReadonlyTableModel, identica a quella di BookletApplet, usata per gestire la
JTable dell’applet. Segue il design dell’applet, sviluppato con WindowBuilder Editor:

L’applet ricalca la pagina [Link]: ci sono la JTextField argo, in cui l’operatore digita la stringa di
ricerca, la JComboBox Funzione con le stesse funzioni di ricerca della pagina HTML, la readonly JTextField
risu in cui mostrare il numero di elementi trovati dalla ricerca, e il JButton per l’esecuzione della ricerca; poi
c’è un separatore, al di sotto del quale sta la JTable table, posta all’interno del JScrollPane scrollPane, usata
per mostrare i dati. Il table model rotm, di tipo [Link], è assegnato a table.

Il build file [Link] consiste inizialmente dei target <clean>, <init>, <WSDL2JAVA>, <compile>, <jarGen> e
<copy>; i target <WSDL2JAVA>, <compile> e <jarGen> sono identici a quelli di LibreriaWSClient: anche qui,
utilizzando il WSDL online della web service, viene generato il package stubLibWS contenente la classe
LibreriaWSStub (stub). Lo stub viene creato (esattamente come in LibreriaWSClient) alla fine
dell’inizializzazione grafica.

Il tag <copy> è simile a quello di BookletApplet: il JAR viene copiato in Tomcat/webapps/applets.

Aggiungo al sito LightSite la pagina [Link], praticamente uguale alla pagina di lancio
di BookletApplet; al suo interno, trovo il tag <object> consueto:
<object id=LibWSAppl codebase="[Link]
archive="[Link]"

pag. 121
Advanced Java rev. 1.0 Novembre 2012

code="[Link]" width=560 height=390>

</object>

Quando però la pagina prova a lanciare l’applet, si verifica un errore bloccante: appena il codice dell’applet
tenta di creare lo stub utilizzando il WSDL online, si verifica un’eccezione di tipo
[Link], in sostanza un accesso negato alla risorsa (cioè il WSDL online);
l’eccezione è riscontrabile nella Java console del browser, e l’applet non viene neppure visualizzato.

Firma dell’applet.
Affinchè l’applet possa accedere alla risorsa WSDL online, e quindi alla web service, è necessario firmare
l’applet. Per firmare l’applet, bisogna disporre di un certificato; perciò bisogna che generi un certificato.

Questo passo viene compiuto usando il tool keytool: apro un command prompt, mi posiziono nella directory
in cui voglio creare il file di certificazione – scelgo Tomcat/webapps/applets, e uso il seguente comando:
keytool –genkey –alias firmaApplet –keystore Chiave
Adesso dispongo del file Chiave in Tomcat/webapps/applets, e posso utilizzarlo per firmare i miei applet.
Così, in [Link] sostituisco il tag <copy> con il seguente tag <signature>:
<target name="signature" description="Sign the JAR">
<signjar destDir="${finalDest}" jar="${lib}/${appName}.jar"
keystore="${finalDest}/Chiave" storepass="sacone58"
alias="firmaApplet"/>
</target>
Il tag <signature> richiama il tool jarsigner; il JAR file di partenza, cioè build/lib/[Link], resta
invariato, e viene prodotto nella directory di destinazione, cioè Tomcat/webapps/applets, un JAR omonimo
(non ho riassegnato il suo nome) ma diverso, in quanto firmato – il JAR firmato è un po’ più grande.

La pagina [Link] carica il JAR firmato; stavolta non ci sono errori bloccanti, la risorsa
WSDL viene acceduta senza problemi e i web method sono richiamabili.

Uso di un manifest esplicito per l’applet.

L’applet firmato funziona correttamente, però nella Java console appaiono messaggi di tipo warning, che
informano della mancanza di tre attributi nel manifest dell’applet; i tre attibuti sono: Application-Name,
Permissions e Codebase.

pag. 122
Advanced Java rev. 1.0 Novembre 2012

La mancanza dei tre attributi non stupisce: siccome io non ho definito un manifest per l’applet, l’embedded
Ant di Eclipse ne ha generato uno, minimale. Allora modifico il tag <init> affinchè crei la directory
build/META-INF, e aggiungo il tag <manifesto> al file [Link]:
<target name="manifesto" description="crea il manifest">
<manifest file="${build}/META-INF/[Link]">
<attribute name="Application-Name" value="${appName}"/>
<attribute name="Permissions" value="all-permissions"/>
<attribute name="Codebase" value="[Link]
</manifest>
</target>

Modifico il tag <jarGen> in modo che usi il nuovo manifest:

<target name="jarGen" description="JAR generation">
<jar manifest="${build}/META-INF/[Link]" duplicate="preserve"
destfile="${lib}/${appName}.jar">
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<fileset dir="${classes}"/>
</jar>
</target>

Con il nuovo applet risultante dal rebuild, la Java console non dà più i precedenti moniti.

pag. 123
Advanced Java rev. 1.0 Novembre 2012

Costruzione della jax-ws web service PeopleWS.

Come LibreriaWS, anche la web service PeopleWS è stata costruita usando la metodologia bottom–up; però
nel caso di PeopleWS non è stato utilizzato il framework Axis2, ma un framework parzialmente compreso in
Java, cioè jax-ws.

Installazione del framework jax-ws RI.

jax-ws RI (Reference Implementation) è un framework che fornisce strumenti per sviluppare le web service e
i loro client; è il cuore del framework Metro di Glassfish, ma è utilizzabile anche separatamente.

Nonostante sia in parte integrato nei JDK, è necessario scaricare JAX-WS<versione>.zip dal sito (parte del
progetto Glassfish) [Link] l’ultima versione disponibile è 2.2.8.

Scompattando lo zip sotto C:\, viene creata la directory C:\jaxws-ri; di particolare importanza è la
sottodirectory lib, contenente alcuni JAR file non presenti nel JDK.

Affinchè il framework sia utilizzabile, alcuni JAR presenti in jaxws-ri/lib vanno integrati nell’installazione
dell’application server utilizzato, nel mio caso Tomcat. Per semplicità, entro jaxws-ri viene fornito un ant
command file ad hoc, [Link]; prima di poter usare il command file, è però necessario definire la variabile
d’ambiente CATALINA_HOME, che identifica la directory di installazione di Tomcat (coincide con
TOMCAT_HOME), in quanto usata dal command file. Fatto ciò, si apre un command prompt entro la
directory jaxws-ri e si dà il comando ant install.

L’effetto del precedente comando è la copia di 23 JAR file entro Tomcat/shared/lib; se shared/lib non esiste,
viene creata. Inoltre viene scritta la riga [Link]=${[Link]}/shared/lib/*.jar
entro Tomcat/conf/catalina.properties13. È bene a questo punto riavviare Tomcat.

In ultimo, definisco la variabile d’ambiente JAXWS_HOME, che punta alla root della directory d’installazione
di jax-ws, quindi JAXWS_HOME = C:\jaxws-ri. Questa variabile d’ambiente verrà usata nel seguito, in
particolare per accedere librerie e tool di jaxws-ri.

Impostazione del progetto Eclipse PeopleWS.

Creo un Java project, di nome PeopleWS; creo il package app, e all’interno di app creo la classe web
service, PeopleWSClass, subtipo diretto di Object. Questa classe dev’essere contrassegnata con
l’annotazione @WebService, in modo che possa essere riconosciuta dal framework come implementazione
di una web service; i suoi metodi pubblici destinati a diventare web method dovrebbero essere
contrassegnati con l’annotazione @WebMethod:
package app;
import [Link];
import [Link];
import [Link];
import [Link];
@WebService
public class PeopleWSClass
{
@WebMethod
public Vector<Person> PeopleListByRange(int mi,int mf)
{ ... }
@WebMethod
public Vector<Person> PeopleListBySurname(String srn)
{ ... }
}
Oltre al package app, ho creato anche il package dao, contenente la classe Person coi campi Matricola,
Nome, Cognome, CodiceFiscale, come di consueto.

13
La riga in questione non è appannaggio di jaxws-ri; essa dev’essere presente nel file [Link],
ogni volta che si utilizza la directory shared/lib entro l’installazione di Tomcat, come nel mio caso, che già vi
avevo posto [Link]; in questi casi, il command file di jaxws-ri duplica inutilmente la riga.

pag. 124
Advanced Java rev. 1.0 Novembre 2012

Il framework jax-ws utilizza ampiamente le annotazioni; in particolare la classe che implementa una web
service dev’essere obbligatoriamente contraddistinta con l’annotazione @WebService; l’annotazione
ammette diversi parametri, che se, come nel caso presente, non vengono settati, assumono valori default
(l’argomento verrà approfondito nel seguito).

Anche l’annotazione WebMethod ammette parametrizzazione; il suo uso è fortemente consigliato, ma non è
obbligatorio: anche omettendo l’annotazione @WebMethod, ogni metodo della classe web service che sia
pubblico diventa un web method, cioè compare nel WSDL ed è richiamabile dai client.

Proprio l’annotazione @WebMethod può essere usata per evitare che un metodo pubblico della classe web
service divenga un web method richiamabile dai client. Sia M un metodo della classe web service: posso
trovare utile dichiararlo pubblico per esigenze di programmazione interne all’applicazione web service, ma
non voglio che divenga un web method accessibile da parte dei client. Come fare ?

La soluzione è l’utilizzo dell’annotazione @WebMethod opportunamente parametrizzata:

@WebMethod(exclude=true)
public tipoRet M(pars)

il default dell’attributo exclude è false.

Anche il tipo di ritorno e i parametri di passaggio di un web method possono essere annotati, rispettivamente
con @WebResult e @WebParam; si vedrà un esempio d’uso di @WebParam nel seguito.

Le annotazioni @WebService, @WebMethod, @WebParam, @WebResult sono presenti in [Link],

che si trova in %JAXWS_HOME%/lib e anche in Tomcat/shared/lib; tuttavia le trovo anche in [Link], a riprova
dell’integrazione parziale di jaxws-ri entro il framework Java.

La classe web service non ha bisogno di alcun main, infatti ad istanziare la classe ci pensa l’application
server (Tomcat). La scrittura della classe web service viene completata scrivendo il codice dei vari metodi.

Build della jax-ws web service LibreriaXWS.

Ciò che verrà generato dal build dell’applicazione è un WAR file. Le fasi più caratteristiche sono l’annotation
processing e la creazione del WAR file, ciascuna corrispondente a un apposito target nel build file; sono
presenti anche i target iniziali <clean> e <init>, e il target finale <copy>.

Il target <init> crea la solita directory build, con le sottodirectory classes e war, quest’ultima destinata a
ospitare il WAR file. Il target <clean> elimina la directory build.

Fase di annotation processing.

Dopo aver eseguito il target <init>, viene la fase detta annotation processing, realizzata dal target
<compileService>. Le operazioni sono compiute dalla classe AnnotationProcessingTask, del package
[Link], facente parte di [Link] situato in JAXWS_HOME/lib:
<path id="[Link]">
<fileset dir="${env.JAXWS_HOME}/lib">
<include name="*.jar"/>
</fileset>
</path>
<taskdef name="annotationProcessing"
classname="[Link]">
<classpath refid="[Link]"/>
</taskdef>
<target name="compileService">
<annotationProcessing
includeantruntime="false"
fork="true"
destdir="${classes}"
srcdir="${srcdir}"
sourceDestDir="${srcdir}"
procOnly="false">
<classpath>
<path refid="[Link]"/>
<pathelement location="${srcdir}"/>
</classpath>

pag. 125
Advanced Java rev. 1.0 Novembre 2012

</annotationProcessing>
</target>

il processing delle annotazioni comprende anche la compilazione di tutti i sorgenti: se l’esecuzione del target
<compileService> avviene correttamente, entro build/classes trovo i file .class di tutti i sorgenti, qui trovo
build/classes/app/[Link] e build/classes/dao/[Link].

Inoltre compare anche la sottodirectory build/classes/app/jaxws che contiene per ogni web method una
coppia di classi, una per la richiesta e una per la risposta: nel caso corrente, la sottodirectory
build/classes/srv/jaxws contiene 4 classi: [Link], [Link],
[Link] e [Link].

Osservazione importante: l’esecuzione del target <compileService> genera nel progetto il package
[Link], ossia, a livello di file system, la sottodirectory jaxws entro la directory app; poi il target genera le
classi compilate entro [Link]. Alla fine, resta la directory app/jaxws entro src, e questo costituisce un
problema di classi duplicate per successive esecuzioni del target <compileService>.

Bisogna quindi eliminare app/jaxws una volta completata l’annotation processing. Allo scopo, aggiungo una
apposita riga in coda al target <compileService>:
<target name="compileService">
<annotationProcessing
...
</annotationProcessing>
<delete dir="${srcdir}/app/jaxws" includeEmptyDirs="true"/>
</target>

Un problema rilevato nell’uso della classe AnnotationProcessingTask.

Quando il nome della directory referenziata dal parametro sourceDestDir contiene dei blank, si verifica un
errore e i file necessari non vengono generati. Infatti non ci sono problemi su Windows 7, ove:
basedir = “C:/Users/Administrator/workspace/PeopleWS”.

L’errore si verifica su Windows XP, ove:

basedir = “C:/Documents and Settings/RavagliV/workspace/PeopleWS”.

Ecco un workaround semplice:

<target name="compileService">
<mkdir dir="C:/temp/PeopleWS"/>
<annotationProcessing
includeantruntime="false"
fork="true"
destdir="${classes}"
srcdir="${srcdir}"
sourceDestDir="C:/temp/PeopleWS"
procOnly="false">
<classpath>
<path refid="[Link]"/>
<pathelement location="${srcdir}"/>
</classpath>
</annotationProcessing>
<delete dir="C:/temp/PeopleWS" includeEmptyDirs="true"/>
</target>

I file .class vengono correttamente generati entro [Link].

I file descrittivi [Link] e [Link].

Il target <warGen> crea il WAR file, tuttavia prima della sua esecuzione è necessario un passo preliminare,
cioè l’aggiunta al progetto di due file assolutamente necessari al funzionamento della web service: [Link] e
[Link]; i due file dovranno essere inclusi nel file WAR. La loro natura è descrittiva dell’applicazione
web service, perciò li chiamo file descrittivi nel seguito.

pag. 126
Advanced Java rev. 1.0 Novembre 2012

Convenzionalmente, si aggiunge il folder etc al progetto, allo stesso livello di src; i due file descrittivi vengono
scritti entro il folder etc. La loro struttura è convenzionale, uguale per ogni web service, soltanto i valori di
alcuni parametri sono specifici della singola web service.

Dettagli su [Link].
Ho usato come prototipo un esempio fornito dalla documentazione di jaxws-ri, adattandolo al caso di
PeopleWS (ho omesso nel seguito le parti non essenziali):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"[Link]
<web-app>
<display-name>PeopleWS (jax-ws web service)</display-name>
<listener>
<listener-class>
[Link]
</listener-class>
</listener>
<servlet>
<servlet-name>people</servlet-name>
<servlet-class>[Link]</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>people</servlet-name>
<url-pattern>/PeopleWS</url-pattern>
</servlet-mapping>
</web-app>

Questo descrittore evidenzia bene il fatto che le JAX-WS web service basano il proprio funzionamento sui
servlet. Per interpretare le caratteristiche generali della struttura del file [Link] di un servlet, rimando ad un
precedente paragrafo.

Il servlet sottostante alla web service, che si preoccupa della ricezione delle richieste dei client, è istanza
della classe WSServlet, una classe appartenente al framework jaxws-ri (libreria [Link]). Anche la classe
WSServletContextListener, da cui viene istanziato il listener del servlet, appartiene alla stessa libreria.

Si evince dalla DTD che l’architettura usata in JAX-WS per i servlet è quella contenuta nelle Servlet
Specification 2.3, tale scelta richiede la presenza di [Link] (a differenza della 3.0, che permette di evitare il
file [Link] mediante l’uso di annotazioni). Di conseguenza, il file [Link] è ineliminabile, in quanto riguarda
non tanto la web service ma il servlet sottostante, che è dato dal framework jaxws-ri.

In ultimo, si noti che, avendo definito il tag <load-on-startup>, con il valore 1, il servlet viene istanziato (da
Tomcat) alla partenza, senza aspettare le richieste da parte dei client.

Dettagli su [Link].
Ho usato come prototipo un esempio fornito dalla documentazione di jaxws-ri, adattandolo al caso di
PeopleWS:
<?xml version="1.0" encoding="UTF-8"?>
<endpoints xmlns='[Link] version='2.0'>
<endpoint name='peopleEP' implementation='[Link]'
url-pattern='/PeopleWS'/>
</endpoints>

Fase di creazione del file WAR.

Il target <warGen> crea il WAR file, a partire dalle directory build e etc:
<target name="warGen">
<war warfile="${wardir}/${appname}.war" webxml="etc/[Link]">
<webinf dir="${basedir}/etc" includes="[Link]"/>
<zipfileset dir="${basedir}/etc" includes="*.wsdl,*.xsd"
prefix="WEB-INF/wsdl"/>

pag. 127
Advanced Java rev. 1.0 Novembre 2012

<classes dir="${classes}"/>
</war>
</target>

Il nome del WAR file è deciso dall’attributo warfile, che stabilisce sia la directory in cui viene crato il file (cioè
build/war) sia il suo nome, che risulta essere PeopleWS, essendo appname = PeopleWS.

In generale, un WAR file è un file archivio che deve soddisfare alcuni requisiti, sia di struttura che di
contenuto: deve contenere la directory WEB-INF; la directory WEB-INF a sua volta deve contenere il file
descrittivo [Link], inoltre le classi (file .class) presenti devono stare nella sottodirectory classes, mentre i
JAR file eventualmente presenti devono stare nella sottodirectory lib.

Oltre alla directory WEB-INF, è di norma presente la directory META-INF, allo stesso livello di WEB-INF,
contenente il file manifest [Link] (senza nulla di particolare).

Quando un WAR file implementa una JAX-WS web service, quindi di un tipo particolare di WAR, allora, oltre
alle classi contenute in build/classes e a [Link], c’è bisogno di un altro file descrittivo: [Link].

Eventuali file WSDL e XSD dovrebbero essere posti nella directory etc; se presenti, il subtarget <zipfileset>
nella quarta riga del target <warGen> li copia entro il folder del WAR file; qui non sono però presenti, per cui
il target <zipfileset> entro <warGen> non compie alcuna azione.

Aggiunta di librerie.
La web service stabilisce una connessione al database Oracle DBPeople, quindi necessita della libreria
(driver Oracle) [Link]; volendo aggiungere la libreria driver al WAR file, è necessario aggiungere al target
<warGen> la riga seguente:
<webinf dir="C:\oraclexe\Drivers" includes="[Link]" prefix="WEB-INF/lib"/>

Rieseguendo il target, entro il WAR file compare la sottodirectory WEB-INF/lib contenente il file [Link]
(non scompattato nelle sue singole classi). Questo procedimento va seguito in generale ogni volta che si
intenda includere un JAR file in un WAR file; se il JAR viene incluso, ma non entro WEB-INF/lib, allora il JAR
file non verrà reperito a runtime: è mandatorio includere i JAR entro WEB-INF/lib.

Tuttavia, come già nel caso della axis2 web service LibreriaWS, ho seguito un’altra strada: supponendo che
il database server e il web application server (Oracle e Tomcat) stiano sulla stessa macchina, pongo
[Link] entro la directory shared/lib di Tomcat, così non ho bisogno di porre alcun database driver entro i
singoli WAR file. Perciò l’elemento <webinf> non serve. Tuttavia è importante ricordare che, usando
<webinf>, è possibile includere una libreria qualsiasi.

Ecco come appare il progetto alla fine dell’esecuzione del target <warGen>:

pag. 128
Advanced Java rev. 1.0 Novembre 2012

Il WAR file, [Link], viene generato

nella directory build/war.

Aggiungo un ultimo target a [Link]: è il

target <copy>, che copia il WAR file nella
directory C:/WAR files, ridenominandolo come
[Link].

Installazione della JAX-WS web service PeopleWS.

Al termine dell’azione del target <copy>, è disponibile l’archivio [Link] nella directory WAR
Files; viene caricato come un qualsiasi WAR file, ad esempio usando la funzionalità di WAR upload propria
di Tomcat Manager (standard deploy di Tomcat). Così facendo, compare il sito JAX-PeopleWS in
Tomcat/webapps: la web service è pronta.

La web service è accessibile all’indirizzo [Link] tramite browser;

facendolo, vengono mostrate alcune informazioni sulla web service:
a) il link al file WSDL: [Link]
b) il nome della classe d’implementazione: [Link]
c) il nome del servizio: {[Link] PeopleWSClassService
d) il nome della porta: {[Link] PeopleWSClassPort.

Realizzazione di un applet client di PeopleWS.

La scrittura di un client della web service PeopleWS è un po’ più semplice e intuitiva di quanto lo sia quella di
un client di una axis2 web service; inoltre il client per funzionare non ha bisogno di librerie apposite, è
sufficiente il runtime di Java – a patto che non utilizzi funzionalità avanzate e quindi non coperte
dall’implementazione nativa in Java di JAX-WS.

Lo sviluppo dell’applet PeopleWSApplet, client di PeopleWS, somiglia allo sviluppo dell’applet

LibreriaWSApplet sotto molti aspetti, ma ci sono alcune importanti differenze, in particolare non servono
librerie esterne da inglobare.

Utilizzo un Java project con il package app, nel quale creo la classe PeopleWSAppletClass subtipo di
JApplet, e il package models nel quale è presente la classe ReadonlyTableModel, identica a quella di
BookletApplet, usata per gestire la JTable dell’applet. Segue il design dell’applet, sviluppato con
WindowBuilder Editor:

pag. 129
Advanced Java rev. 1.0 Novembre 2012

Le prime fasi del build sono i soliti target <clean> e <init>; c’è la generazione del manifest tramite il target
<manifesto>; seguono poi la fase di generazione dello stub (target <wsimport>), la fase di compilazione
(target <compile>), infine la fase di generazione del JAR file (target <jarGen>) e la firma e copia in
Tomcat/webapps/applets (target <signature>).

Il target <init> genera build, build/META-INF e build/classes, ed è il primo che dev’essere eseguito; lo segue
il target <manifesto>, che scrive un manifest in build/META-INF, analogo a quello di LibreriaWSApplet.

Fase di generazione dello stub.

La fase di generazione dello stub è implementata dal target <wsimport>:

<property name="wsdlSource"
value="[Link]
<property name="srcdir" value="${basedir}/src"/>
<property name="stubPkg" value="stubPeoWS"/>
<path id="[Link]">
<pathelement location="${env.JAVA_HOME}/lib/[Link]"/>
</path>
<target name="wsimport" description="Stub generation">
<java classname="[Link]" fork="true">
<classpath refid="[Link]"/>
<arg value="-keep"/>
<arg value="-extension"/>
<arg value="-d"/>
<arg value="${srcdir}"/>
<arg value="-p"/>
<arg value="${stubPkg}"/>
<arg value="${wsdlSource}"/>
</java>
</target>

La classe WsImport, appartenente al package [Link], si trova in [Link], libreria facente

parte del JDK ma non del JRE, di qui la necessità del target <path id="[Link]">.

La parametrizzazione dice alla classe di utilizzare il file WSDL di PeopleWS, inoltre stabilisce che le classi
generate apparterranno al package stubPeoXWS, e che il package starà nella directory src.

pag. 130
Advanced Java rev. 1.0 Novembre 2012

La classe WsImport svolge un ruolo analogo a

quello svolto dalla classe WSDL2Java nel
framework axis2; i risultati sono molto simili, però
sono “atomizzati” ossia distinti in più classi.

Il package stubPeoWS contiene una coppia di classi

per ciascun web method, come PeopleListByRange
e PeopleListByRangeResponse, più altre classi,
tuttavia le classi di diretto interesse nella scrittura del
client sono l’interfaccia PeopleWSClass e la classe
PeopleWSClassService, subtipo di Service.

Service, contenuta in [Link], è la classe che

rappresenta in generale una web service dal punto
di vista client; il subtipo PeopleWSClassService è
“mappato” sulla specifica web service PeopleWS
mediante una annotazione generata da WsImport:
l’annotazione è WebServiceClient (appartenente a
[Link]); quindi PeopleWSClassService rappresenta la
specifica web service PeopleWS dal punto di vista
dei suoi client.

Ecco come si presenta la classe PeopleWSClassService, generata dall’esecuzione del target <wsimport>:
package stubLibXWS;
@WebServiceClient(name="PeopleWSClassService",targetNamespace="http://
app/",
wsdlLocation="[Link]
public class PeopleWSClassService extends Service
{
...
}

È interessante confrontare i valori dei parametri dell’annotazione @WebServiceClient con le informazioni

fornite dal browser accedendo il sito della web service.

Uso delle classi generate da <wsimport>.

Il metodo init dell’applet, terminata l’inizializzazione grafica, esegue il codice che crea lo stub, pws:
URL wsdl = new URL("[Link]
PeopleWSClassService pwsSrv = new PeopleWSClassService(wsdl);
pws = [Link]();

Le chiamate ai metodi della web service PeopleWS vengono effettuate usando l’oggetto pws, e sono più
semplici e immediate delle chiamate ai metodi di una axis2 web service:
List<Person> lista = [Link](mi, mf);
List<Person> lista = [Link](srn);

Ho usato List<Person> come tipo di ritorno dei due metodi, perché si tratta del tipo di ritorno presente
nell’interfaccia [Link]:
public interface PeopleWSClass
{
@WebMethod(operationName = "PeopleListByRange")
@WebResult(targetNamespace = "")

pag. 131
Advanced Java rev. 1.0 Novembre 2012

@RequestWrapper(localName = "PeopleListByRange", targetNamespace =

"[Link]
className = "[Link]")
@ResponseWrapper(localName = "PeopleListByRangeResponse", targetNamespace =
"[Link] className =
"[Link]")
@Action(input = "[Link] output
=
"[Link]
public List<Person> peopleListByRange(
@WebParam(name = "arg0", targetNamespace = "")
int arg0,
@WebParam(name = "arg1", targetNamespace = "")
int arg1);
@WebMethod(operationName = "PeopleListBySurname")
@WebResult(targetNamespace = "")
@RequestWrapper(localName = "PeopleListBySurname", targetNamespace =
"[Link]
className = "[Link]")
@ResponseWrapper(localName = "PeopleListBySurnameResponse", targetNamespace
=
"[Link] className =
"[Link]")
@Action(input = "[Link]
output =
"[Link]
public List<Person> peopleListBySurname(
@WebParam(name = "arg0", targetNamespace = "")
String arg0);
}

il resto del codice client serve alla visualizzazione dei dati ricevuti.

Generazione ed esecuzione.
Il target <compile> non presenta particolarità, tutte le classi, sia PeopleWSAppletClass sia quelle generate
da <wsimport> entro il package stubPeoWS, vengono compilate e i .class generati entro build/classes.

I target <jarGen> e <signature> sono del tutto analoghi a quelli già visti nel caso di LibreriaWSApplet.

Una volta che l’applet è disponibile in Tomcat/webapps/applets, per provarlo aggiungo al sito LightSite la
pagina [Link], che carica l’applet firmato:

pag. 132
Advanced Java rev. 1.0 Novembre 2012

L’applet funziona perfettamente.

Analisi dei messaggi SOAP con SocketClient.

Tramite l’applicazione SocketClient, posso chiamare un metodo della web service PeopleWS; ad esempio il
metodo PeopleListBySurname: public Vector<Person> PeopleListBySurname(String srn), con
srn = “Z”, spedendo il seguente messaggio alla porta 8081 di user-pc:
POST /JAX-PeopleWS/PeopleWS HTTP/1.1
Content-Type: text/xml; charset=utf-8
Host: user-pc
Content-Length: 177

<s:Envelope xmlns:s='[Link]
<s:Body>
<v:PeopleListBySurname xmlns:v='[Link]
<arg0>Z</arg0>
</v:PeopleListBySurname>
</s:Body>
</s:Envelope>

Si tratta del messaggio minimale funzionante, eccettuato l’attributo Content-Type che non è strettamente
necessario (potrebbe essere omesso, ma è bene specificarlo).

Il messaggio SOAP è analogo a quello della richiesta alla axis2 web service LibreriaWS, ma ci sono rigidità
maggiori, in particolare il tag del parametro dev’essere <arg0> e null’altro, pena errori, inoltre il tag col nome
del metodo deve appartenere al namespace [Link] e non averlo come default namespace.

Ecco la risposta della web service:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Sat, 11 Jan 2014 23:20:54 GMT

6e
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="[Link]
<S:Body>
180
<ns2:PeopleListBySurnameResponse xmlns:ns2="[Link]
<return>
<Matricola>2000</Matricola>
<Nome>Cristina</Nome>
<Cognome>Zanni</Cognome>
<CodiceFiscale>Gnocconissima</CodiceFiscale>
</return>
<return>
<Matricola>2100</Matricola>
<Nome>Enrico</Nome>
<Cognome>Zunino</Cognome>
<CodiceFiscale>Neonato</CodiceFiscale>
</return>
</ns2:PeopleListBySurnameResponse>
</S:Body>
</S:Envelope>
0

Si noti che 6e è 110, e i byte che vanno da <? (subito dopo il 6e) fino a <S:Body> compreso sono proprio
110. Poi c’è 180, che equivale a 384, e questo è proprio il numero di byte che vanno da <ns2 (subito dopo il
180) fino alla fine, cioè fino a </S:Envelope> incluso. Si tratta del chunk dei messaggi.

pag. 133
Advanced Java rev. 1.0 Novembre 2012

Utilizzo di funzionalità avanzate del framework JAX-WS.

Come si è visto, un client di PeopleWS per funzionare non ha bisogno di librerie apposite, è sufficiente il
runtime di Java; come si è già detto, questo è vero a patto che il client non utilizzi funzionalità avanzate e
quindi non coperte dall’implementazione nativa in Java di JAX-WS.

L’applet PeopleWSApplet è un client semplice e infatti non utilizza librerie proprie di jaxws-ri; adesso invece
passo ad un client avanzato, cioè un client che utilizza funzionalità avanzate: PeopleWSClient.

In una sua prima versione, PeopleWSClient non utilizza funzionalità avanzate: è una semplice applicazione
console, che permette all’operatore di chiamare i metodi della web service PeopleWS, e mostra a video i
risultati delle chiamate. I tag del build file sono i consueti <clean>, <init>, <wsimport> come in
PeopleWSApplet, infine i tre tag <compile>, <jarGen> e <copy> tipici delle applicazioni in ExeJar.

Nella seconda versione, l’applicazione PeopleWSClient svolge le stesse funzioni, ma in più effettua il log dei
messaggi scambiati con la web service PeopleWS.

Generalità su handler e message context nel framework jax-ws.

Nel framework JAX-WS, come nel mondo web in generale, le applicazioni comunicano tramite messaggi;
questi messaggi di solito seguono il protocollo HTTP. A sua volta, il protocollo HTTP può veicolare, come
body dei messaggi HTTP, messaggi scritti in qualche protocollo applicativo: nel caso di JAX-WS, è molto
diffuso l’uso del protocollo SOAP. Le web service qui considerate e i loro client comunicano mediante
messaggi SOAP, veicolati da messaggi HTTP dei quali i messaggi SOAP costituiscono il body.

Sempre in generale, i messaggi (sia HTTP, sia SOAP) sono manipolati nel loro ciclo di vita da handler; la
descrizione di un messaggio, il suo stato, composto in generale da chiavi e valori, è detta contesto del
messaggio ossia message context. Un handler quindi agisce sui message context, facendoli evolvere: in
questo senso, handler e message context sono concetti connessi.

Ogni JAX-WS handler è rappresentabile programmaticamente mediante l’interfaccia generica

[Link], contenuta in [Link]; sempre in [Link], è presente l’interfaccia MessageContext,
anch’essa appartenente al package [Link].

L’interfaccia MessageContext discende dall’interfaccia Map<String,Object>, ossia è visibile come una mappa
di coppie chiave/valore. L’interfaccia MessageContext rappresenta il message context di un messaggio
HTTP orientato all’utilizzo entro il framework JAX-WS, come provano i suoi campi
(HTTP_REQUEST_METHOD, HTTP_RESPONSE_CODE, WSDL_OPERATION, WSDL_PORT etc).

L’utilizzo delle due interfacce, Handler e MessageContext, è sinergico: Handler è interfaccia generica e la
sua espressione formale è Handler<I extends MessageContext>.

All’interno di [Link], nel package [Link], sono presenti due interfacce, derivanti dalle
precedenti e più specializzate: si tratta di SOAPHandler, subtipo di Handler, e SOAPMessageContext,
subtipo di MessageContext. L’interfaccia SOAPHandler è anch’essa generica, e la sua espressione formale
è SOAPHandler<T extends SOAPMessageContext>.

Per implementare un proprio handler, in generale lo sviluppatore crea una classe che implementa
l’interfaccia SOAPHandler<SOAPMessageContext>: è la strada che ho seguito per realizzare il client,
PeopleWSClient, capace di effettuare il log dei messaggi, ho creato allo scopo la mia classe handler,
LoggingHandler, implementazione dell’interfaccia SOAPHandler<SOAPMessageContext>.

Come si vedrà, l’implementazione dell’handler avverrà in un primo tempo senza bisogno di aggiungere
librerie apposite; solo quando richiederò un certo tipo di funzionalità, il progetto client sarà costretto a
ricorrere alle librerie del framework jax-ws ri.

La classe LoggingHandler, implementazione dell’interfaccia SOAPHandler.

Ho creato nel progetto PeopleWSClient il package log, e in esso ho creato la classe LoggingHandler,
implementazione dell’interfaccia SOAPHandler<SOAPMessageContext>: l’interfaccia Handler definisce i
metodi handleMessage, handleFault e close; la sua estensione SOAPHandler definisce il metodo
getHeaders: quindi LoggingHandler deve implementare tutti e quattro questi metodi.

pag. 134
Advanced Java rev. 1.0 Novembre 2012

Questa è la classe, così come è stata generata dall’IDE di Eclipse (appartenente al package log; ho omesso
le import clause, per semplicità e brevità):
public class LoggingHandler implements SOAPHandler<SOAPMessageContext>
{
@Override
public void close(MessageContext context)
{}
@Override
public boolean handleFault(SOAPMessageContext context)
{ return false; }
@Override
public boolean handleMessage(SOAPMessageContext context)
{ return false; }
@Override
public Set<QName> getHeaders()
{ return null; }
}

I metodi getHeaders e close non mi interessano, li lascio così come sono. Riscrivo i metodi handleMessage
e handleFault: il codice è lo stesso per entrambi, cioè la chiamata del metodo logToSystemOut, privato,
che effettua la stampa a video delle informazioni inerenti al messaggio trattato – rappresentato da smc;
inoltre, faccio restituire true a entrambi i metodi.

Ecco il codice del metodo logToSystemOut, ove ho tralasciato la gestione degli errori:
private void logToSystemOut(SOAPMessageContext smc)
{
boolean outboundProperty = (boolean)[Link](MessageContext.MESSAGE_OUTBOUND_PROPERTY);
if (outboundProperty)
[Link]("Outbound message at "+[Link]());
else [Link]("Inbound message at "+[Link]());
String httpReqMethod = (String)[Link](MessageContext.HTTP_REQUEST_METHOD);
if (httpReqMethod == null)
[Link]("\nMessageContext.HTTP_REQUEST_METHOD is null\n");
else [Link]("\nMessageContext.HTTP_REQUEST_METHOD="+httpReqMethod);
Integer retc = (Integer)[Link](MessageContext.HTTP_RESPONSE_CODE);
if (retc == null)
[Link]("MessageContext.HTTP_RESPONSE_CODE is null");
else [Link]("MessageContext.HTTP_RESPONSE_CODE="+[Link]());
SOAPMessage msg = [Link]();
[Link]([Link]);
}

File di configurazione contenente la definizione della catena dei handler.

La classe dev’essere per così dire resa nota al framework jax-ws. Allo scopo, aggiungo al progetto un file di
configurazione, [Link]; per convenzione, lo pongo in un folder chiamato etc (allo stesso livello
della directory src):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bindings xmlns:xsd="[Link]
xmlns:wsdl="[Link]
wsdlLocation="[Link]
xmlns="[Link]
<bindings node="wsdl:definitions" xmlns:jws="[Link]
<jws:handler-chains>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>[Link]</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

pag. 135
Advanced Java rev. 1.0 Novembre 2012

</bindings>
</bindings>

Il file [Link] (il nome è arbitrario) è molto importante, perché al suo interno viene definita la
cosiddetta handler-chains (catena dei handler). Si noti che al suo interno è referenziata la classe
LoggingHandler, cioè la classe che implementa l’handler applicativo.

Il nuovo target wsimport e gli effetti della sua esecuzione.

Serve ancora un collegamento tra il codice Java e il file di configurazione: come si è visto nell’analisi del
client LibreriaXWSClient, l’azione del target <wsimport> genera 9 file .java; qui modifico il target <wsimport>
affinchè operi anche sul file [Link], tramite l’opzione –b:
<target name="wsimport" description="Stub generation">
<java classname="[Link]" fork="true">
<classpath refid="[Link]"/>
<arg value="-keep"/>
<arg value="-extension"/>
<arg value="-d"/>
<arg value="${srcdir}"/>
<arg value="-p"/>
<arg value="${stubPkg}"/>
<arg value="-b"/>
<arg value="${basedir}/etc/[Link]" />
<arg value="${wsdlSource}"/>
</java>
</target>

Eseguo il target <wsimport>: viene creato il package stubPeoXWS, contenente 9 file .java aventi gli stessi
nomi di quelli del progetto PeopleWSApplet, e due file XML, PeopleWSClass_handler.xml e
PeopleWSClassService_handler.xml. I due file XML sono identici, e sono in pratica uguali al file che
risulterebbe sfrondando [Link] dai riferimenti al wsdl e lasciandone intatta la definizione della
handler chain.

Dei 9 file .java generati, due soli sono diversi dagli omonimi del progetto PeopleWSApplet: si tratta di
[Link] e [Link] (i due file più importanti tra i 9 generati).

Il file [Link] del progetto PeopleWSClient differisce dall’omonimo del progetto

PeopleWSApplet, in quanto il primo usa un’annotazione assente nel secondo:
@HandlerChain(file = "PeopleWSClass_handler.xml"), applicata alla classe.

Analogamente, l’annotazione @HandlerChain(file = "PeopleWSClassService_handler.xml")

annota la classe PeopleWSClassService solamente nel progetto PeopleWSClient.

Siccome le classi PeopleWSClass e PeopleWSClassService fanno riferimento ai rispettivi file XML descrittivi
del loro handler, mi aspetto che i due file XML debbano essere presenti nel file JAR. Supponendo di
ignorarlo, posso compilare e generare il JAR (target <compile> e <jarGen> rispettivamente), quindi copiare
[Link] in ExeJar, e infine lanciare il client: si verifica un errore, in quanto la classe
PeopleWSClassService non riesce a trovare il file PeopleWSClassService_handler.xml. Me l’aspettavo…

È necessario copiare i due file XML, generati da <wsimport>, nella directory build/classes, per cui aggiungo
un comando di copia in coda al target:
<target name="wsimport" description="Stub generation">
<java classname="[Link]" fork="true">
... come sopra ...
</java>
<copy toDir="${classes}">
<fileset dir="${srcdir}/${stubPkg}">
<include name="*.xml"/>
</fileset>
</copy>
</target>

pag. 136
Advanced Java rev. 1.0 Novembre 2012

Eseguo il target <wsimport>, poi <compile>, <jarGen> e <copy>; apro un command prompt in ExeJar e do il
comando java –jar [Link]: il client funziona correttamente.

Dump dei messaggi HTTP SOAP.

Quanto segue è l’output di una parte del funzionamento di PeopleWSClient: il client (remoto) ha invocato il
metodo PeopleListByRange (con range di matricole tra 2 e 8) e ha ottenuto la risposta.

Il primo messaggio è uscente: HTTP_REQUEST_METHOD è null, perché il campo viene analizzato troppo
precocemente (assumerà il valore POST, ma non l’ha ancora assunto nel momento in cui l’analizzo); anche
HTTP_RESPONSE_CODE è null, il che è corretto essendo un messaggio di richiesta e non di risposta.

Il SOAP message che costituisce il body è conforme a ciò che mi attendevo, ed a ciò che ho scritto quando
ho usato SocketClient.

Poi giunge il messaggio di risposta da parte della web service: qui non ha senso
HTTP_REQUEST_METHOD, trattandosi di un messaggio di risposta, mentre HTTP_RESPONSE_CODE è
valorizzato e vale 200 = OK. Anche qui, il SOAP message che costituisce il body è conforme alle attese.

Si può migliorare l’informazione fornita, cominciando a eliminare le informazioni certamente inutili; so che il
client invia richieste e riceve risposte, e quindi è inutile stampare HTTP_RESPONSE_CODE in un
messaggio in uscita, così come è inutile stampare HTTP_REQUEST_METHOD, che è sempre null per le
ragioni sopra addotte.

Finora non ho utilizzato feature proprie di jaxws-ri, infatti il computer sul quale viene eseguita l’applicazione
PeopleWSClient non ha il framework jaxws-ri installato.

pag. 137
Advanced Java rev. 1.0 Novembre 2012

Client avanzato che usa feature proprie del framework jaxws-ri.

È possibile fornire più informazioni, in particolare i header HTTP del messaggio di risposta ricevuto dal client:
infatti i valori dei campi per questo messaggio sono disponibili, come dimostra il fatto che il campo
HTTP_RESPONSE_CODE sia correttamente valorizzato: mi aspetto che ci siano coppie parametro/valore
valorizzate e di interesse. Come posso leggere questi header HTTP ?

Viene suggerito l’uso dell’istruzione seguente:

Headers hs = (Headers) [Link](MessageContext.HTTP_RESPONSE_HEADERS);

però la classe Headers non viene risolta. È qui che si rende necessario il salto di qualità.

La classe Headers, appartenente al package [Link], si trova in [Link]. Allora

configuro il build path nella IDE di Eclipse, referenziando come external library la libreria [Link] situata
nella directory <JAXWS_HOME>/lib. Così facendo, molte altre librerie ivi presenti vengono automaticamente
incluse (si tratta di librerie comprese nel classpath di [Link]).

Adesso il client LibreriaXWSAdvClient è diventato un client avanzato, che ricorre alle feature proprie del
framework jaxws-ri.

Ecco il codice finale del metodo logToSystemOut:

private void logToSystemOut(SOAPMessageContext smc)
{ boolean outboundProperty =
boolean)[Link](MessageContext.MESSAGE_OUTBOUND_PROPERTY);
if (outboundProperty)
[Link]("Outbound message at "+[Link]());
else
{ [Link]("Inbound message at "+[Link]());
Integer retc = (Integer) [Link](MessageContext.HTTP_RESPONSE_CODE);
if (retc == null) [Link]("MessageContext.HTTP_RESPONSE_CODE is
null");
else
{ [Link]("MessageContext.HTTP_RESPONSE_CODE="+[Link]());
Headers hs = (Headers) [Link](MessageContext.HTTP_RESPONSE_HEADERS);
if (hs == null) [Link]("MessageContext.HTTP_RESPONSE_HEADERS is
null");
else
{ Collection<Entry<String,List<String>>> collHea = [Link]();
Iterator<Entry<String, List<String>>> ite = [Link]();
Entry<String, List<String>> en = null;
while ([Link]())
{ en = [Link]();
[Link]([Link]()+": ");
List<String> ls = [Link]();
for (int i=0;i<[Link]();i++) [Link]([Link](i) + " ");
}
}
}
}
SOAPMessage msg = [Link]();
[Link]([Link]);
}

Modifiche alla compilazione e generazione del JAR.

Apporto alcune modifiche a [Link]; introduco un elemento <property> e un elemento <path>:
<property name="[Link]" value="${env.JAXWS_HOME}/lib"/>
<path id="[Link]">
<pathelement location="${[Link]}/[Link]"/>
</path>

Quindi aggiungo l’elemento <classpath refid="[Link]"/> al target <compile>: la

compilazione avviene senza errori.

pag. 138
Advanced Java rev. 1.0 Novembre 2012

Anche il target <jarGen> va modificato, aggiungendo le necessarie librerie:

<target name="jarGen" description="JAR generation">
<jar manifest="[Link]" destfile="${build}/${appName}.jar">
<zipfileset src="${[Link]}"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<zipfileset src="${[Link]}/[Link]"/>
<fileset dir="${classes}"/>
</jar>
</target>

Rigenero [Link] e lo copio in ExeJar.

Esecuzione e analisi dei messaggi.

Eseguo la nuova versione di [Link], su un PC remoto (rispetto a user-pc, sul quale risiede la
web service PeopleWS), sul quale non è stato installato il framework jaxws-ri:

Stavolta sono visibili i campi dell’header HTTP nel messaggio di risposta inviato dalla web service al client.

Utilizzo di un handler applicativo da parte della web service.

Voglio che anche la web service PeopleWS sia in grado di effettuare il logging dei messaggi HTTP SOAP;
sarà così possibile vedere i messaggi di richiesta ricevuti dai client. In pratica, modificherò il progetto
PeopleWS in modo che la web service usi una versione un po’ modificata della classe LoggingHandler.

pag. 139
Advanced Java rev. 1.0 Novembre 2012

La classe LoggingHandler adattata al lato server.

Aggiungo al progetto PeopleWS il package log, contenente la classe LoggingHandler, analoga a quella
presente nel package log del progetto PeopleWSClient.

Anche qui, nei messaggi inviati i campi del header HTTP non sono ancora valorizzati, all’esecuzione
dell’handler – infatti HTTP_RESPONSE_CODE = 0, poi diverrà 200; perciò non ha senso stamparli. Stampo
invece i campi dell’header dei messaggi ricevuti, sono le richieste dei client: perciò entro il metodo
logToSystemOut stampo il valore di HTTP_REQUEST_METHOD, e stampo i campi di
HTTP_REQUEST_HEADERS.

File di configurazione contenente la definizione della catena dei handler.

Entro la directory etc, che esiste già, aggiungo il file [Link], che definisce la handler chain della web
service PeopleWS:
<handler-chains xmlns="[Link]
<handler-chain>
<handler>
<handler-class>[Link]</handler-class>
</handler>
</handler-chain>
</handler-chains>

Modifiche al codice della classe PeopleWSClass.

La classePeopleWSClass, che implementa la web service, deve adesso referenziare [Link]; è
sufficiente l’aggiunta di un’apposita annotazione: @HandlerChain(file="[Link]").

Modifiche al target <compileService> e gli effetti della sua esecuzione.

I comandi ant che permettono la realizzazione della fase di annotation processing non cambiano, anche se
processano l’annotazione @HandlerChain prima assente. Tuttavia è necessario aggiungere al target
<compileService>, dopo l’annotation processing, il comando di copia del file [Link] da etc alla
directory build/classes, altrimenti a runtime la classe LibreriaImpl non troverebbe il file [Link], e si
verificherebbe un errore. Ecco la nuova forma del target <compileService>:
<target name="compileService">
... comandi ANT preesistenti, di annotation processing ...
<copy todir="${classes}">
<fileset dir="${basedir}/etc">
<include name="[Link]"/>
</fileset>
</copy>
</target>

Eseguendo il target, il file [Link] viene copiato in build/classes.

Generazione del file WAR, suo caricamento e funzionamento.

Il target <warGen> resta invariato. Anche il target <copy> non cambia; come prima, il file [Link]
viene copiato nella directory C:/WAR files. Servendomi di Tomcat Manager, scarico (undeploy) la vecchia
versione di PeopleWS, e carico (deploy) la versione nuova.

L’output della classe LoggingHandler stavolta va all’interno del file di log tomcat7-stdout.<data>.log, nella
directory Tomcat/logs.

Scenario di funzionamento.
Con la web service attiva su user-pc, apro un command prompt sul PC remoto METRO e lancio il client
PeopleWSClient: java –jar [Link] user-pc, quindi chiamo il metodo PeopleListByRange
passandogli le matricole 2 (iniziale) e 8 (finale).

Nel command prompt, vedo l’output del client, e in esso si distingue il messaggio di richiesta in uscita,
corrispondente alla chiamata al metodo PeopleListByRange:
Outbound message at 18/01/2014 19:19:53
<S:Envelope xmlns:S=”[Link]
xmlns:SOAP-ENV=”[Link]
<SOAP-ENV:Header/>

pag. 140
Advanced Java rev. 1.0 Novembre 2012

<S:Body>
<ns2:PeopleListByRange xmlns:ns2=”[Link]
<arg0>2</arg0>
<arg1>8</arg1>
</ns2:PeopleListByRange>
</S:Body>
</S:Envelope>

Ho ridefinito il formato della data per chiarezza (niente più millisecondi).

Nel file Tomcat/logs/[Link] trovo la richiesta proveniente dal client, così come l’ha
ricevuta la web service PeopleWS:
Inbound message at 18/01/2014 19:19:54
MessageContext.HTTP_REQUEST_METHOD=POST
accept: text/xml, multipart/related
connection: keep-alive
content-length: 292
content-type: text/xml; charset=utf-8
host: user-pc:8081
soapaction: "[Link]
user-agent: JAX-WS RI 2.2.8 svn-revision#13980
<S:Envelope xmlns:S=”[Link]
xmlns:SOAP-ENV=”[Link]
<SOAP-ENV:Header/>
<S:Body>
<ns2:PeopleListByRange xmlns:ns2="[Link]
<arg0>2</arg0>
<arg1>8</arg1>
</ns2:PeopleListByRange>
</S:Body>
</S:Envelope>

Sempre nel file Tomcat/logs/[Link], vedo la risposta della web service PeopleWS:
Outbound message at 18/01/2014 19:19:55
<S:Envelope xmlns:S=”[Link]
xmlns:SOAP-ENV=”[Link]
<SOAP-ENV:Header/>
<S:Body>
<ns2:PeopleListByRangeResponse xmlns:ns2="[Link]
<return>
<Matricola>2</Matricola>
<Nome>Renzo</Nome>
<Cognome>Calabria</Cognome>
<CodiceFiscale>CLBRNZ43A26D969D</CodiceFiscale>
</return>
<return>
<Matricola>7</Matricola>
<Nome>Giovanni</Nome>
<Cognome>Arrigoni</Cognome>
<CodiceFiscale>RRGGNN46C02A794J</CodiceFiscale>
</return>
<return>
<Matricola>8</Matricola>
<Nome>Edoardo</Nome>
<Cognome>Bianco</Cognome>
<CodiceFiscale>BNCDRD46T16D969Y</CodiceFiscale>
</return>
</ns2:PeopleListByRangeResponse>
</S:Body>
</S:Envelope>

Ecco infine come appare il messaggio ricevuto dal client, nel suo command prompt:

pag. 141
Advanced Java rev. 1.0 Novembre 2012

Inbound message at 18/01/2014 19:19:55

MessageContext.HTTP_RESPONSE_CODE=200
null: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Date: Sat, 18 Jan 2014 18:19:55 GMT
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
<S:Envelope xmlns:S=”[Link]
xmlns:SOAP-ENV=”[Link]
<SOAP-ENV:Header/>
<S:Body>
<ns2:PeopleListByRangeResponse xmlns:ns2="[Link]
<return>
<Matricola>2</Matricola>
<Nome>Renzo</Nome>
<Cognome>Calabria</Cognome>
<CodiceFiscale>CLBRNZ43A26D969D</CodiceFiscale>
</return>
<return>
<Matricola>7</Matricola>
<Nome>Giovanni</Nome>
<Cognome>Arrigoni</Cognome>
<CodiceFiscale>RRGGNN46C02A794J</CodiceFiscale>
</return>
<return>
<Matricola>8</Matricola>
<Nome>Edoardo</Nome>
<Cognome>Bianco</Cognome>
<CodiceFiscale>BNCDRD46T16D969Y</CodiceFiscale>
</return>
</ns2:PeopleListByRangeResponse>
</S:Body>
</S:Envelope>

Ci possono essere leggere differenze nei messaggi, a seconda dei diversi client utilizzati.

pag. 142
Advanced Java rev. 1.0 Novembre 2012

Introduzione alle pagine JSP.

Ho aggiunto tre pagine JSP al sito LightSite, tutte accessibili da [Link]: [Link], [Link] e
[Link].

Generalità sulle pagine JSP mediante l’analisi della pagina [Link].

La pagina [Link] è assai semplice, ma è interessante perché utilizza molte feature proprie di tutte le
pagine JSP, anche di quelle più complesse.

In generale, una pagina JSP consiste di due tipi fondamentali di elementi: template text ed elementi JSP; si
dice template text tutto ciò che non è un elemento JSP, quindi codice HTML, testo semplice, elementi XML,
immagini, codice JavaScript.

Gli elementi JSP a loro volta si possono suddividere in quattro sottotipi: direttive, azioni, scripting e
espressioni EL (Expression Language). Tutti questi elementi vengono processati sul server.

Affinchè un web server sia in grado di operare con le pagine JSP, esso dev’essere un servlet container, ma
non basta: deve anche essere un JSP container, cioè deve essere in grado di trattare le pagine JSP.

Quando un browser richiede al web server una pagina JSP, il web server core gira la richiesta al JSP
container, che opera in due fasi: compilazione (o traduzione) della pagina, e processing della richiesta.

Nella prima fase, il JSP container prima di tutto trasforma la pagina JSP in un servlet: tutto il template text è
convertito in istruzioni println, mentre tutti gli elementi JSP vengono convertiti in codice Java; la classe che
ne risulta viene quindi compilata.

La compilazione della pagina solitamente viene eseguita quando il server riceve la prima richiesta per quella
pagina, ma è anche possibile una strategia di precompilazione, evitando il ritardo nella risposta al primo
utente che richiede la pagina.

In ogni caso, una volta che la compilazione è stata eseguita, la classe servlet è disponibile e viene usata dal
JSP container per la seconda fase: la richiesta proveniente dal client è processata dalla classe servlet
equivalente alla pagina JSP, la risposta viene composta e inviata al browser.

Finchè la pagina JSP non cambia, le richieste successive alla prima non causano compilazioni, per ciascuna
richiesta viene direttamente eseguita la seconda fase (processing della richiesta).

Panoramica sugli elementi JSP.

Quanto segue è riferito alla pagina [Link]: la pagina mostra un saluto attagliato all’ora corrente, ad
esempio se la pagina viene acceduta tra le 5:00 e le 11:59, appare il messaggio Good morning, mentre se
l’invocazione avviene tra le 12:00 e le 18:59, appare la scritta Good afternoon.

Le direttive hanno la forma <%@direttiva ... %>, ove direttiva può essere page, include o taglib; in generale
una direttiva è seguita da parametri. Nel caso di [Link], viene usata la direttiva taglib, ed è la prima riga:
<%@ taglib prefix="c" uri="[Link] %>

I due parametri sono prefix e uri, entrambi valorizzati; discuterò a breve la direttiva taglib. I parametri delle
direttive, e anche delle azioni, vengono detti attributi.

Dopo la prima riga, seguono righe di template text, e dopo queste, segue un elemento di tipo azione:
<html>
<head>
<title>Pagina JSP di saluti</title>
</head>
<body bgcolor="white">
<jsp:useBean id="clock" class="[Link]" />

Le azioni a loro volta si suddividono in standard action, aventi prefisso jsp, e custom action, che vedrò a
breve; quindi la precedente azione è una standard action. Le standard action sono presenti in numero
limitato, sono predefinite nel framework JSP; in particolare, la standard action <jsp:useBean> dichiara e
istanzia un Java bean utilizzato nel seguito della pagina.

pag. 143
Advanced Java rev. 1.0 Novembre 2012

Un Java bean è (per definizione) una classe Java autoconsistente, dotata di un costruttore parameterless:
quest’ultimo è il costruttore che viene invocato da <jsp:useBean>.

Segue il resto del codice della pagina:

<c:choose>
<c:when test="${([Link] >= 5) && ([Link] < 12)}">
<h1>Good morning</h1>
</c:when>
<c:when test="${([Link] >= 12) && ([Link] < 19)}">
<h1>Good afternoon</h1>
</c:when>
<c:when test="${([Link] >= 19) && ([Link] < 21)}">
<h1>Good evening</h1>
</c:when>
<c:otherwise>
<h1>Good night</h1>
</c:otherwise>
</c:choose>
<A HREF="[Link]">Torna alla Home Page</A>
</body>
</html>

I tag <c:choose>, <c:when> e <c;otherwise> corrispondono a custom action; a differenza degli elementi
standard action, gli elementi custom action non sono nativamente presenti nell’architettura JSP, fanno
invece parte di librerie (JAR file) aggiuntive.

È possibile creare i propri elementi di tipo custom action, tuttavia esiste una libreria standard, detta JSTL
(JSP Standard Tag Library), che mette a disposizione un grande numero di tag utili per le esigenze più
diffuse; tra essi, rientrano i tag <c:choose> etc.

JSTL è un’estensione di JSP, implementata in più file JAR, tra i quali i due fondamentali, nella versione da
me utilizzata, sono [Link] e [Link]: questi JAR file
devono essere a disposizione del JSP container, se anche uno solo di essi manca, si verificano errori.
Essendo Tomcat il mio JSP container, ho posto le due librerie nella directory Tomcat/shared/lib.

In alternativa ai due precedenti JAR file, si può usare [Link], ponendolo in Tomcat/shared/lib; non ci sono
apprezzabili differenze.

A questo punto, è chiaro il significato della prima riga, direttiva taglib: il valore dell’attributo uri è assimilabile
alla dichiarazione di un nome simbolico, non è la locazione della libreria JSTL !

È possibile sviluppare una propria libreria di tag, aggiungendo così nuovi tag a quelli già disponibili, tuttavia
esaminerò questa possibilità solamente nel seguito; solitamente non è necessario creare nuovi tag, data
l’abbondanza di tag già definiti in JSTL.

Infine, sono presenti espressioni EL all’interno delle azioni, siano esse le custom action di JSTL oppure le
standard action: le espressioni EL vengono utilizzate per valorizzare gli attributi delle azioni. Il linguaggio EL
ha un numero limitato di keyword, come empty che utilizzerò in seguito, operatori logici (come &&) e
aritmetici, e inoltre dispone di alcune variabili implicite di interesse, che utilizzerò esse pure nel seguito (sono
analoghe agli oggetti server di ASP).

Scripting elements.
Il quarto tipo di elementi JSP è costituito dai cosiddetti scripting elements, non utilizzati in [Link]. In
pratica, uno scripting element consiste di una o più istruzioni scritte in codice Java.

Esistono tre sottotipi di scripting elements, o meglio quattro, se si considerano i commenti come scripting
elements – in una pagina JSP, è possibile porre un commento utilizzando la seguente sintassi:
<%-- testo del commento --%>

Un commento JSP è invisibile al browser: essendo uno scripting element, sta sul lato server.

A parte i commenti, i tre sottotipi di scripting elements sono: espressioni, dichiarazioni e scriptlet.

pag. 144
Advanced Java rev. 1.0 Novembre 2012

Un’espressione è un’istruzione Java che restituisce un valore, il quale va a far parte della risposta; può
anche essere usata per valorizzare l’attributo di un’azione. Ecco un esempio, in cui voglio scrivere la data e
l’ora correnti come titolo della pagina (l’esempio è una pagina JSP completa):
<head><html><title>Data/ora: <%= new [Link]()
%></title></head>></html>

Con ciò, il titolo della pagina diventa Data/ora: Sat Feb 08 00:37:18 CET 2014.

Una dichiarazione è la dichiarazione, scritta in codice Java, di una variabile o di una procedura, che
diventano (rispettivamente) un campo o un metodo dell’istanza della classe servlet risultante dalla
compilazione della pagina JSP.

Nell’esempio che segue, dichiaro una variabile e me ne servo nel seguito, mediante un’espressione:
<%! StringBuffer sb = new StringBuffer("sacone"); %>
<%= [Link]() %>

Nella risposta, appare la scritta enocas.

Infine, uno scriptlet è un pezzo di codice Java inserito nella pagina, eseguito al momento; eccone la sintassi:
<% codice Java %>

In genere, i scripting elements e in particolare i scriptlet dovrebbero essere considerati l’ultima risorsa, è
preferibile utilizzare azioni ed espressioni EL per quanto possibile.

Informazioni di basso livello sulle pagine JSP.

Usando un scripting element, è possibile ottenere alcune informazioni inerenti la classe servlet
corrispondente alla pagina JSP, compiendo in sostanza una reflection.

Ho aggiunto alla pagina [Link] il seguente scripting element, posto subito prima del link di ritorno all’home
page [Link]:
<%! [Link]<String> ident()
{
[Link]<String> infos = new [Link]<String>();
[Link]("ClassName="+[Link]().getName());
[Link]("SuperClassName="+([Link]()).getSuperclass().getName());
[Link]("ServletName="+[Link]());
[Link]("ServletInfo="+[Link]());

[Link]("[Link]="+[Link]().getContextPath(
));

[Link]("[Link]="+[Link]().getServerInfo())
;
return infos;
}
%>
Who am I:
<c:forEach items="<%= [Link]() %>" var="inf">
<br>
<c:if test="${!(empty inf)}">${inf}</c:if>
<c:if test="${empty inf}">NULL</c:if>
</c:forEach>

Ecco il risultato:
Who am I:
ClassName=[Link].Salve_jsp
SuperClassName=[Link]
ServletName=jsp
ServletInfo=Jasper JSP 2.2 Engine
[Link]=/LightSite
[Link]=Apache Tomcat/7.0.47

pag. 145
Advanced Java rev. 1.0 Novembre 2012

La classe corrispondente alla pagina JSP ha un nome evocativo; è subtipo della classe HttpJspBase, che si
trova in Tomcat/lib/[Link], ed è una classe astratta, a sua volta subtipo della classe
[Link], la classe dalla quale discendono direttamente i servlet applicativi,
come Booklet.

Notare: una soluzione migliore è salvare il codice di cui sopra, esattamente com’è, nel file [Link], poi
includerlo nelle pagine che intendono usarlo, con la direttiva <%@ include file="[Link]" %>;
ponendo la direttiva in [Link], il risultato non cambia, ma la pagina è molto più leggibile.

È possibile utilizzare, al posto della direttiva include, la standard action <jsp:include>, scrivendo
<jsp:include page="[Link]" /> entro la pagina includente. Ci sono alcune differenze importanti
tra la direttiva e la standard action: la prima è valutata nella fase di compilazione, la seconda nella fase di
request processing, inoltre la seconda permette il passaggio dinamico del nome della pagina da includere,
ad esempio tramite un’espressione EL.

Supponiamo di utilizzare la standard action anziché la direttiva, all’interno di [Link]: l’output che si ottiene
è simile, ma con la differenza che stavolta ClassName=[Link].Reflex_jsp.

Si tratta di una differenza facilmente spiegabile: la standard action <jsp:include> opera nella fase di
processing della richiesta, quando ormai la compilazione è stata effettuata e le classi servlet equivalenti
generate per entrambe le pagine, e così esiste una classe di nome Reflex_jsp, ed è questa che esegue il
codice, è ad essa che appartiene il metodo ident. Nel caso della direttiva include, che opera nella fase di
compilazione, il codice della pagina inclusa diventa parte del codice della pagina includente, perciò in
ingresso alla fase di request processing c’è una sola classe, Salve_jsp, cui appartiene il metodo ident.

L’uso di form HTML nelle pagine JSP.

Il modo canonico per passare al server informazioni presenti nel template text, tipicamente i valori dei
controlli HTML presenti nella pagina, consiste nell’aggiunta di una HTML form alla pagina, porre i controlli
entro la form ed effettuare la post della form: i nomi e i valori dei controlli HTML vengono passati, come
coppie chiave/valore, al server nel messaggio di richiesta. Esistono altre vie per passare informazioni da
client a server, ad esempio l’uso di AJAX, oppure invocando i metodi di una web service tramite un client
stub, tutte queste vie sono disponibili alle pagine JSP, tuttavia si preferisce in genere la post di una form.

La pagina autoimpostante [Link].

Una tecnica comune nelle pagine JSP (ma anche nelle pagine ASP) è lo sviluppo di una pagina
autoimpostante, ossia una pagina dotata di una form HTML la cui action richiama la pagina stessa.

Espongo il codice della pagina [Link]:

<%@ taglib prefix="c" uri="[Link] %>
<html>
<head>
<title>Pagina JSP di calcolo complesso</title>
<script language="JavaScript">
function DataOk()
{
...
}
</script>
</head>
<body bgcolor="white">
<jsp:useBean id="cx" class="[Link]" />
<c:if test="${!(empty [Link])}">
<jsp:setProperty name="cx" property="real" value="${[Link]}"/>
<jsp:setProperty name="cx" property="img" value="${[Link]}"/>
</c:if>
<form action="[Link]" name="Mask" onSubmit="return DataOk()"
method=POST>
<table border=1>
<tr><td>Reale</td><td>
<c:if test="${!(empty [Link])}">
<INPUT NAME=reale TYPE=Text VALUE="${[Link]}">
</c:if>
<c:if test="${(empty [Link])}">

pag. 146
Advanced Java rev. 1.0 Novembre 2012

<INPUT NAME=reale TYPE=Text VALUE="">

</c:if>
</td><td>Immaginario</td><td>
<c:if test="${!(empty [Link])}">
<INPUT NAME=immag TYPE=Text VALUE="${[Link]}">
</c:if>
<c:if test="${(empty [Link])}">
<INPUT NAME=immag TYPE=Text VALUE="">
</c:if>
</td></tr><tr><td>Numero complesso</td><td>
<c:if test="${!(empty [Link])}">${cx}</c:if>
</td><td>modulo</td><td>
<c:if test="${!(empty [Link])}">${[Link]()}</c:if>
</td></tr><tr><td>Fattore moltiplicativo</td><td>
<c:if test="${!(empty [Link])}">
<INPUT NAME=factor TYPE=Text VALUE="${[Link]}">
/c:if>
<c:if test="${(empty [Link])}">
<INPUT NAME=factor TYPE=Text VALUE="">
</c:if>
</td><td>Risultato</td><td>
<c:if test="${!(empty [Link])}">
${[Link]([Link])}
(modulo=${[Link]([Link]).module()})
</c:if>
</td></tr>
</table>
<INPUT NAME=goBtn VALUE="Calcola" TYPE=submit>
</form>
<HR>
<A HREF="[Link]">Torna alla Home Page</A>
</body>
</html>

Ecco come appare la pagina, dopo che l’utente ha inserito i valori nei campi reale, immag e factor
(rispettivamente, 3, 4 e 20) e premuto il submit button:

Il codice JavaScript della funzione DataOk è stato omesso per brevità, ma è abbastanza semplice: esegue il
controllo sui tre campi di input della form, e se anche uno solo di essi risulta vuoto, oppure contenente un
valore che non può essere tradotto in un numero reale, allora dà un messaggio d’errore (alert) e restituisce
false, annullando il POST della form; altrimenti restituisce true e il POST della form viene effettuato.

pag. 147
Advanced Java rev. 1.0 Novembre 2012

Uso di un custom bean.

Quando la pagina viene chiamata, e in seguito ad ogni server round trip causato dal submit della form, viene
eseguita l’azione <jsp:useBean id="cx" class="[Link]" />, che impiega il custom bean
[Link]: ogni volta che l’azione viene eseguita, viene creata un’istanza della classe [Link],
utilizzando il suo costruttore parameterless (che crea un numero complesso con le parti reale e immaginaria
entrambe uguali a 0).

La classe [Link] appartiene a [Link]; ciò significa che bisogna aggiungere a tomcat-apps/Light la
directory WEB-INF/lib (se non è già presente), copiarvi dentro [Link] e rigenerare il sito.

Ingresso nella pagina, post della form e uso dell’oggetto param di EL.
Una delle variabili implicite del linguaggio EL è l’oggetto param, che è una collezione, di tipo [Link], di
tutti i valori dei parametri della richiesta. Qui, la richiesta è provocata dal post della form Mask: premendo il
submit button goBtn, e supponendo che la funzione DataOk ritorni true, allora viene spedito al server un
messaggio di richiesta, di tipo HTTP POST, i cui parametri hanno nome e valore come i controlli della form –
non tutti i controlli HTML contenuti nella form partecipano all’operazione POST, ma di certo vi partecipano i
controlli <input TYPE=text> e il submit button, quindi i controlli di nome reale, immag, factor e goBtn.

In effetti, il messaggio HTTP POST inviato nel caso illustrato nella precedente figura, ha il seguente body:
reale=3&immag=4&factor=20&goBtn=Calcola.

Aggiungo un codice temporaneo alla pagina [Link], per meglio studiare l’oggetto EL param:
<c:if test="${!(empty param)}" >
<c:forEach items="${param}" var="par">
${[Link]} = ${[Link]}<br>
</c:forEach>
</c:if>
<c:if test="${empty param}" >param is empty<br></c:if>
Il codice di cui sopra sfrutta la natura di collezione di coppie chiave/valore dell’oggetto param. Come si vede
dal codice della pagina, per indirizzare il parametro (chiave) reale, mi basta scrivere [Link], e
analogamente [Link] etc.

Come sempre nel caso delle pagine autoimpostanti, bisogna fare attenzione al diverso comportamento del
codice all’ingresso nella pagina rispetto alle successive post della form.

All’ingresso nella pagina, param è vuoto e appare la scritta param is empty; con ciò, seguendo il codice
della pagina, ai campi del bean cx non vengono assegnati valori, e la form Mask viene presentata completa
ma con tutti i campi vuoti, infatti [Link] e tutti gli altri sono ovviamente vuoti.

L’utente inserisce i dati nei tre campi e preme il button, così facendo viene effettuata la post della form; la
action della form identifica il destinatario della post, che è la pagina stessa (di qui il termine autoimpostante).
Con ciò, il codice della pagina viene rieseguito, stavolta però param non è vuoto, e infatti dal codice
provvisorio trovo ciò che mi aspettavo: goBtn = Calcola
immaginario = 4
factor = 20
reale = 3

Posso rimuovere il codice provvisorio dalla pagina [Link] e proseguire con l’analisi del codice
effettivo: stavolta i campi del bean cx vengono valorizzati, ricevendo i valori già passati nella post; gli stessi
valori vecchi (cioè del precedente server round trip) vengono scritti nei campi della form, l’effetto per l’utente
è la conservazione dei valori nei campi della form (senza questo passaggio li rivedrebbe vuoti).

L’esecuzione dell’espressione EL ${cx} scrive il valore del complesso, 3+4i, nella table, chiamando
implicitamente il metodo toString della classe [Link]; per calcolare il modulo, l’espressione EL
corretta è ${[Link]()}. Si noti anche, sempre come espressione EL, la chiamata di un metodo con
parametro di passaggio: ${[Link]([Link])}.

Accesso al database.
La pagina [Link] permette un facile accesso ai dati del database DBPeople, usando azioni JSP,
senza ricorrere a custom bean o a scripting element. Anche [Link] è una pagina autoimpostante, ed
è autosufficiente in quanto reperisce i dati che presenta. Segue il codice della pagina:

pag. 148
Advanced Java rev. 1.0 Novembre 2012

<%@ taglib prefix="c" uri="[Link] %>

<%@ taglib prefix="sql" uri="[Link] %>
<html>
<head>
<title>Pagina JSP di accesso ai dati degli impiegati</title>
<script language="JavaScript">
function DataOk()
{
...
}
</script>
</head>
<body bgcolor="white">
<form action="[Link]" name=Mask onSubmit="return DataOk()"
method=POST>
Nominativo
<c:if test="${!(empty [Link])}">
<INPUT NAME=cgn TYPE=Text VALUE="${[Link]}">
</c:if>
<c:if test="${(empty [Link])}">
<INPUT NAME=cgn TYPE=Text VALUE="">
</c:if>
<INPUT TYPE=submit name=goBtn value="Invia">
</form>
<hr>
<c:if test="${!(empty [Link])}">
<sql:setDataSource var="dbPeople"
driver="[Link]"
url="jdbc:oracle:thin:@localhost:1521:XE"
user="DBPeople" password="sacone58" />
<sql:query var="empls" dataSource="${dbPeople}"
sql="select * from people where cognome like ?">
<sql:param value="${[Link]}%" />
</sql:query>
</c:if>
<c:if test="${[Link] > 0}">
<H3>Trovati ${[Link]} impiegati</H3>
<table id="Griglia" width=500px border=1>
<tr>
<c:forEach items="${[Link]}" var="colName">
<th><B>${colName}</B></th>
</c:forEach>
</tr>
<c:forEach items="${[Link]}" var="row">
<tr><td>${[Link]}</td>
<td>${[Link]}</td>
<td>${[Link]}</td>
<td>${row.codice_fiscale}</td></tr>
</c:forEach>
</table>
</c:if>
<c:if test="${[Link] == 0}">
<H3>Nessun impiegato trovato</H3>
</c:if>
<A HREF="[Link]">Torna alla Home Page</A>
</body>
</html>

Il codice JavaScript della funzione DataOk è stato omesso per brevità, ma è abbastanza semplice: esegue il
controllo sul campo cgn della form, ove viene scritto il nominativo (parte iniziale del cognome degli
impiegati): il campo non può essere vuoto, e deve cominciare con una lettera maiuscola; se le condizioni non
sono rispettate, viene dato un messaggio d’errore (alert) e la funzione DataOk restituisce false, annullando
il POST della form; altrimenti, la funzione restituisce true e il POST della form viene effettuato.

pag. 149
Advanced Java rev. 1.0 Novembre 2012

Su param e sul meccanismo di post valgono le considerazioni già fatte a proposito della pagina
[Link]; in particolare, all’ingresso nella pagina, la HTML textbox cgn appare vuota, essendo
vuoto param e quindi [Link], e il resto del codice della pagina non viene eseguito.

Una volta scritto qualcosa di ammissibile nella textbox cgn, premendo il submit button viene compiuto un
server round trip, cioè un post della form; stavolta param non è vuoto, per cui il valore di [Link] viene
assegnato alla HTML textbox cgn, dando all’utente la sensazione di continuità. Ma soprattutto, vengono
eseguite le azioni di accesso ai dati nel database.

Nella sua forma più semplice, l’accesso in lettura ad un database prevede l’uso di due sole azioni, entrambe
definite nella libreria JSTL e con un proprio nome simbolico: l’azione <sql:setDataSource>, che apre la
connessione al database, e l’azione <sql:query>, che effettua una query; il loro uso è molto semplice, si
intuisce senza problemi leggendo il codice della pagina.

Supponendo che l’utente abbia scritto D entro la textbox cgn, la query che risulta dall’azione <sql:query>
(comprensiva di <sql:param>) è select * from people where cognome like ‘D%’:

I risultati della query vengono posti nella variabile EL empls, definita nell’azione <sql:query>, il resto è una
semplice presentazione tabellare dei dati.

Visibilità e persistenza degli oggetti di accesso al database.

Entrambe le azioni, <sql:setDataSource> e <sql:query>, hanno l’attributo scope, che non ho esplicitamente
valorizzato; l’attributo scope definisce la visibilità e la persistenza della variabile definita nelle azioni.

I valori ammissibili per l’attributo scope sono quattro: page, request, session e application; il default è page,
ed è il valore che viene usato quando, come nel caso di [Link], l’attributo non viene assegnato.
Inizio l’analisi trattando il solo data source.

Il data source con scope = page è visibile solamente nella pagina cui appartiene, viene creato all’ingresso
nella pagina e viene ricreato ad ogni server round trip; se scope = request, allora esso ha lo stesso ciclo di
vita della richiesta: se la pagina cui il data source appartiene effettua un forward verso un’altra pagina, allora
il data source persiste ed è visibile nella pagina acceduta, dato che si tratta sempre della stessa richiesta.

Si noti che scope = page è il più ristretto in termini sia di visibilità sia di persistenza, e scope = request è
poco più ampio: anche con scope = request, il data source viene ricreato ad ogni nuovo accesso alla pagina
che lo contiene ed anche ad ogni server round trip – si tratta ogni volta di una nuova richiesta.

pag. 150
Advanced Java rev. 1.0 Novembre 2012

Assegnando scope = session, il data source è visibile in tutte le pagine del sito, anche aprendo il sito in più
finestre del browser purchè appartenenti alla stessa sessione, e perdura finchè il browser non viene
completamente chiuso, terminando così la sessione.

Posso ad esempio riscrivere l’azione <sql:setDataSource> in [Link], come segue:

<c:if test="${empty dbPeople)}">
<sql:setDataSource var="dbPeople" scope="session"
driver="[Link]"
url="jdbc:oracle:thin:@localhost:1521:XE"
user="DBPeople" password="sacone58" />
</c:if>

Il test <c:if> è necessario, senza di esso ricreerei comunque il data source. Tutto il resto del codice della
pagina [Link] resta invariato.

Posso verificare facilmente che il data source viene creato solo una volta, nel seguito viene riutilizzato, non
importa quante volte entri ed esca dalla pagina, o quanti server round trip vengano effettuati.

Ma c’è di più: posso utilizzare il data source anche in un’altra pagina. Ad esempio, posso (provvisoriamente)
aggiungere il seguente codice alla pagina [Link]:
<c:if test="${!(empty dbPeople)}" >
<%@ taglib prefix="sql" uri="[Link] %>
<sql:query var="lista" dataSource="${dbPeople}" sql="select * from
people" />
<br>Ci sono ${[Link]} impiegati nel database<br>
</c:if>

Apro il browser, accedo il sito LightSite, entro nella pagina [Link] ed effettuo una query; poi apro una
nuova scheda (quindi appartenente alla medesima sessione), accedo in essa il sito LightSite ed entro nella
pagina [Link]: vedrò comparire la scritta: Ci sono 49 impiegati nel database.

Infine, usando scope = application, il data source è visibile in tutte le pagine del sito, anche aprendo il sito in
browser operanti in sessioni diverse, o anche accedendo il sito da browser diversi (ad esempio da Internet
Explorer e da Google Chrome); il data source persiste finchè non ricarico il sito (ad esempio, usando la voce
Reload di Tomcat Manager).

La scelta del valore da assegnare all’attributo scope del data source è questione applicativa: da un lato,
utilizzare un scope non volatile, come session o application, evita la necessità di aprire e chiudere una
connessione ogni volta che si effettua una richiesta; d’altro canto, l’uso di un data source permanente
comporta il mantenimento di una connessione sempre aperta. La scelta dipende in ultima analisi dalla natura
complessiva dell’applicazione, incluse le sue condizioni di utilizzo.

Infine, anche l’azione <sql:query> ha l’attributo scope, con gli stessi valori; tuttavia l’uso di una query
persistente mi sembra meno interessante, trovo più naturale (almeno, nella grande maggioranza dei casi)
assegnare scope = page oppure request all’azione <sql:query>.

Barriere e aperture tra codice client, codice Java e azioni nelle pagine JSP.
Nell’architettura di una pagina JSP sono presenti tre componenti costitutivi: il template text, costituito da tag
HTML, client script (solitamente ma non obbligatoriamente JavaScript); il codice Java, presente nella pagina
come scriping element (dichiarazione, assegnazione o scriptlet che sia); il codice delle azioni, che chiamo
sinteticamente (e forse impropriamente) codice JSP, comprendendo in esso anche le espressioni EL.

Tutte e tre le componenti contribuiscono alla composizione della pagina che viene presentata dal browser; il
processing del template text avviene su browser e il processing del resto su server: in base a questa
considerazione, si potrebbe pensare a due ambienti, l’ambiente client (browser) al quale appartengono tutti
gli elementi del template text, e l’ambiente server al quale appartengono tutti gli altri elementi.

Tuttavia io adotto una tripartizione, cioè penso a tre ambienti: l’ambiente client al quale appartiene ogni
elemento di tipo template text; l’ambiente codice Java al quale appartiene ogni scripting element; l’ambiente
JSP al quale appartengono le azioni e le espressioni EL, ed anche le direttive.

È importantissimo capire come i tre ambienti interagiscano tra loro, in particolare quali sono le vie praticabili
per passare le informazioni da un ambiente all’altro, e quali sono invece le barriere.

pag. 151
Advanced Java rev. 1.0 Novembre 2012

Dato un controllo HTML nella pagina JSP, dotato di un nome e di un valore, esso risulta invisibile sia al
codice Java dei scripting elements sia al codice JSP; è possibile rendere noti nome e valore del controllo al
codice delle espressioni EL effettuando la post della form che contiene il controllo, indi accedendo l’oggetto
param nel codice EL.

Non si possono accedere gli oggetti e le variabili di EL, né oggetti definiti in un’azione, dal codice Java di un
scripting element; vale anche il viceversa: definito un oggetto in un scripting element, esso risulta
sconosciuto nel codice JSP.

Se definisco un bean, ad esempio l’oggetto cx di tipo [Link] entro la standard action <jsp:useBean>,
l’oggetto cx potrà essere utilizzato nelle espressioni EL di altre azioni, ma risulterà sconosciuto al codice
Java dei scriptlet.

Se viceversa definisco cx di tipo [Link] usando un scripting element di tipo dichiarazione, esso
risulterà sconosciuto nel codice JSP (EL incluso) delle azioni.

Un scripting element di tipo assegnazione può contribuire al template text, producendo esso stesso del
template text, come nel caso seguente:
<%! int cnt = 12; %>
...
<INPUT NAME="Contatore" TYPE=Text VALUE="<%= cnt %>">

ciò non significa che lo scripting element veda il codice HTML o JavaScript, né vale il viceversa, in pratica è
come se il codice Java dell’assegnazione compisse un output testuale.

Si può usare l’assegnazione anche all’interno di codice JavaScript, il che non stupisce, essendo quest’ultimo
template text; ad esempio, posso dichiarare una variabile Java e poi mostrarne il valore:
<%! int cnt = 12; %>
...
<script language="JavaScript">
alert("Valore del contatore = " + <%= cnt %>);
</script>

Allo stesso modo, un scripting element di tipo assegnazione può contribuire ad un’azione; un esempio viene
fornito nella pagina [Link]: <c:forEach items="<%= [Link]() %>" var="inf">, l’attributo
items dell’azione è valorizzato usando codice Java (la funzione ident è implementata in un scripting
element).

Anche le espressioni EL possono essere usate per produrre template text, ad esempio:
<INPUT NAME=cgn TYPE=Text VALUE="${[Link]}" >
...
<script language="JavaScript">
alert("Valore del parametro = " + "${[Link]}");
</script>

Case study.
Voglio che l’utente della pagina [Link] venga allertato quando, effettuando una query, la somma
delle matricole trovate superi un certo limite, ad esempio 6000: si tratta di una richiesta speciosa, e una volta
soddisfatta, il codice che la soddisfa può essere rimosso, ma è interessante la soluzione fornita.

Nella pagina [Link] è già presente un loop, <c:forEach>, che scrive i risultati (righe) della query in
una HTML table; allora, definisco la variabile sommaMatricole subito prima del loop e la uso per
immagazzinarvi la somma delle matricole. Segue il codice:
<c:set var="sommaMatricole" value="0" />
<c:forEach items="${[Link]}" var="row">
<tr>
<td>${[Link]}</td>
<td>${[Link]}</td>
<td>${[Link]}</td>
<td>${row.codice_fiscale}</td>
</tr>
<c:set var="sommaMatricole" value="${sommaMatricole+[Link]}" />
</c:forEach>

pag. 152
Advanced Java rev. 1.0 Novembre 2012

<c:if test="${sommaMatricole > 6000}" >

<script language="JavaScript">
alert("somma delle matricole = "+${sommaMatricole}+", è molto alta");
</script>
</c:if>
Il codice è ben comprensibile, e funziona correttamente, ecco ciò che accade quando l’utente scrive la
lettera M e poi preme Invia:

L’azione <c:set> crea la variabile, sommaMatricole, se essa non esiste, e la aggiorna se già esiste.

pag. 153
Advanced Java rev. 1.0 Novembre 2012

Uso dei cookie.

La pagina [Link] è nata dalla seguente esigenza: bisogna realizzare una pagina, sia essa
costituita da solo codice HTML oppure una pagina JSP, dotata di campi di ricerca sui libri (database
Libreria), per nominativo e per range di codici; la pagina deve ricavare i dati chiamando il servlet Booklet.
La pagina deve, tra una query e l’altra,
mantenere i precedenti valori inseriti
nei campi di ricerca; i campi di ricerca
appaiono vuoti all’ingresso nella
pagina, chiamata dalla home page.

Sopra è raffigurata la pagina, così come appare all’ingresso (provenendo da [Link]).

Esiste già una pagina che soddisfa questi requisiti, ed è [Link], già studiata: utilizza il sistema
AJAX per invocare il servlet Booklet e gestire la risposta. L’oggetto XmlHttpRequest è molto utile, perché con
esso non si pongono problemi di mantenimento dei valori nei campi tra una query e l’altra: sia che venga
usata una GET o una POST, essa avviene tra l’oggetto XmlHttpRequest e il servlet (o web service), senza
affliggere il resto della pagina.

Invece BookletInfo,html non utilizza AJAX, ma due semplici HTML form, che – tramite il proprio submit
button – effettuano una POST indirizzata al servlet.

Prima versione, ingenua, della pagina.

In prima battuta, posso sviluppare una pagina assai semplice:
<html>
<head>
<title>Pagina HTML client di Booklet</title>
<script language="JavaScript">
function DataOk(opt)
{
...
}
</script>
</head>
<body bgcolor="white">
<form action="/Booklet/Answers" name=MaskA onSubmit="return
DataOk('A');"
method=POST>
Nominativo <INPUT NAME=Nominativo TYPE=Text VALUE="" />
<INPUT TYPE=hidden name=Funzione value="ListaLibrodnByAutore" />
<INPUT TYPE=hidden name=XML value="Y" />
<INPUT TYPE=submit name=goBtn value="Invia" />
</form>
<hr/>
<form action="/Booklet/Answers" name=MaskB onSubmit="return
DataOk('B');"
method=POST>
Da <INPUT NAME=CodiceIniziale TYPE=Text VALUE="" />
a <INPUT NAME=CodiceFinale TYPE=Text VALUE="" />
<INPUT TYPE=hidden name=Funzione value="ListaLibrodnByRangeCod" />
<INPUT TYPE=hidden name=XML value="Y" />
<INPUT TYPE=submit name=goBtn value="Invia" />
</form>
<A HREF="[Link]">Torna alla Home Page</A>
</body>
</html>.

pag. 154
Advanced Java rev. 1.0 Novembre 2012

Per controllare l’accettabilità dei dati in ingresso, entrambe le form, MaskA e MaskB, chiamano la funzione
booleana DataOk; quest’ultima ha il parametro opt proprio per distinguere la form chiamante: se ‘A’, la form
chiamante è MaskA, se ‘B’ è MaskB.

La form MaskA ha un solo campo visibile di input, Nominativo; i controlli svolti da DataOk(‘A’) accertano che
il valore del campo non sia vuoto e che inizi con una lettera maiuscola. La form MaskB ha due campi visibili
di input, CodiceIniziale e CodiceFinale; i controlli svolti da DataOk(‘B’) accertano che i valori dei due campi
siano entrambi non vuoti, che corrispondano a valori interi positivi, e non siano in ordine inverso.

Entrambe le form hanno due campi hidden: Funzione, che definisce quale funzionalità viene richiesta al
servlet, e XML, con il valore Y, in modo che il servlet fornisca una risposta in formato XML (e non binario).

Analisi dei messaggi HTTP.

Supponiamo di scrivere il valore Ca nel campo Nominativo, e i valori 1 e 6 nei campi CodiceIniziale e
CodiceFinale; premendo il submit button di MaskA, viene generato il seguente messaggio HTTP POST:
POST /Booklet/Answers HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: [Link]
Accept-Language: it-IT
User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident 7.0; rv:11.0) like Gecko
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: user-pc:8081
Content-Length: 61
DNT : 1
Connection: Keep-Alive
Cache-Control: no-cache

Nominativo=Ca&Funzione=ListaLibrodnByAutore&XML=Y&goBtn=Invia

Questo è il messaggio generato, nel caso il browser sia Internet Explorer 11; se avessi usato Google
Chrome, avrei ottenuto un messaggio un po’ diverso, ma con gli stessi header essenziali e lo stesso body.

Se avessi premuto il submit button della forma MaskB, avrei ottenuto un messaggio con lo stesso header,
ma Content-Length = 81, e il seguente body:
CodiceIniziale=1&CodiceFinale=6&Funzione=ListaLibrodnByRangeCod&XML=Y&goBtn=Invia.

Al solito, i nomi dei controlli HTML campi delle form devono essere uguali ai nomi dei parametri che il servlet
Booklet si attende nel messaggio di richiesta.

Utilizzo di XSLT in Booklet.

La risposta del servlet Booklet, che costituisce il body del messaggio di risposta, è un documento XML,
strutturato come il seguente:
<?xml version='1.0' encoding='ISO-8859-1'?>
<doc>
<libro>
<Codice>6</Codice>
<Titolo>Insomnia</Titolo>
<Autore>Stephen King</Autore>
</libro>
...
<libro>
<Codice>15</Codice>
<Titolo>Redenzione immorale</Titolo>
<Autore>Philip K. Dick</Autore>
</libro>
</doc>

La dichiarazione esplicita dell’encoding permette la gestione corretta dei caratteri accentati.

Nel caso della pagina [Link], l’oggetto XmlHttpRequest spedisce la richiesta e riceve la risposta,
così facendo i dati sono disponibili direttamente sul lato client e possono essere trattati dal codice

pag. 155
Advanced Java rev. 1.0 Novembre 2012

JavaScript; questo non è possibile nel caso della pagina [Link]: la risposta del servlet giunge
direttamente, in pratica si passa dal sito LightSite al servlet Booklet, come si vede dalla figura seguente.

Nell’esempio seguente, l’utente ha scritto Z nel campo Nominativo, e ha sottoposto la form (MaskA):

la pagina di risposta è quindi

l’output diretto del servlet
Booklet, è un documento
XML, che appare con la
formattazione fornita dal
foglio di stile implicitamente
applicato dal browser14.

La soluzione non è affatto

soddisfacente, la pagina è
troppo grezza e manca
anche del ritorno alla home
page o alla pagina
precedente, anzi addirittura
si trova fuori dal sito
LightSite, e per tornare
indietro bisogna usare il
tasto back del browser.

Una soluzione elegante è possibile, mediante un apposito file XSLT: trovandone la dichiarazione (o meglio, il
riferimento) in testa al documento XML, il browser utilizza il file XSLT referenziato, anziché applicare il
proprio foglio di stile default.

Allo scopo, aggiungo la seguente riga al codice di Maine, metodo doGet, nel progetto Booklet:
PrintWriter pw = [Link]();
[Link]("text/xml");
[Link]("<?xml version='1.0' encoding='ISO-8859-1'?>");
[Link]("<?xml-stylesheet type='text/xsl'
href='[Link]
[Link]("<doc>");
...

la parte colorata è la riga aggiunta, il resto è codice preesistente. Con ciò, il documento XML costruito dal
servlet Booklet è il seguente:
<?xml version='1.0' encoding='ISO-8859-1'?>
<?xml-stylesheet type='text/xsl'
href='[Link]
<doc>
<libro>
<Codice>1</Codice>
<Titolo>The two-timers (Cronomoto)</Titolo>
<Autore>Bob Shaw</Autore>
</libro>
...
</doc>

Ho creato la directory misc entro Tomcat/webapps, in modo che faccia parte del default site di Tomcat e sia
quindi facilmente accessibile da tutti i siti contenuti in Tomcat/webapps, come LightSite e anche Booklet. Il
file [Link] fornisce una presentazione dei dati XML, dà al documento XML una veste grafica, ma non si
limita a questo, infatti fornisce anche una via di ritorno alla pagina [Link] e quindi al sito LightSite.

14
In figura, il browser utilizzato è Internet Explorer 11; anche Chrome applica un foglio di stile default ai dati
XML, un po’ diverso, ma non molto, da quello di Internet Explorer.

pag. 156
Advanced Java rev. 1.0 Novembre 2012

Analisi di [Link] e suo utilizzo .

Non è qui la sede per studiare i file XSLT, mi limiterò a fornire informazioni orientate al corrente caso d’uso,
confidando anche sulle capacità autoesplicative del codice XSLT di [Link], esposto di seguito.

Nella direttiva xsl:stylesheet, la dichiarazione del namespace di prefisso xsl ha valore di namespace, non di
effettivo collegamento Internet; i tag XSLT appartengono a quel namespace.
<xsl:stylesheet xmlns:xsl=[Link]
version="1.0">
<xsl:template match="/">
<HTML>
<HEAD>
<TITLE>Elenco Libri</TITLE>
<SCRIPT language="JavaScript">
function back()
{ [Link]("/LightSite/[Link]","_parent"); }
</SCRIPT>
</HEAD>
<BODY>
<H3>Elenco di Libreria
<INPUT name="RetHPBtn" type="Button" value="Torna alla Home
Page"
onclick="return back();" />
</H3>
<xsl:if test="count(doc/Libro) > 0">
<H3>Trovati <xsl:value-of select="count(doc/Libro)"/>
libri</H3>
<TABLE BORDER="2">
<TR><TD>Codice</TD><TD>Titolo</TD><TD>Autore</TD></TR>
<xsl:for-each select="doc/Libro">
<TR>
<TD><xsl:value-of select="Codice"/></TD>
<TD><xsl:value-of select="Titolo"/></TD>
<TD><xsl:value-of select="Autore"/></TD>
</TR>
</xsl:for-each>
</TABLE>
</xsl:if>
<xsl:if test="count(doc/Libro) = 0"><H3>Nessun libro
trovato</H3>
</xsl:if>
</BODY>
</HTML>
</xsl:template>
</xsl:stylesheet>

C’è un solo template, applicato al documento XML in toto, infatti l’attributo match punta al root element del
documento XML.

Segue l’impostazione HTML della pagina, in particolare viene definito il HTML button, RetHPBtn, mediante il
quale – con l’invocazione di un’apposita funzione JavaScript – si può tornare alla pagina [Link]; è
importante notare il valore _parent assegnato al secondo parametro della funzione [Link], senza il
quale la pagina [Link] verrebbe visualizzata in una nuova finestra15.

15
Siccome la window è sempre la stessa, al di là che in essa vengano aperte pagine del sito LightSite o
documenti provenienti dal servlet Booklet, avrei anche potuto passare il valore _self al secondo parametro di
[Link], ottenendo lo stesso risultato ottenuto con l’uso di _parent.

pag. 157
Advanced Java rev. 1.0 Novembre 2012

A sinistra, si vede il risultato, supponendo di aver

scritto Nominativo = C nella pagina [Link],
e quindi eseguito il POST di MaskA.

Il problema della persistenza dei valori nei campi delle form.

Utilizzando il tasto di ritorno, RetHPBtn definito entro [Link], viene riaperta nel browser la pagina
[Link], i cui campi (Nominativo, CodiceIniziale e CodiceFinale) appaiono però vuoti: come
m’aspettavo, non c’è persistenza.

Il tentativo fallimentare dell’uso di una pagina JSP.

Per risolvere il problema della persistenza dei valori inseriti nei campi delle form, trasformo la pagina
[Link] in una pagina JSP, cioè [Link].

Le modifiche per passare da [Link] a [Link] sono ben circoscritte: aggiungo la solita
direttiva <%@ taglib prefix="c" uri="[Link] %> in testa alla
pagina, poi circondo i campi di input delle due form con il codice JSP di recupero del valore:
Nominativo
<c:if test="${!(empty [Link])}">
<INPUT NAME=cgn TYPE=Text VALUE="${[Link]}">
</c:if>
<c:if test="${(empty [Link])}">
<INPUT NAME=cgn TYPE=Text VALUE="">
</c:if>

Mi comporto analogamente per i campi CodiceIniziale e CodiceFinale.

Modifico anche il file [Link], facendogli referenziare la pagina JSP anzichè la pagina HTML.

Tuttavia questa soluzione non funziona: utilizzando il tasto di ritorno, RetHPBtn definito entro [Link],
viene riaperta nel browser la pagina [Link], i cui campi (Nominativo, CodiceIniziale e CodiceFinale)
appaiono però vuoti: non c’è persistenza.

Ciò accade perché param è vuoto, e lo è perché, rientrando in [Link] dopo la pressione del tasto
RetHPBtn, la richiesta è già stata esaurita, quindi param – che ha lo scope della richiesta – è inizializzato.
Con ciò, l’uso della pagina JSP non può risolvere il problema della persistenza.

Uso dei cookie su lato client.

Una soluzione semplice ed effettiva è possibile, tornando alla pagina [Link], ma introducendovi
l’utilizzo dei cookie.

Un cookie è un insieme di dati, nella forma di una o più coppie nome/valore, che viene conservato più o
meno permanentemente da un browser; il browser mantiene i cookie nella directory (locale) dei file
temporanei, di qui la persistenza.

I cookie presenti nel browser possono essere stati ricevuti da un sito web, quindi originati da un server, ma
possono anche essere generati da codice client (JavaScript), come nel caso di [Link]. Nel primo
caso si suppone che il browser client e il web server si scambino i cookie, ad esempio per una
identificazione dell’utente; nel secondo caso, il browser non invia i cookie al server, cioè al servlet Booklet: i
cookie restano su client, e servono come strumenti di persistenza di informazioni residenti sul client.

Creazione, persistenza e visibilità dei cookie.

Come riferimento, adotto il codice della pagina [Link], già presentato.

pag. 158
Advanced Java rev. 1.0 Novembre 2012

Operativamente, i cookie vengono creati quando l’utente, dopo aver inserito valori nei campi delle form,
preme uno dei due submit button: in tal caso, viene chiamata la funzione JavaScript DataOk, che esegue
controlli sui dati inseriti, e, se i controlli vengono superati, crea i cookie:
function DataOk(opt)
{
... controlli (codice preesistente) ...
[Link] = "Nomen="+[Link];
[Link] = "PrimoCodice="+[Link];
[Link] = "SecondoCodice="+[Link];
return true;
}

L’oggetto DOM Document ha la proprietà cookie, che ospita tutti i cookie definiti nel documento; inizialmente
la proprietà è vuota, poi, dopo aver eseguito le istruzioni al termine della funzione DataOk, essa contiene le
tre coppie nome/valore.

Prima di tutto, indago la persistenza e la visibilità dei cookie; per ferlo, eseguo il seguente esperimento: entro
in [Link] e scrivo Nominativo = As, CodiceIniziale = 11 e CodiceFinale = 23, poi premo il button
Invia su MaskA: vengono visualizzati i libri degli autori il cui cognome comincia con As; premo il tasto di
ritorno a [Link], ignoro al momento i contenuti dei campi delle form, e torno alla home page; di qui,
scelgo un’altra pagina, ad esempio [Link], nella quale ho aggiunto un’istruzione atta a visualizzare i
cookie, come alert([Link]), ecco il risultato: Nomen=As; PrimoCodice=11; SecondoCodice=23.

Con ciò, i cookie sono persistenti, e visibili da tutte le pagine del sito; si può dimostrare facilmente che lo
scope dei cookie sopra definiti, sia per la persistenza, sia per la visibilità, è la sessione: aprendo una nuova
sessione (con l’apposita voce del menu del browser), la proprietà [Link] risulta vuota.

Utilizzo dei cookie per ripristinare i valori delle form.

Torno alla pagina [Link]: finora ho creato i cookie, ma non li ho usati.

Prima di tutto, scrivo una funzione JavaScript in grado di restituire il valore di un cookie del quale si conosce
il nome; la scrivo nella sezione <script> di <header> della pagina (che già ospita DataOk):
function FindValOfCookie(nome)
{
var target = nome +"=";
var ca = [Link](";");
for (var i=0;i<[Link];i++)
{
var c = ca[i].trim();
if ([Link](target) == 0)
return [Link]([Link],[Link]);
}
return "";
}

Il codice è autoesplicativo: invocandola con il nome di un cookie, ad esempio Nomen, se il cookie è stato
creato ne restituisce il valore, altrimenti, non trovandolo, restituisce una stringa vuota.

Di seguito alla definizione di MaskA, che resta invariata, aggiungo un blocco di codice JavaScript:
<script language="JavaScript">
var memo = FindValOfCookie("Nomen");
if (memo != "") [Link] = memo;
</script>

Il codice viene sempre eseguito; nel tag <form> di MaskA, il campo Nominativo riceve value = "", ma se
il cookie Nomen è già stato creato all’interno del codice di DataOk, allora il campo Nominativo riceve il valore
del cookie, nell’esempio As; se invece il cookie non è presente, il valore di Nominativo resta vuoto.

Aggiungo un analogo codice dopo la definizione di MaskB:

<script language="JavaScript">
var memo = FindValOfCookie("PrimoCodice");
if (memo != "") [Link] = memo;

pag. 159
Advanced Java rev. 1.0 Novembre 2012

memo = FindValOfCookie("SecondoCodice");
if (memo != "") [Link] = memo;
</script>

Con ciò, tornando alla pagina [Link] dopo una POST, non importa su quale delle due form, l’utente
ritrova i valori inseriti nei campi di entrambe le form.

Soluzione al problema dell’eccessiva persistenza.

La pagina [Link], così come l’ho realizzata, non soddisfa un requisito: quando la accedo dalla home
page non per la prima volta durante una sessione, i campi delle form non appaiono vuoti, come io vorrei, ma
mostrano i valori salvati nei cookie.

Il problema può essere facilmente risolto, a patto di saper distinguere tra una POST e un ingresso nella
pagina; allo scopo, aggiungo un’altra funzione JavaScript nella sezione <script> di <header>:
function isFirstAccess()
{
return ([Link]("[Link]") >= 0);
}

La proprietà referrer dell’oggetto document contiene il nome della pagina di provenienza: in caso di primo
ingresso, è la pagina [Link] (home page), mentre in caso di POST, [Link] è vuoto… questo,
almeno, è il comportamento di Internet Explorer.

Stabilito il criterio di distinzione tra ingresso nella pagina e POST, aggiungo la seguente funzione JavaScript,
sempre nella sezione <script> di <header>:
function InitMask()
{
if (isFirstAccess())
{
[Link] = "";
[Link] = "";
[Link] = "";
}
return;
}

La funzione InitMask dev’essere invocata subito dopo la fine del caricamento della pagina, perciò sull’evento
onload del tag <body>: <body bgcolor="white" onload="InitMask();">.

Ciò garantisce che, nel caso di ingresso, i campi delle form, che hanno ricevuto i valori contenuti nei cookie,
vengano reinizializzati: infatti, essi appaiono vuoti.

Come si è già detto, i cookie così creati su lato client hanno come scope (sia in visibilità, sia in persistenza)
la sessione.

Uso dei cookie originati da server.

Un caso d’uso assai frequente dei cookie è il seguente: un componente server, cioè un servizio web come
possono essere un servlet oppure una web service, crea un cookie e lo passa, nel messaggio di risposta, al
client che ha effettuato una richiesta; il cookie viene ricevuto dal client, che poi, ad ogni successiva richiesta,
lo ripassa automaticamente al server.

Un esempio di funzionalità protetta: GiudiziSuAutori.

Aggiungo al servlet Booklet la funzionalità che chiamo GiudiziSuAutori: il client invia al servlet una richiesta
in cui Funzione = GiudiziSuAutori, passando anche il parametro Nominativo; il servlet restituisce il giudizio
(se diponibile) per ciascun autore il cui cognome inizia col valore passato nel parametro Nominativo.

La funzionalità di per sé non è affatto complicata: nel progetto Booklet, aggiungo alla classe DAO il metodo
public static Giudiziodn[] giudiziAutoriByNome(String nomen); questo metodo accede,
nel database Libreria, la table MIXAUTORI in join con la table AUTORI per costruire nomi e cognomi.

Ecco il risultato della query, nel caso in cui il parametro nomen (ossia, il campo Nominativo) valga S:

pag. 160
Advanced Java rev. 1.0 Novembre 2012

AUTORE NOMINATIVO GIUDIZIO NOTE VOTO

1 Bob Shaw Eccellente Autore irlandese, geniale, scomparso a soli 65 anni 1000
16 Clifford D. Simak Bravo Autore dalla qualità non costante 700
25 Robert Sheckley Ottimo Autore cruciale nella SF, ove inventò il genere sociologico 925

Il tipo Giudiziodn, definito nel package dao del progetto Booklet, ha i campi definiti in accordo coi risultati
della query (anche se il primo campo si chiama codice, e non autore).

Tuttavia ho stabilito che la funzionalità GiudiziSuAutori sia protetta: quando il servlet ne riceve la richiesta,
prima di tutto verifica che il client abbia le giuste credenziali, cioè quelle di un critico letterario.

Il client deve inviare nella richiesta, oltre al parametro Nominativo, una coppia username/password
adeguata; il servlet estrae dalla richiesta i parametri Nickname e Password e li confronta con i contenuti della
(nuova) table CRITICI del database Libreria: se la coppia è presente nella table, il test è superato, altrimenti
il servlet risponde al client solamente con uno pseudorecord Giudiziodn, nel cui campo giudizio sta scritto
FORBIDDEN.

Se invece il test viene superato, allora il servlet invoca il metodo [Link] e passa la risposta al
client, inoltre nel messaggio di risposta il servlet passa al client il cookie Semaforo: verde. A questo punto, il
client è in possesso del cookie, e nelle successive richieste di tipo GiudiziSuAutori può accedere senza più
specificare la coppia Nickname/Password.

Modifiche al codice di Booklet.

Le modifiche sono tre: la nuova classe Giudiziodn, appartenente al package dao; due nuovi metodi per la
classe DAO: il già incontrato giudiziAutoriByNome, e il metodo isCritic – quest’ultimo è dichiarato come
public static boolean isCritic(String nic,String pass), il suo codice cerca nella table
CRITICI un record avente NICK = nic e PWD = pass, e restituisce true se e solo se esiste un record
siffatto; in ultimo, modifiche al metodo doGet della classe Maine, affinchè siano gestiti sia la nuova
funzionalità, sia i cookie. Nel seguito, analizzo in dettaglio le sole modifiche al metodo [Link].

La richiesta della nuova funzionalità ha la forma seguente, nella massima generalità:

Funzione=GiudiziSuAutore&Client=nomeClient&XML=y/n&Nominativo=nomen&Nickname=nic&Password=pass

I campi Funzione e Nominativo devono essere sempre presenti, mentre Client è opzionale; il campo XML
può essere assente, nel qual caso il codice si comporta come se fosse presente e avesse valore negativo; i
campi Nickname e Password possono o meno essere presenti.

Nel caso di Funzione = GiudiziSuAutori, il codice del metodo doGet verifica la presenza dei cookie, anzi la
presenza di un particolare cookie, cioè quello destinato al passaggio veloce:
Cookie[] cooks = [Link]();
boolean telePass = false;
if (cooks != null)
{
for (Cookie coo : cooks)
if ([Link]().matches("Semaforo") &&
[Link]().matches("verde"))
{
telePass = true;
break;
}
}

Poiché il cookie Semaforo: verde è creato dal servlet dopo che è avvenuto un accesso client corretto,
almeno una prima volta il test non sarà superato e quindi risulterà telePass = false.

Ecco il codice seguente:

if (!telePass)
{
String nic = [Link]("Nickname");
String pass = [Link]("Password");
if ((nic != null) && (pass != null) && ([Link]() > 0) &&

pag. 161
Advanced Java rev. 1.0 Novembre 2012

([Link]() > 0))

telePass = [Link](nic, pass);
}

Nel caso l’accesso veloce alla funzionalità non sia possibile, allora il codice ricava le credenziali d’accesso
alla funzionalità protetta, ossia la coppia Nickname e Password: se la coppia è presente e definita nella
richiesta, e se corrisponde alle credenziali di un critico letterario – ossia, se c’è un record della table CRITICI
che ha i campi NICK e PWD rispettivamente uguali a nic e pass,

Il valore finale di telePass, in assenza del cookie Semaforo: verde, dipende solamente dalla validità delle
credenziali; in presenza del cookie, telePass è vero e le credenziali non vengono affatto controllate.

In ogni caso, il codice prosegue:

if (telePass)
writable = [Link](cgn);
else
{
Giudiziodn[] agp = new Giudiziodn[1];
agp[0] = new Giudiziodn(0,"-","FORBIDDEN","???",0);
writable = agp;
}

Se telePass è vero, vengono reperiti (se presenti) i giudizi sugli autori il cui cognome inizia come cgn, ove
cgn è il valore (nomen) del parametro Nominativo; come per gli altri valori di Funzione, i dati vengono passati
nell’oggetto generico writable.

Se invece telePass è falso, allora viene generata una risposta d’errore, strutturalmente identica al caso
positivo, cioè un oggetto di tipo Giudiziodn[], ma con un solo item nel cui campo giudizio è scritto
FORBIDDEN (è responsabilità del client interpretare ciò come un errore d’accesso).

Se la risposta non è attesa in formato XML, l’oggetto writable viene scritto sul response output stream;
altrimenti, il codice prosegue formattando i dati binari contenuti in writable come un documento XML
(nell’esempio seguente, Nominativo = Si):
<?xml version='1.0' encoding='ISO-8859-1'?>
<?xml-stylesheet type='text/xsl' href='[Link]
<doc>
<GiudizioAutore>
<Codice>16</Codice>
<Nominativo>Clifford D. Simak</Nominativo>
<Giudizio>Bravo</Giudizio>
<Note>Autore dalla qualità non costante</Note>
<Voto>700</Voto>
</GiudizioAutore>
</doc>

Prima però di comporre il documento XML, che costituisce il body della risposta, il codice del metodo doGet
si preoccupa della creazione e del passaggio del cookie Semaforo: verde:
if ([Link]("GiudiziSuAutori") && (cooks == null)16)
{
Giudiziodn[] agp = (Giudiziodn[])writable;
if (([Link] == 0) || (!agp[0].[Link]("FORBIDDEN")))
{
Cookie cook = new Cookie("Semaforo","verde");
[Link](cook);
}
}

Il cookie viene creato, se già non esiste, e a patto che non mi trovi nel caso di accesso negato (è invece
accettabile la risposta senza dati, che si verifica quando per quella parte iniziale di cognome, nessun autore

16
Il test effettuato funziona correttamente solo se l’unico cookie previsto è Semaforo: verde; più in generale,
dovrei utilizzare un test più selettivo, ossia verificare, a fronte di cookie non null, che non sia già presente il
cookie Semaforo: verde.

pag. 162
Advanced Java rev. 1.0 Novembre 2012

reca un giudizio): il cookie è creato e aggiunto al messaggio di risposta, ove comparirà come una riga del
HTTP header, Set-Cookie: Semaforo=verde.

Esempio di pagina HTML che utilizza un cookie originato da server.

Riprendo la già studiata [Link], che utilizza il framework Ajax per accedere al servlet Booklet, e le
aggiungo qualche campo, in modo che possa passare più parametri al servlet.

Nel controllo HTML <select>, di nome Funzione, aggiungo l’opzione GiudiziSuAutori; aggiungo, nella
HTML table Fissa, a fianco della HTML textbox argo, un’altra HTML textbox argo2 e il controllo HTML di tipo
password, di nome pass; in questo modo, è possibile selezionare l’opzione GiudiziSuAutori nella tendina,
passare il nominativo (parte iniziale del cognome) entro argo, e – come risulta necessario almeno la prima
volta – passare anche le credenziali, cioè il nickname entro argo2 e la password entro pass.

Aggiungo alla funzione JavaScript CallServlet il codice necessario alla gestione del caso GiudiziSuAutori:
var conn = "[Link]
[Link]+"&Client=AjaxSync&XML=y";
... segue codice specifico per [Link] = "GiudiziSuAutori" ...
conn = conn + "&Nominativo="+[Link];
var body = "";
if ([Link] > 0) // suppongo di non avere il cookie
body += "&Nickname="+[Link]+"&Password="+[Link];
[Link]("POST",conn,false);
[Link]("Content-Type","application/x-www-form-
urlencoded");
[Link](body);

l’operatore può passare o meno Nickname servendosi del campo argo2: se non lo passa e il cookie non è
stato ancora ricevuto, riceverà un errore (FORBIDDEN); se invece lo passa e il cookie è già stato ricevuto,
allora Nickname e Password vengono semplicemente ignorati. Comunque, qui assumo che l’operatore abbia
inserito il nickname in argo2 e si tratti della prima richiesta alla funzionalità GiudiziSuAutori.

Infine, aggiungo a CallServlet il codice necessario per la corretta formattazione del documento XML,
utilizzando i nomi dei tag definiti in Booklet e adattando l’ampiezza delle celle alla grandezza dei valori.

Ecco il risultato dell’interrogazione:

pag. 163
Advanced Java rev. 1.0 Novembre 2012

Qui sopra viene mostrato il risultato dell’interrogazione: vengono mostrati tutti i giudizi presenti per gli autori il
cui cognome comincia con S. Come si vede, l’utente ha passato le credenziali.

A questo punto, il client riceve il cookie Semaforo: verde dal servlet; nelle successive interrogazioni non è più
necessario passare le credenziali, perché il client spedisce automaticamente il cookie al servlet.

Ecco il messaggio HTTP originato ripetendo l’interrogazione, coi campi argo2 e pass vuoti:
POST /Booklet/Answers?Funzione=GiudiziSuAutori&XML=y&Nominativo=S HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: user-pc
Content-Length: 0
Cache-Control: no-cache
Cookie: Semaforo=verde

La lunghezza del body è 0; dopo l’ultma riga dell’header, seguono due righe vuote. Si noti la presenza del
cookie, ricevuto dal servlet e automaticamente rimpallato ad ogni richiesta.

Scope, visibilità e modo d’impiego del cookie.

Lo scope del cookie originato dal servlet Booklet è la sessione: all’interno della stessa sessione in cui è stato
ricevuto il cookie dal servlet (a fronte di una richiesta di tipo GiudiziSuAutori), ogni pagina che invia una
richiesta a Booklet – non importa quale richiesta, automaticamente spedisce il cookie a Booklet.

Supponiamo che [Link] richieda GiudiziSuAutori senza avere il cookie, ma passando credenziali
corrette: oltre ai dati, la pagina riceve pure il cookie Semaforo: verde. Da questo momento in poi, ogni altra
pagina, o altro componente client come un applet, quando rivolge una qualsiasi richiesta a Booklet,
automaticamente passa il cookie.

Ad esempio, do all’applet BookletApplet la possibilità di inoltrare una richiesta GiudiziSuAutori: l’applet

prevede il passaggio del nominativo, ma non di nickname e password, quindi riceve una risposta non
FORBIDDEN solamente se nella stessa sessione è già stato ricevuto il cookie da [Link].

pag. 164
Advanced Java rev. 1.0 Novembre 2012

Ecco il messaggio in uscita dall’applet:

GET /Booklet/Answers?Funzione=GiudiziSuAutori&Nominativo=S HTTP/1.1
Cache-Control: no-cache
Host: user-pc
Cookie: Semaforo=verde

Come già detto, il passaggio del cookie avviene ogni volta che un componente client rivolge una qualsiasi
richiesta al servlet Booklet, ad esempio anche quando una pagina chiede la lista dei generi.

Terminata la sessione, il cookie perde validità, e in una nuova sessione, quando si accede alla funzionalità
GiudiziSuAutori, è necessario ripetere il passaggio delle credenziali.

pag. 165
Advanced Java rev. 1.0 Novembre 2012

Principali novità introdotte da Java 1.8.

Le principali novità introdotte da Java 1.8 sono tre: le espressioni lambda, i default method, gli stream; sono
anche molto importanti i nuovi metodi delle collezioni, come forEach e filter, che sfruttano espressioni
lambda e stream per compiere le cosiddette operazioni aggregate (gli stessi nuovi metodi delle collezioni
sono chiamati operazioni aggregate).

Un’altra novità, di interesse ma di minore importanza, è costituita dai method reterence.

Setup di Eclipse per l’uso di Java 1.8.

Prima di tutto, installo JDK 1.8, disponibile per Windows 7 (o superiore) ma non per XP.

Attualmente, l’ultima versione di Eclipse è Kepler SR2, tuttavia nativamente essa supporta Java 1.7 ma non
Java 1.8; affinchè sia possibile usare Java 1.8 nella IDE di Eclipse, bisogna installare un’apposita feature, in
sostanza un plugin chiamato “Eclipse JDT patch with Java 8 support”.

La via più semplice per installare la patch è l’uso della voce HelpEclipse Marketplace, che attiva il
marketplace client; sfogliando le liste dei vari tab del marketpkace client, si può trovare la feature indicata
come Java 8 support for Eclipse Kepler SR2: deve essere installata.

Fatto ciò, bisogna sincerarsi che, in ogni progetto che intenda servirsi di nuove feature come le espressioni
lambda, il compliance level del compilatore sia settato al valore 1.8; la via più semplice consiste nell’adottare
tale compliance level a livello di workspace: da un qualsiasi progetto, accedo (col tasto destro) a
PropertiesJava Compiler e di qui alla voce Configure Workspace Settings, e nella finestra successiva
scelgo 1.8 come compliance level del compilatore. Con ciò, ogni nuovo progetto nasce con compliance 1.8.

Le espressioni lambda.
A partire dalla versione 1.8, Java fornisce supporto al calcolo funzionale mediante le espressioni lambda.
Queste sono così chiamate in quanto conformi al formalismo del calcolo lambda.

Il progetto Lambda.
Creo il Java project Lambda, che fornisce un’introduzione euristica all’uso delle espressioni lambda. È un
progetto molto semplice, consistente di due package, app che contiene le classi Maine (dotata di metodo
main) e Agente, e landa, contenente l’interfaccia XFace, preposta alla costruzione delle espressioni lambda.

Definizione di interfaccia funzionale.

Si dice che un’interfaccia è un’interfaccia funzionale quando essa consiste di un solo metodo.

Ecco il caso di XFace:

public interface XFace
{
public String opex(String str,int n);
}

In un’interfaccia funzionale, è possibile usare ogni tipo, primitivo o costruito (ad esempio [Link]), sia
come parametro di passaggio, sia come tipo di ritorno; anche void è ammissibile.

Uso dell’interfaccia funzionale per costruire espressioni lambda.

Il metodo main della classe Maine istanzia la classe Agente, recupera eventuali parametri di passaggio, e
chiama i metodi dell’istanza di Agente:
String t = "";
int q = 0;
Agente agente = new Agente();
if ([Link] > 0)
{
t = args[0];
q = [Link](args[1]);
}
[Link]([Link](t, q));

pag. 166
Advanced Java rev. 1.0 Novembre 2012

[Link]([Link](t, q));
[Link]([Link](t, q));

Ecco il codice del metodo adder della classe Agente, che implementa un’espressione lambda:
public String adder(String txt,int ad)
{
[Link]("metodo adder#");
XFace xFace = (String t,int i)->
{
if (i > 15) return t+[Link](i);
StringBuilder sb = new StringBuilder(t);
for (int k=0;k<[Link]();k++)
[Link](k, (char)([Link](k)+i));
return [Link]();
};
return [Link](txt, ad);
}

Premetto che l’identità di signature tra il metodo adder e il metodo dell’interfaccia funzionale non è
necessaria, è venuta fuori per comodità e per caso.

L’espressione lambda è costituita dalle righe successive alla prima nel corpo dle metodo, con l’eccezione
dell’ultima; la sua struttura è la seguente: Interfaccia interf = (parameter list)-> { body }.

Ci sono alcune regole da rispettare:

a) l’interfaccia Interfaccia dev’essere un’interfaccia funzionale
b) la parameter list dev’essere identica a quella del metodo di Interfaccia (a parte i nomi dei parametri,
che possono essere diversi)
c) il body è arbitrario, ma deve restituire lo stesso tipo del tipo di ritorno del metodo di Interfaccia.

Se l’interfaccia funzionale ha un metodo senza parametri, allora parameter list è assente, ma devono restare
le parentesi tonde, cioè Interfaccia interf = ()-> { body }.

Se il metodo dell’interfaccia funzionale non ha tipo di ritorno, cioè è definito void, allora il body non può
contenere istruzioni del tipo return x, ma solo return, oppure nessuna.

L’ultima istruzione del metodo adder è importante perché mostra come utilizzare l’espressione lambda,
tuttavia non presenta caratteristiche di rilievo.

Gli altri due metodi dell’interfaccia funzionale XFace, adderPlus e hRev, sono implementazioni (o funzioni)
distinte, ma obbediscono alle stesse regole generali.

Rapporti di visibilità tra body di un’espressione lambda ed enclosing scope.

Una variabile definita localmente al body di un’espressione lambda non è visibile nell’enclosing scope,
mentre una variabile definita nell’enclosing scope è visibile, ma non alterabile, nel codice del body
dell’espressione lambda.

Aggiungo il metodo demo alla classe Agente:

public int demo(String txt,int ad)
{
int v = 3;
[Link]("metodo demo#");
XFace xFace = (String t,int i)->
{
int sum = v + i + [Link]();
return t+"_"+sum;
};
[Link]([Link](txt, ad)+"#");
return v*v;
}

pag. 167
Advanced Java rev. 1.0 Novembre 2012

Nel metodo main di Maine, aggiungo la riga [Link]([Link](t,q)); passando ad

esempio t=Virgilio e q=11, l’output è metodo demo#Virgilio_22#9: la variabile v, definita nell’enclosing scope,
risulta correttamente visibile.

Se tentassi di accedere la variabile sum, definita nel body dell’espressione lambda, al di fuori del body,
otterrei un errore di compilazione, la variabile sum risulterebbe non visibile.

La variabile v non è dichiarata final, tuttavia è come se lo fosse, si dice che v è effectively final; infatti, se
provo ad alterarne il valore dopo averla definita, in qualsiasi parte del codice del metodo – nel body
dell’espressione lambda, ma anche nell’enclosing scope, sia prima sia dopo il body – ottengo un errore di
compilazione. In sostanza, posso compilare solo se la variabile si comporta come final.

Nota Bene: se una variabile è dichiarata non nell’enclosing scope del body dell’espressione lambda, ma più
esternamente, ad esempio come membro della classe cui appartiene il metodo, allora nel body
dell’espressione lambda è possibile non solo usarla, ma anche modificarne il valore.

Scrittura semplificata di espressioni lambda.

La parameter list può essere semplificata omettendo le dichiarazioni dei tipi dei parametri; ad esempio, nel
metodo demo avrei potuto scrivere l’espressione lambda come segue:
XFace xFace = (t,i)->
{
int sum = v + i + [Link]();
return t+"_"+sum;
};

i tipi dei parametri vengono inferiti dal compilatore, in base all’unico metodo (non default, non statico)
dell’interfaccia funzionale (XFace) usata nella definizione e costruzione dell’espressione lambda.

Se il metodo dell’interfaccia funzionale ha un solo parametro, ad esempio R metodo(T x), allora la parameter
list nelle espressioni lambda si sempifica ulteriormente: Interfaccia iFace = x->{ body }.

Passaggio parametrico di espressioni lambda.

Le espressioni lambda possono essere passate come parametri, in virtù della loro natura di codice trattato
come dati. Considero un esempio, di natura fortemente accademica ma completo.

Creo due interfacce funzionali, XFactor e XBino (entrambe appartenenti al package landa):
public interface XFactor public interface XBino
{ {
long fattoriale(int n); long binomio(int a,int b,int c,String o);
} }

Aggiungo il metodo (pubblico) Comparatore alla classe Agente, che viene chiamato dal metodo main di
Maine: il metodo Comparatore effettua il rapporto tra n! e (a+b)c, nel caso o non inizi col carattere –, oppure
tra n! e (a–b)c, nel caso o inizi col carattere –; in base al valore del rapporto, fornisce una scritta informativa.

Tuttavia ipotizzo che il metodo Comparatore riceva da Maine non solo i valori, ma anche gli algoritmi di
calcolo, sia del fattoriale, sia della potenza del binomio; ecco il codice nel metodo main di Maine:
[Link]([Link](q,
N->
{
long l = 1;
if (N < 0) l = -1; else for (int i=1;i<=N;i++) l *= i;
return l;
},
r,s,u,t,
(A,B,C,O)->
{
if ([Link]("-")) return (long) [Link](A-B,C);
else return (long) [Link](A+B,C);
}));

ed ecco il codice del metodo Comparatore della classe Agente:

pag. 168
Advanced Java rev. 1.0 Novembre 2012

public String Comparatore(int n,XFactor xf,int a,int b,int c,String

o,XBino xb)
{
[Link]("metodo comparatore#");
double ratio = (double)[Link](n)/(double)[Link](a, b, c,
o);
String s = "";
if (ratio >= 10) return "Frazione >> 1";
else if ((ratio < 10) && (ratio > 1.01)) return "Frazione > 1";
else if ((ratio <= 1.01) && (ratio > 1)) return "Frazione ~> 1";
else if (ratio == 1) return "Bingo";
else if ((ratio < 1) && (ratio >= 0.99)) return "Frazione ~< 1";
else if ((ratio < 0.99) && (ratio > 0.1)) return "Frazione < 1";
else return "Frazione << 1";
}

Nel caso d’uso seguente, ho passato al codice del metodo main (da riga di comando) i valori q = 5, r = 7, s =
4, u = 2, t = +:
quindi n! = 5! = 120, (a+b)c = (7+4)2
= 121, perciò ratio = 0,9917 e
quindi 0.99 < ratio < 1, il che spiega
la scritta in output (frazione quasi
uguale a 1 per difetto).

Nelle due espressioni lambda scritte nel codice del metodo main, ho utilizzato la notazione abbreviata della
parameter list in ambo i casi, ma avrei potuto utilizzare la notazione estesa.

La vecchia alternativa alle espressioni lambda: le classi anonime.

Prima della versione 1.8, Java permetteva comunque l’implementazione di interfacce senza dover passare
attraverso la definizione esplicita di classi; la metodologia, che conserva tuttora validità, è quella dell’utilizzo
di classi anonime. Tale metodologia viene correntemente usata per definire i event handler dei button.

Considero l’interfaccia DoubleFace, contenuta nel package oldStuff del progetto Lambda:
public interface DoubleFace
{
public long bino(int a,int b);
public String nTOs(long v);
}

L’interfaccia ha due metodi, perciò non è un’interfaccia funzionale e quindi non può essere utilizzata per
costruire espressioni lambda. Tuttavia non è necessario creare una classe che la implementi, è possibile
utilizzare la tecnica della classe anonima.

Aggiungo alla classe Agente il metodo handleDuo:

public String handleDuo(String txt,int ad)
{
[Link]("metodo handleDuo#");
DoubleFace df = new DoubleFace()
{
@Override
public long bino(int a, int b)
{
return (long) [Link](a, b);
}
@Override
public String nTOs(long v)
{
return [Link](v, true);
}

pag. 169
Advanced Java rev. 1.0 Novembre 2012

};
return txt+"_"+[Link]([Link](ad, 3))+"_"+[Link](ad);
}

La costruzione della classe anonima è quella comunemente usata per definire event handler dei controlli
Swing o SWT. Anche qui vale la regola di visibilità delle variabili rispetto all’enclosing scope che racchiude la
classe anonima.

Aggiungendo al metodo main della classe Maine la riga

[Link]([Link](t,q)), e passando i valori t = Virgilio e q = 11, ottengo
l’output metodo handleDuo#Virgilio_1331_B.

A basso livello, la classe anonima viene trattata come una sottoclasse della classe ospite; nel mio esempio,
la classe ospite è [Link], e la classe anonima ha nome [Link]$1.

Notare: l’obbligo delle interfacce funzionali di essere monometodo sembra essere una notevole limitazione
all’utilizzo delle espressioni lambda rispetto all’uso delle classi anonime; ma, come si vedrà nei successivi
paragrafi, questa limitazione viene assai ridotta da un’altra nuova caratteristica di Java 1.8, i default method.

I default method.
I default method, detti anche defender method, sono una nuova caratteristica di Java 1.8, che permette di
scrivere codice nei metodi dichiarati in un’interfaccia; grazie ai default method, le interfacce diventano di fatto
simili alle classi astratte.

Dichiarazione e utilizzo dei default method.

Considero l’interfaccia XXFace, appartenente al package landa come XFace, avente lo stesso metodo opex
di XFace, e in più dotata di un default method (si noti la keyword):
public interface XXFace
{
public String opex(String str,int n);
default public String nTOs(long v)
{
return [Link](v, true);
};
}

Il metodo nTOs è non solo dichiarato, ma anche già codificato all’interno dell’interfaccia XXFace; suppongo
di creare (nel package mix del progetto Lambda) una classe XXClass che implementi l’interfaccia XXFace:
public class XXClass implements XXFace
{
@Override
public String opex(String str, int n)
{
return "XX:"+str+"_"+[Link](n);
}
}

Si noti che non è stato necessario implementare il default method nTOs.

Aggiungo il codice seguente nel metodo main di Maine:

XXClass xx = new XXClass();
[Link]("metodo [Link]#"+[Link](t, q));
[Link]("metodo [Link]#"+[Link](q));

passando t = Virgilio e q = 12000, ecco l’output ottenuto:

metodo [Link]#XX:Virgilio_12000
metodo [Link]#2EE0

è evidente che l’istanza di XXClass ha utilizzato il codice dell’interfaccia da essa implementata.

La classe XXClass può comunque reimplementare il default method:

public class XXClass implements XXFace

pag. 170
Advanced Java rev. 1.0 Novembre 2012

{
@Override
public String opex(String str, int n)
{
return "XX:"+str+"_"+[Link](n);
}
@Override
public String nTOs(long n)
{
String r = [Link](n);
return [Link]();
}
}

È molto interessante la notazione utilizzata per recuperare il default method dell’interfaccia che la classe sta
implementando: alla keyword super ho dovuto prefissare il nome dell’interfaccia (pena errori di
compilazione), il che ha senso tenendo conto che una classe può implementare più interfacce, le quali
potrebbero dichiarare metodi omonimi.

Adesso rieseguo il codice del metodo main di Maine, sempre con t = Virgilio e q = 12000, ed ecco l’output:
metodo [Link]#XX:Virgilio_12000
metodo [Link]#2ee0

Uso di metodi statici nelle interfacce.

Con la versione 1.8, è possibile definire anche metodi statici nelle interfacce; si comportano come i metodi
statici di una classe.

Come esempio, aggiungo all’interfaccia XXFace il seguente metodo statico:

static long factor(int k)
{
long r = 1;
if (k < 0) r = -1; else for (int i=1;i<=k;i++) r *= i;
return r;
}

Per provare il codice, aggiungo al metodo main di Maine la seguente riga:

[Link]("metodo [Link]#"+[Link](q));

passando q = 7, ottengo metodo [Link]#5040.

Sinergia tra default method ed espressioni lambda.

La limitazione più seria delle espressioni lambda sta nella necessità, per il loro impiego, di interfacce
funzionali, ossia interfacce aventi un solo metodo, quindi “scomode” per utilizzi diversi dalle espressioni
lambda. Tuttavia la possibilità di definire default method, e in misura minore metodi statici, riduce
grandemente la difficoltà.

Mi servo di un esempio per mostrare la sinergia tra espressioni lambda e default method.

L’interfaccia XFace ha il solo metodo opex; l’interfaccia XXFace ha il metodo opex come XFace, inoltre ha
altri due metodi, il default method nTOs e il metodo statico factor. Più elegantemente, apporto un
cambiamento al progetto lambda: lascio XFace invariata, ma rendo XXFace estensione di XFace.

Ecco come si presenta XXFace:

public interface XXFace extends XFace
{
default public String nTOs(long v)
{
return [Link](v, true);
};
static long factor(int k)
{
long r = 1;

pag. 171
Advanced Java rev. 1.0 Novembre 2012

if (k < 0) r = -1; else for (int i=1;i<=k;i++) r *= i;

return r;
}
}

Creo il metodo smart della classe Agente, che costruisce ed usa la stessa espressione lambda già vista per
il metodo [Link], ma si serve anche degli altri metodi di XXFace:
public String smart(String txt,int ad)
{
[Link]("metodo smart#");
XXFace xxFace = (String t,int i)->
{
if (i > 15) return t+[Link](i);
StringBuilder sb = new StringBuilder(t);
for (int k=0;k<[Link]();k++)
[Link](k, (char)([Link](k)+i));
return [Link]();
};
return [Link](txt,ad)+"_"+[Link](ad)
+"_"+[Link](ad);
}

Aggiungo al main di Maine l’istruzione [Link]([Link](t,q)); passando t =

abc e q = 14, ottengo l’output metodo smart#opq_E_87178291200.

Posso creare una classe (eventualmente, anche anonima) che implementi l’ìnterfaccia XXFace, continuando
anche ad usare l’interfaccia per definire espressioni lambda.

In sintesi, un’interfaccia funzionale può avere più di un metodo, a patto che i metodi distinti da quello usato
per costruire le espressioni lambda siano default method oppure metodi statici; in questo caso, quando si
utilizza l’interfaccia per costruire un’espressione lambda, bisogna usare la signature del metodo non default
e non statico. Con ciò, se provo a utilizzare l’interfaccia XXFace usando la signature del default method
nTOs, ottengo un errore di compilazione, in quanto il compilatore si aspetta l’uso del metodo opex.

Un’interfaccia avente un solo metodo, definito però default method oppure statico, non è un’interfaccia
funzionale e non può essere usata per costruire espressioni lambda.

Cos’è un oggetto di tipo Stream.

In generale, uno stream è un flusso di dati; Java prevede moltissime classi che gestiscono stream, intesi
come flussi di dati, distinti sempre in flussi in ingresso, input stream, e flussi in uscita, output stream: si tratta
di classi come ByteArrayInputStream e ByteArrayOutputStream, ObjectInputStream e ObjectOutputStream,
PrintStream, tutte appartenenti al package [Link]; oppure classi più specializzate, come JarInputStream e
JarOutputStream, appartenenti al package [Link].

Programmaticamente, ogni classe che rappresenta un flusso di dati (stream) in ingresso, discende dalla
classe [Link]; ogni classe che rappresenta un flusso di dati (stream) in uscita, discende dalla
classe [Link].

Tutto ciò continua a valere in Java 1.8, ove però compare un package, [Link], assente in Java 1.7;
questo package contiene l’interfaccia Stream<T>, che rappresenta un concetto di stream un po’ diverso, ma
ancora analogo al concetto tradizionale di stream come flusso di dati. Una definizione migliore di stream
verrà fornita nel seguito.

Relazioni tra collezioni, operazioni aggregate e stream.

In Java 1.7, il framework di classi Java prevede l’interfaccia [Link]<T>; questa interfaccia, che ha
il solo metodo iterator, permette ad ogni classe che la implementa di essere oggetto dello statement foreach.

Tra le varie interfacce che estendono Iterable, c’è [Link]<T>: programmaticamente, le collezioni
sono tutte le classi che implementano Collection<T>; di conseguenza, le collezioni hanno il metodo iterator e
possono essere oggetto dello statement foreach.

pag. 172
Advanced Java rev. 1.0 Novembre 2012

Con Java 1.8, l’interfaccia Iterable<T> si arricchisce: oltre a iterator, essa prevede i metodi default forEach e
spliterator; per il momento, ignoro spliterator. Di conseguenza, le collezioni hanno il metodo forEach.

Sempre con Java 1.8, l’interfaccia Collection<T> si arricchisce dei metodi default stream e parallelStream,
che restitcuiscono un oggetto di tipo Stream<T>: una collezione Coll<T>, chiamando il metodo stream,
restituisce un oggetto di tipo Stream<T>, ossia una sequenza di oggetti di tipo T costituita dagli elementi
presenti nella collezione Coll<T> al momento della chiamata.

Nel seguito si chiarirà la differenza tra uno stream sequenziale, quale è lo stream resituito da
Coll<T>.stream, e uno stream parallelo, quale è Coll<T>.parallelStream; per il momento, limito il mio
interesse a stream sequenziali.

Programmaticamente, uno stream è una classe che implementa l’interfaccia Stream; si può però dare una
definizione più esplicativa del concetto di stream: uno stream rappresentato da Stream<T> è una sequenza
(un flusso) di elementi di tipo T, che supporta operazioni aggregate.

Le operazioni aggregate avvengono solo sequenzialmente se lo stream è sequenziale, mentre se lo stream

è parallelo, le operazioni aggregate possono avvenire sia sequenzialmente sia in parallelo.

Le operazioni aggregate sono possibili solamente su flussi cioè su stream, e sono definite come metodi in
Stream<T>; essenzialmente sono tre: filter, map, forEach; sono operazioni aggregate anche alcune
specializzazioni delle tre precedenti, ad esempio mapToInt oppure forEachOrdered.

Non confondere il metodo forEach della collezione con il metodo forEach dello stream.
Una qualsiasi classe collezione, ad esempio Vector<T>, ha il metodo forEach, in quanto implementa
l’interfaccia Collection<T>, che eredita tale metodo dall’interfaccia Iterable<T>; inoltre la classe collezione ha
il metodo stream, il quale ritorna un oggetto di tipo Stream costituito da tutti gli elementi della collezione, ed
anche l’interfaccia Stream ha il metodo forEach.

Con ciò, data ad esempio la collezione vx di tipo Vector<Complex>, è possibile scrivere l’istruzione
[Link](x -> [Link]()), oppure [Link]().forEach(x -> [Link]()).
L’effetto delle due istruzioni è lo stesso: tutti gli elementi del vettore vx vengono coniugati. Tuttavia sarebbe
sbagliato identificare le due istruzioni.

Il metodo forEach di un oggetto di tipo Stream è una vera operazione aggregata, mentre il metodo forEach
della classe collezione non lo è: nell’interfaccia Stream, il metodo forEach è definito come un semplice
instance method, void forEach(Consumer<? super T> action); nell’interfaccia Collection, il metodo
forEach è definito come default void forEach(Consumer<? super T> action), e
l’implementazione default esegue l’azione su ogni elemento della collezione utilizzando un ciclo foreach.

Principali caratteristiche delle operazioni aggregate.

Le operazioni aggregate hanno natura olistica, ossia avvengono come un’unica azione coinvolgente tutti gli
elementi della collezione (o dello stream); questa caratteristica delle operazioni aggregate è particolarmente
evidente quando si paragona l’operazione aggregata forEach con il ciclo foreach: nel secondo, l’iterazione è
esterna ossia controllata dal codice applicativo, mentre nelle operazioni aggregate l’iterazione è interna ossia
determinata completamente dal JDK.

Mentre i cicli come foreach operano sempre e soltanto sequenzialmente, le operazioni aggregate possono
anche operare parallelamente: ciò accade quando lo stream sul quale avvengono è parallelo, anche se non
è sempre detto che, dato uno stream parallelo, le operazioni aggregate eseguano parallelamente.

Operazioni aggregate intermedie e parallele.

Un’operazione aggregata si dice intermedia quando, agendo su un certo stream, produce un nuovo stream;
è il caso di operazioni come filter e map. L’operazione si dice invece terminale quando il suo risultato non è
uno stream, ma un valore, oppure nessun risultato (void), come nel caso di forEach.

Come esempio, considero il metodo filtraComplessi della classe Agente:

public void filtraComplessi(int u)
{
Vector<Complex> vx = new Vector<Complex>();
for (int i=1;i<=u;i++) [Link](new Complex(i,i+1));
Stream<Complex> sx = [Link]();

pag. 173
Advanced Java rev. 1.0 Novembre 2012

Stream<Complex> sxf = [Link](v ->

{
double m = [Link]();
return (m - (int)m == 0);
});
[Link](v -> [Link](v + " ha modulo quadrato"));
}

Supponiamo che il metodo sia stato invocato da [Link], con u = 20: il vettore vx contiene 20 numeri
complessi, 1+2i, 2+3i, e così via fino a 20+21i.

L’istruzione [Link]() restituisce un oggetto sx di tipo Stream<Complex>, uno stream coi 20 numeri
complessi. Agire sugli elementi del vettore o su quelli dello stream dà gli stessi risultati, dato che essi fanno
riferimento agli stessi oggetti, cambia solo il modo di referenziarli.

La prima operazione aggregata è filter: applicata allo stream sx, essa genera lo stream sxf, ancora di tipo
Stream<Complex>, ma riguardante i soli numeri complessi, tra i 20 originari, aventi modulo il cui quadrato
sia intero – si tratta di 3+4i, che ha modulo al quadrato 16 = 42, e 20+21i, di modulo al quadrato 841 = 292.

Segue l’operazione aggregata forEach, applicata al nuovo stream sxf, che stampa i due numeri complessi:
3+4i ha modulo quadrato
20+21i ha modulo quadrato

Osservazione importante: una volta che un’operazione aggregata è stata eseguita, il riferimento simbolico
allo stream diventa inutilizzabile.

Ad esempio, riprendo il codice precedente: dopo aver applicato il primo filtro e ottenuto sxf, provo ad
applicare un nuovo filtro sullo stream referenziato da sx, come segue:
Stream<Complex> sx = [Link]();
Stream<Complex> sxf = [Link](v ->
{ ... });
Stream<Complex> sx2 = [Link](v -> [Link]() > 3);

il primo filtro genera, a partire da sx, uno stream referenziato come sxf costituito dai due numeri complessi
3+4i e 20+21i; il secondo filtro si applica ancora a sx, che si suppone sia rimasto invariato e quindi
contenente i 20 complessi iniziali, e dovrebbe generare lo stream sx2 contenente i soli complessi aventi
parte reale > 3.

Quando lancio il programma, si verifica un’eccezione appena viene tentata l’esecuzione del secondo filtro:
stream has already been operated upon or closed.

Pipeline di operazioni aggregate.

Riprendo il metodo filtraComplessi della classe Agente, imponendo che vengano individuati tutti i numeri
complessi, nel range stabilito da u, il cui modulo quadrato sia intero e la cui parte reale sia maggiore di un
certo valore L; tuttavia, come ulteriore complicazione, voglio che venga mostrato non il numero complesso
originario, bensì il suo coniugato (che, ovviamente, ha lo stesso modulo).

Ecco il codice del nuovo metodo filtraComplessi:

public void filtraComplessi(int u,int L)
{
[Link]("FiltraComplessi#");
Vector<Complex> vx = new Vector<Complex>();
for (int i=1;i<=u;i++) [Link](new Complex(i,i+1));
[Link]()
.filter(v ->
{
double m = [Link]();
return (m - (int)m == 0);
})
.filter(v -> [Link]() > L)
.map(v ->
{

pag. 174
Advanced Java rev. 1.0 Novembre 2012

[Link]();
return v;
})
.forEach(v -> [Link](v + " ha modulo quadrato"));
}

Se u = 20 e L = 3, il risultato è 20-21i ha modulo quadrato, il che è corretto (3+4i è stato scartato).

Passando invece u = 1000 e L = 100, trovo:

119-120i ha modulo quadrato
696-697i ha modulo quadrato
qui sono stati scartati 3+4i e 20+21i.

Premesso che le prime istruzioni si limitano a caricare i dati nel vettore, è molto interessante notare come
tutto il lavoro restante sia compiuto da un’unica, lunga istruzione, costituente un buon esempio di pipeline di
operazioni aggregate.

In generale, una pipeline consiste di uno stream sul quale agire (qui, [Link]), un certo numero di
operazioni intermedie (qui, tre: due filter e un map; potrebbero anche essere zero, cioè nessuna operazione
intermedia), e al più un’operazione terminale (qui, forEach); quest’ultima, se presente, chiude la pipeline.

L’operazione terminale non è sempre presente, e in questo caso la pipeline restituisce uno stream,
possibilmente con elementi di tipo diverso dal tipo dello stream di partenza.

Nella precedente pipeline, se avessi omesso il forEach finale, avrei ottenuto uno stream di tipo
Stream<Complex>; considero una forma un po’ modificata dello stesso codice:
Stream<String> ss = [Link]()
.filter(v ->
{
double m = [Link]();
return (m - (int)m == 0);
})
.filter(v -> [Link]() > L)
.map(v ->
{
[Link]();
return v + " ha quadrato del modulo intero";
});

in questo caso l’ultima operazione della pipeline è intermedia, trattandosi di map; in base al tipo di ritorno
dell’espressione lambda utilizzata in map, ciò che viene restituito è uno stream di stringhe.

Stream nativi.
L’interfaccia Stream è generica, ma oltre ad essa esistono interfacce specializzate, da utilizzarsi quando gli
elementi dello stream appartengono a certi tipi primitivi di dati: appartengono al package [Link] le
tre interfacce DoubelStream, IntStream e LongStream.

Considero un esempio concreto, fornito dal metodo mediaComplessi della classe Agente:
public void mediaComplessi(int u)
{
Vector<Complex> vx = new Vector<Complex>();
for (int i=1;i<=u;i++) [Link](new Complex(i,i+1));
OptionalDouble mReal = [Link]()
.mapToDouble(v -> [Link]())
.average();
OptionalDouble mImg = [Link]()
.mapToDouble(v -> [Link]())
.average();
Complex mcx = new Complex([Link](),[Link]());
[Link]("Complesso medio = "+mcx);
}

pag. 175
Advanced Java rev. 1.0 Novembre 2012

Scopo del metodo è, data una certa sequenza di numeri complessi, trovarne la media (come media di una
successione di numeri complessi, intendo il numero complesso avente come parte reale la media aritmetica
delle parti reali dei complessi appartenenti alla sequenza, e analogamente per la parte immaginaria).

Le due prime righe di codice creano il vettore vx ospite e lo popolano con u numeri complessi, poi segue
l’istruzione che calcola la parte reale della media, si tratta di una pipeline in cui lo stream oggetto è
[Link], che è di tipo Stream<Complex>; l’interfaccia Stream ha il metodo mapToDouble, specializzato nel
generare un flusso di double.
Per esteso, senza pipeline, sarebbe: DoubleStream ds = [Link]().mapToDouble(v-
>[Link]())
ove si ottiene uno stream di dati native, di tipo double, descrivibile come DoubleStream ma non come
Stream<Double>17, essendo quest’ultimo uno stream di oggetti e non di dati primitivi.

L’interfaccia DoubleStream ha il metodo average, un’operazione terminale: applicata a uno stream,

restituisce un valore non stream, un oggetto di tipo OptionalDouble; il metodo average è assente
nell’interfaccia Stream.

Il metodo average calcola la media aritmetica dei dati di tipo double, e restituisce un oggetto di classe
OptionalDouble; questa classe è stata introdotta in Java 1.8, essa è riguardabile come un contenitore
(container) che può contenere un valore di tipo double oppure essere vuoto.

L’oggetto di tipo OptionalDouble ha metodi appositi per appurare se un valore è presente; qui non vengono
usati, siccome do per scontato che sia u > 0. Posto che un valore sia presente, esso è recuperabile
mediante il metodo getAsDouble.

Ordinamento degli elementi di uno stream.

L’interfaccia Stream<T> ha due metodi di ordinamento:
Stream<T> sorted()
Stream<T> sorted(Comparator<? super T> comparator)

Entrambi i metodi hanno lo scopo di ordinare gli elementi, di tipo T, dello stream; il primo utilizza il criterio dì
ordinamento proprio del tipo T, mentre il secondo utilizza un criterio di comparazione esterno.

Come esempio, considero il metodo ordinaComplessi della classe Agente:

public void ordinaComplessi(int u)
{
Vector<Complex> vx = new Vector<Complex>();
Random rnd = new Random();
IntStream iStream = [Link](1,100);
OfInt ite = [Link]();
for (int i=0;i < u;i++) [Link](new Complex([Link](),[Link]()));
[Link]();
[Link]("Sequenza iniziale");
[Link](v -> [Link](v));
[Link]("Sequenza ordinata");
Stream<Complex> sord = [Link]().sorted();
[Link](v -> [Link](v));
}

È interessante lo stratagemma utilizzato per caricare i dati entro il vettore che funge da contenitore dei
numeri complessi.

Con Java 1.8, la classe Random è stata dotata di metodi che generano flussi (stream) infiniti di dati primitivi
– i metodi sono ints, longs, doubles; qui ho utilizzato lo stream di interi randomici, iStream, di tipo IntStream:
la parametrizzazione scelta garantisce che gli interi assumano valori compresi tra 1 e 99.

Recupero l’iteratore sullo stream, ite di tipo [Link],OfInt, quest’ultima è un’interfaccia che
rappresenta un iteratore su valori interi; il metodo next dell’iteratore restituisce l’intero (randomico) letto dal
flusso, me ne servo per generare u numeri complessi da immagazzinare nel vettore vx.

17
La notazione Stream<double> genera un errore di compilazione.

pag. 176
Advanced Java rev. 1.0 Novembre 2012

L’esecuzione dell’istruzione di ordinamento causa un errore (eccezione), perché Complex non è un tipo
ordinato; se voglio usare il metodo sorted nella sua forma più semplice, devo rendere Complex ordinato.

Programmaticamente, il tipo Complex deve implementare l’interfaccia [Link]:

public class Complex implements Serializable,Comparable<Complex>
{
... codice preesistente ...
@Override
public int compareTo(Complex o)
{
if (module() < [Link]()) return -1;
if (module() > [Link]()) return 1;
return 0;
}
}

Come criterio di comparazione tra due numeri complessi, ho utilizzato il confronto tra i loro moduli, che,
essendo numeri reali, sono immediatamente comparabili.

Rigenero la libreria LibJar/[Link], ricreo [Link] e rieseguo l’applicazione con u = 10:

Sequenza iniziale Sequenza ordinata
4 + 90i 20 + 41i
91 + i 24 + 65i
20 + 41i 1 + 78i
18 + 79i 21 + 77i
43 + 71i 18 + 79i
21 + 77i 43 + 71i
58 + 63i 58 + 63i
1 + 78i 48 + 72i
24 + 65i 4 + 90i
48 + 72i 91 + i

L’ordinamento ha funzionato.

Caso di ordinamento sovraimpresso.

Usando la seconda forma del metodo sorted, non è necessario che la classe T, propria degli elementi dello
stream Stream<T>, sia ordinata. Ciò è spesso utile, in quanto molte classi non sono ordinate, oppure, posto
che lo siano, si vuole passare un particolare criterio di ordinamento diverso da quello proprio della classe T.

Come esempio, espongo il metodo ordinaPersone della classe Agente: il metodo prima crea il vettore px, di
tipo Vector<Persona>, ove [Link] è una classe della libreria LibJar/[Link], avente il campo intero
matricola pubblico, e altri due campi di tipo stringa, nome e cognome; la classe Persona non è ordinata.

Aggiungo al vettore px alcuni elementi, uno dopo l’altro, con le matricole disposte disordinatamente; voglio
ricavare (e stampare) uno stream di tipo Stream<Persona> ordinato per matricole crescenti. Ecco il codice:
Stream<Persona> sord = [Link]().sorted((p1,p2) ->
{
if ([Link] < [Link]) return -1;
if ([Link] > [Link]) return 1;
return 0;
});
[Link](v -> [Link](v));

ho usato il metodo sorted nella sua seconda forma, passandogli un’espressione lambda congrua con
l’interfaccia [Link]<T>, qui T è Persona.

L’interfaccia Comparator<T> è un’interfaccia funzionale, il cui solo metodo (non default e non statico, e con
l’esclusione di equals ereditato da Object) è int compare(T t1,T t2), l’espressione lambda di sopra è
una sua semplice implementazione. Ecco il risultato:

Dati presenti nel vettore Stampa dei dati ordinati

915, Virgilio, Ravagli 1, Enrico, Albareto

pag. 177
Advanced Java rev. 1.0 Novembre 2012

1, Enrico, Albareto 900, Mariangela, Malpeli

914, Adriano, Aicardi 914, Adriano, Aicardi
1000, Bruno, Saccomanno 915, Virgilio, Ravagli
900, Mariangela, Malpeli 1000, Bruno, Saccomanno

L’ordinamento ha funzionato.

L’ordinamento nella collezione e nello stream associato.

Dato il vettore vx di tipo Vector<T>, il suo stream associato è sx = [Link](), di tipo Stream<T>; vx e lo
stream sx contengono gli stessi oggetti T k di tipo T, sebbene sarebbe più corretto asserire che essi
contengono non gli oggetti, ma i riferimenti agli oggetti.

Se altero un oggetto Tk nell’ambito della collezione vx, lo ritrovo alterato accedendolo dallo stream sx, e
viceversa. Tuttavia l’ordinamento non è altrettanto intercambiabile.

Se aggiungo elementi al vettore vx, eseguendo un forEach su vx trovo gli elementi nell’ordine in cui li ho
aggiunti, e lo stesso ordine lo trovo se eseguo [Link]; ciò significa che, inizialmente, l’ordine di
comparsa degli oggetti (ossia, dei loro riferimenti) è lo stesso, nella collezione e nello stream.

Supponiamo che venga eseguito un sort su sx: facendo il forEach su sx trovo gli elementi ordinati, ma
eseguendo il forEach su vx ritrovo la successione iniziale, non quella ordinata: l’ordine degli oggetti in vx è
rimasto inalterato.

Ad esempio, creo vx di tipo Vector<Complex> e gli aggiungo, nell’ordine, 2+5i, i e 3+4i; eseguendo
l’istruzione [Link](c -> [Link](c)), ottengo la sequenza sopra elencata.

Se usassi l’istruzione [Link]().sorted().forEach(c -> [Link](c)), otterrei la

stessa sequenza. Invece eseguo [Link]().sorted().forEach(c ->
[Link](c)): la sequenza stampata è quella ordinate, cioè i, 3+4i, 2+5i.

Infine, rieseguo [Link](c -> [Link](c)); la sequenza stampata è quella iniziale,

ossia 2+5i, i, 3+4i: l’ordinamento è avvenuto sullo stream, ma non sulla collezione.

Non vale il viceversa, e lo mostro attraverso un esempio: creo vx e lo popolo con la sequenza 2+5i, i e 3+4i,
poi recupero il riferimento allo stream, Stream<Complex> sx = [Link]().

Fatto ciò, eseguo l’ordinamento sulla collezione e stampo i dati:

[Link]((c1,c2) ->
{
if ([Link]() < [Link]()) return -1;
if ([Link]() > [Link]()) return 1;
return 0;
});
[Link](c -> [Link](c));

la sequenza stampata è quella ordinata, cioè i, 3+4i, 2+5i.

Infine, stampo la sequenza usando lo stream: [Link](c -> [Link](c)),

nonostante l’ordinamento della collezione sia avvenuto dopo l’assegnazione di sx, la sequenza stampata è
quella ordinata, ossia quella presente nella collezione.

Dettagli di funzionamento del metodo sort delle collezioni.

Il metodo sort della classe Vector<T> ha la signature public void sort(Comparator<? super T>
c), si tratta di un metodo disponibile a tutte le classi che implementano l’interfaccia List (non tutte le
collezioni la implementano, ma Vector sì); è simile al metodo sorted dell’interfaccia Stream<T>, però a
differenza di quest’ultimo, non ne esiste una versione parameterless, inoltre non restituisce un’altra
collezione (anzi, non restituisce alcunché).

Se intendo usare l’ordinamento naturale del tipo T (posto che T sia ordinato), anziché passare un criterio
esterno di comparazione come espressione lambda, posso scrivere sort(null); così, essendo il tipo
[Link] ordinato, e stabilito che il suo naturale criterio d’ordinamento mi soddisfi, posso riscrivere il
codice precedente come segue: [Link](null);

pag. 178
Advanced Java rev. 1.0 Novembre 2012

[Link](c -> [Link](c));

decisamente più semplice.

Stream standalone.
Finora ho considerato solamente stream derivanti da collezioni, tuttavia uno stream può esistere di suo,
senza tirare in ballo alcuna collezione: un oggetto di tipo Stream<T> può essere creato, popolato (o
costruito), e quindi utilizzato, a prescindere da ogni collezione. Si parla in questo caso di stream standalone.

Allo scopo, l’interfaccia Stream dispone del metodo statico builder; volendo creare uno stream standalone,
come prima mossa creo il builder, ad esempio: Builder<Complex> b = [Link]().

L’interfaccia [Link] è contenuta entro l’interfaccia Stream, è un suo

campo statico: static interface [Link]<T>, entro Stream<T>; a sua volta, Stream<T> ha
il metodo statico builder, parameterless, che crea un oggetto di tipo <T>.

Tramite il metodo add, posso quindi aggiungere elementi al builder: [Link](new Complex(3,4t)) etc.
Quando ritengo di aver terminato il popolamento dello stream builder (building phase), eseguo l’istruzione
Stream<Complex> sx = [Link](); l’istruzione [Link] fa evolvere lo stato dello stream builder a built,
e restituisce il riferimento allo stream: tutti gli elementi contenuti nello stream builder diventano elementi dello
stream appena generato, nello stesso ordine in cui sono stati aggiunti allo stream builder.

Lo stream che ne risulta è del tutto analogo a quelli già visti, ottenuti partendo da oggetti di tipo
Vector<Complex> e in generale da collezioni.

Notare: dopo la chiamata a [Link], lo stream builder passa nello stato built, e non è più possibile aggiungere
elementi.

I method reference.
I method reference sono in pratica una stenografia utilizzabile in alternativa ad alcune espressioni lambda;
come si vedrà nei prossimi paragrafi, esistono quattro diverse tipologie di method reference.

Riferimento ad un metodo d’istanza di un oggetto arbitrario di tipo dato.

Riprendo il caso del metodo filtraComplessi della classe Agente; supponiamo di dotare la classe Complex
del metodo public boolean isSquared(), che verifica se il quadrato del modulo è un intero, così il
metodo filtra Complessi può essere riscritto come segue:
public void filtraComplessi(int u)
{
Vector<Complex> vx = new Vector<Complex>();
for (int i=1;i<=u;i++) [Link](new Complex(i,i+1));
[Link]()
.filter(v -> [Link]())
.forEach(v -> [Link](v + " ha quadrato del modulo
intero"));
}

L’espressione lambda in filter consiste adesso di una chiamata di metodo sul parametro, e nient’altro. Al
posto dell’espressione lambda in questione, posso utilizzare un method reference:
public void filtraComplessi(int u)
{
...
.filter(Complex::isSquared)
...
}

Ho usato un riferimento al metodo isSquared del tipo Complex.

Mostro un altro esempio, nel quale sono presenti parametri di passaggio (isSquared è parameterless): si
tratta del metodo ordinaPersone della classe Agente. In esso, l’ordinamento viene imposto dall’esterno,
poiché Persona non è un tipo ordinato:
[Link]()

pag. 179
Advanced Java rev. 1.0 Novembre 2012

.sorted((p1,p2) ->
{
if ([Link] < [Link]) return -1;
if ([Link] > [Link]) return 1;
return 0;
})
.forEach(v -> [Link](v));

Suppongo di aggiungere alla classe Persona il metodo comparaMatricole:

public int comparaMatricole(Persona p)
{
if (matricola < [Link]) return -1;
if (matricola > [Link]) return 1;
return 0;
}

Il tipo Persona continua a non essere ordinato, infatti non implementa l’interfaccia Comparable, ho
semplicemente aggiunto un nuovo metodo, e me ne servo per riscrivere il codice precedente:
[Link]()
.sorted((p1,p2) -> [Link](p2))
.forEach(v -> [Link](v));

Anche qui, l’espressione lambda in sorted consiste di una sola chiamata di metodo, e può essere sostituita
da un riferimento al metodo comparaMatricole della classe Persona:
[Link]()
.sorted(Persona::comparaMatricole)
.forEach(v -> [Link](v));

Questa è una delle forme più comuni di method reference: è il riferimento a un metodo d’istanza (cioè, non
statico) di un oggetto arbitrario avente un certo tipo.

Nel primo esempio, il metodo d’istanza è isSquared e il tipo è [Link]; nel secondo esempio, il metodo
d’istanza è comparaMatricole e il tipo è [Link]; in entrambi, si fa riferimento a un oggetto generico: nel
primo caso, v di tipo Complex – e il metodo è parameterless; nel secondo caso, p1 di tipo Persona – e il
metodo ha un parametro d’ingresso, p2 di tipo Persona.

Riferimento ad un metodo statico di un tipo dato.

In un precedente paragrafo, il metodo main di Maine invocava il metodo Comparatore della classe Agente,
passando non solo i dati, ma anche gli algoritmi di calcolo, sia del fattoriale, sia della potenza di un binomio;
adesso, restando immutato il metodo [Link], cambio la chiamata nel metodo main:
quest’ultimo non passerà più gli algoritmi, ma si appoggerà a una classe esterna, [Link]
appartenente alla libreria LibJar/[Link], che implementerà tali algoritmi con propri metodi statici.

Ecco la classe Funzioni:

public class Funzioni
{
public static long Fattoriale(int n)
{
if (n < 0) return -1;
if (n == 0) return 1;
return n*Fattoriale(n-1);
}
public static long Binomio (int a, int b, int c, String o)
{
if ([Link]("-")) return (long) [Link](a-b,c);
else return (long) [Link](a+b,c);
}
}

Il metodo Comparatore della classe Agente è dichiarato come public String Comparatore(int n,
XFactor xf, int a, int b, int c, String o, XBino xb), perciò lo statement d’invocazione
nel metodo main di Maine può essere riscritto come segue:

pag. 180
Advanced Java rev. 1.0 Novembre 2012

[Link]([Link](q,n -> [Link](n),

r,s,u,t,(A,B,C,D) ->
[Link](A,B,C,D)));

le espressioni lambda possono essere sostituite da riferimenti ai metodi:

[Link]([Link](q,[Link]::Fattoriale,
r,s,u,t,[Link]::Binomio));

Questa è un’altra forma abbastanza comune di method reference: è il riferimento a un metodo statico di un
certo tipo. A prima vista, sembra uguale al riferimento a un metodo non statico di un oggetto arbitrario del
tipo considerato, però si tratta di due espressioni concettualmente diverse.

Ne mostro un altro esempio di utilizzo, fornito dal metodo coeffBino della classe Agente:
public long coeffBino (int n,int k)
{
XFactor xf = [Link]::Fattoriale;
return [Link](n)/([Link](k)*[Link](n-k));
}

Il metodo viene invocato nel main di Maine: [Link]([Link](q,r)); suo

scopo è il calcolo del coefficiente binomiale, ad esempio se q = 7, r = 3, ottengo il valore 35.

Qui l’approvvigionamento dell’algoritmo di calcolo del fattoriale è compiuto dal metodo coeffBino, il main si
limita a passare i soli valori. Con ciò, l’espressione lambda non è passata al metodo coeffBino dall’esterno,
ma è costruita e quindi usata dal metodo stesso; è come se nel metodo coeffBino avessi scritto l’istruzione
XFactor xf = n -> [Link](n), però al posto dell’espressione lambda esplicita
ho utilizzato la sua stenografia tramite un method reference.

Riferimento ad un metodo d’istanza di un particolare oggetto.

Riprendo il caso del metodo coeffBino, ma ipotizzo che il metodo Fattoriale della classe [Link] non
sia statico: come fare per utilizzarlo ancora, senza stravolgere più di tanto il codice del metodo coeffBino ?

Ecco la soluzione:
public long coeffBino (int n,int k)
{
[Link] fun = new [Link]();
XFactor xf = fun::Fattoriale;
return [Link](n)/([Link](k)*[Link](n-k));
}

Posso facilmente riscrivere anche la chiamata, da parte del metodo main, al metodo [Link]:
[Link] f = new [Link]();

[Link]([Link](q,f::Fattoriale,r,s,u,t,[Link]::Binomio))
;

qui viene ancora usato un method reference, ma si tratta del riferimento al metodo d’istanza di un oggetto
particolare, non arbitrario, e il tipo dell’oggetto (qui, [Link]) non compare.

Riferimento ad un costruttore.
Ci sono casi in cui un’espressione lambda si limita a restituire un oggetto. Come primo esempio, alquanto
accademico, considero il seguente scenario: il metodo main di Maine invoca un metodo (d’istanza) della
classe Agente, eseguendo l’output del risultato, senza sapere nulla delle caratteristiche dell’oggetto
restituito, senza nemmeno sapere il tipo dell’oggetto restituito:
[Link](agente.fetch2Double(q, r));

segue il codice del metodo della classe Agente invocato da main:

public Object fetch2Double(double a,double b)
{
XGet2Double xg = (d1,d2) -> new Complex(d1,d2);
return [Link](a, b);

pag. 181
Advanced Java rev. 1.0 Novembre 2012

L’interfaccia funzionale XGet2Double ha il (solo) metodo public Object get(double a,double b);
con ciò, l’espressione lambda a destra è un’implementazione adeguata: dati due parametri di tipo double,
essa restituisce un oggetto di tipo Complex, e ciò va bene dato che tutto ciò che si chiede è che ci siano due
parametri d’ingresso di tipo double e che ci sia un elemento qualsiasi restituito.

Anche questa espressione lambda può essere sostituita da un method reference, di tipo particolare, cioè il
riferimento ad un costruttore:
public Object fetch2Double(double a,double b)
{
XGet2Double xg = Complex::new;
return [Link](a, b);
}

Nonostante la classe Complex abbia anche un altro costruttore, tutto funziona correttamente, perché il
compilatore Java è in grado di selezionare il costruttore corretto in base alla parametrizzazione del metodo
get dell’interfaccia funzionale.

Mostro un altro esempio, più elaborato, nel quale l’interfaccia funzionale ha natura veramente generale; si
tratta dell’interfaccia CatchAny, appartenente al package intfc, compresa nella libreria LibJar/[Link]:
public interface CatchAny
{
public Object gotcha(Object... pars);
}

Ciò che viene restituito è un oggetto generico, e la parameter list può essere qualsiasi, anche vuota.

Poi considero la classe [Link], appartenente alla libreria LibJar/[Link]; si tratta di una classe
puramente accademica:
public class StrangeClass
{
private long num;
private Complex cx;
private String str;
public StrangeClass(Object... pars)
{
switch([Link])
{
case 0:
num = 0;
cx = new Complex();
str = "";
break;
case 1:
num = (long) pars[0];
cx = new Complex(num,num);
str = [Link](num, true);
break;
case 2:
num = (long) pars[0];
cx = new Complex(num-1,num+1);
str = (String) pars[1];
if (num != 0) str += [Link](num, true);
break;
}
}
@Override
public String toString()
{
return "StrangeClass: the long is "+num+", the complex is
"+cx+

pag. 182
Advanced Java rev. 1.0 Novembre 2012

" and the string is "+str;

}
}

La classe ha un costruttore molto elastico, si comporta come tre costruttori diversi a seconda del numero di
parametri passati; è compreso il caso del costruttore parameterless.

Aggiungo alla classe Agente il metodo seguente:

public Object strangeMethod(Object... pars)
{
[Link] cat = (ps -> new [Link](ps));
return [Link](pars);
}

ma lo riscrivo immediatamente, servendomi di un method reference, riferimento ad un costruttore:

public Object strangeMethod(Object... pars)
{
[Link] cat = [Link]::new;
return [Link](pars);
}

Poi aggiungo il codice di chiamata al main di Maine:

[Link]([Link]());
[Link]([Link]((long)u));
[Link]([Link]((long)u,t));

ove u e t, parametri passati da linea di comando, sono rispettivamente un intero ed una stringa.

La prima chiamata del main si rivolge al costruttore parameterless, infatti il risultato non cambia al variare di
u e t: StrangeClass: the long is 0, the complex is 0 and the string is .

La seconda chiamata del main si rivolge al costruttore con un solo parametro, di tipo long; ecco il risultato
per u = 12000 e t qualsiasi:
StrangeClass: the long is 12000, the complex is 12000+12000i and the string is
2EE0.

La terza chiamata del main si rivolge al costruttore con due parametri, di tipo long e String (nell’ordine); ecco
il risultato per u = 12000 e t = 0x:
StrangeClass: the long is 12000, the complex is 11999+12001i and the string is
0x2EE0.

Anche in questo caso, il compilatore Java sa come chiamare correttamente il costruttore (cioè, con quanti e
quali parametri).

Limitazioni comuni ai method reference.

I method reference sono stenografie di espressioni lambda, quindi possono essere usati solamente laddove
sono usabili le equivalenti espressioni lambda.

Per di più, essi coprono solamente un sottoinsieme delle espressioni lambda: un’espressione lambda può
essere costituita da un numero arbitrario di istruzioni, mentre un method reference corrisponde ad
un’espressione lambda costituita da una sola istruzione.

Ad esempio, riprendo il metodo fetch2Double della classe Agente: anziché limitarsi a restituire in ogni caso
un numero complesso usando i due parametri di passaggio come parti reale e immaginaria, il metodo deve
comportarsi ancora così solo nel caso in cui ambo i parametri siano strettamente positivi, altrimenti deve
restituire null. Questo nuovo comportamento è facilmente realizzabile mediante un’espressione lambda:
public Object fetch2Double(double a,double b)
{
XGet2Double xg = (d1,d2) ->
{
if ((d1 > 0) && (d2 > 0)) return new Complex(d1,d2);
else return null;

pag. 183
Advanced Java rev. 1.0 Novembre 2012

};
return [Link](a, b);
}

Tuttavia non posso tradurre quest’espressione in un method reference, a meno di non creare un metodo ad
hoc in una classe coinvolta, ad esempio Complex.

Infine, anche nel caso di espressioni lambda costituite da un’unica istruzione, questa dev’essere la chiamata
di un metodo o di un costruttore, e non altro.

Ad esempio, l’istruzione XGet2Double xg = (a,b) -> 2*a+b; è ben costruita e di immediato utilizzo;
ma non avrebbe senso cercare di riscriverla usando un reference method, proprio perché, nella sua
immediatezza, non è la chiamata di un metodo o di un costruttore.

pag. 184