Java: Arte e tecnica
Applicazioni e applet
Dario de Judicibus
Che cos’Φ un applet? E che differenza esiste fra un applet e una applicazione? Di seguito risponderemo a questa e ad altre domande, e costruiremo insieme una serie di modelli che ci serviranno come base per lo sviluppo di programmi in Java
Negli
articoli precedenti abbiamo visto come Java sia un linguaggio di programmazione completo,
in grado di soddisfare anche le esigenze di chi ha la necessitα di scrivere applicazioni
molto complesse. In teoria, non esiste alcun motivo per cui non si possa utilizzare
un’applicazione Java esattamente come si usa un eseguibile normale. Al momento,
tuttavia, il fatto che Java non sia parte integrante dei sistemi operativi e la presenza
di alcune limitazioni fanno s∞ che chi debba sviluppare applicazioni specifiche per una
certa piattaforma preferisca linguaggi pi∙ classici, come, per esempio, il C++. Queste
limitazioni nello sfruttare al massimo le peculiaritα delle singole piattaforme sono
dovute al fatto che esso deve basarsi su un’architettura intrinsecamente portabile, e
quindi generalizzata. In effetti, Java non si presenta come diretto concorrente di altri
linguaggi largamente utilizzati nello sviluppo di applicativi. La scelta del linguaggio va
sempre fatta sulla base di esigenze pratiche, non in base a princ∞pi pi∙ o meno
discutibili o a preferenze personali. Se, per esempio, devo sviluppare
un’applicazione che richiede elevate prestazioni e che deve sfruttare al massimo le
funzioni specifiche della piattaforma UNIX o Linux, user≥ il C o il C++. Viceversa, se ho
bisogno di sviluppare rapidamente un’interfaccia per la piattaforma Windows 95,
sceglier≥ il Visual Basic. Il Rexx sarα una scelta ideale per sviluppare macro per le
piattaforme Amiga e OS/2, ma in entrambi i casi sceglier≥ di nuovo il C o il C++ se devo
sviluppare un eseguibile che sfrutti al massimo le librerie specifiche di questi ambienti
operativi. In molti casi, poi, la scelta del linguaggio pu≥ dipendere dal tipo di
applicazione che dovr≥ sviluppare: esistono infatti linguaggi pensati appositamente per
gestire basi dati o sviluppare applicazioni multimediali. Dal Fortran al COBOL, da Delphi
a Clipper, ogni linguaggio ha una sua ragione d’essere. Sono strumenti, e come tali
vanno usati. Java Φ un linguaggio pensato per la Rete, e quindi deve garantire al massimo
la portabilitα, l’interoperabilitα e la sicurezza. Questo ovviamente ha un prezzo.
Dato tuttavia che l’essere in Rete Φ ormai una realtα consolidata anche per il
computer di casa, chiunque sviluppi applicazioni dovrα sempre di pi∙ fare i conti con
questo linguaggio.
Due tipi di programmi
D’altra parte, anche se pu≥ essere fastidioso dover scrivere java prima del nome di un programma per farlo eseguire, e anche se l’esecuzione stessa Φ pi∙ lenta di quella di un equivalente programma scritto in C, questo Φ solo un problema contingente. L’integrazione della macchina virtuale Java nei sistemi operativi, l’implementazione di interpreti sempre pi∙ veloci e compilatori just-in-time, faranno in breve dimenticare le attuali limitazioni. Nei prossimi articoli vedremo come giα da ora Java pu≥ essere utilizzato per scrivere programmini e utilitα di sistema, esattamente come un qualunque altro linguaggio. Ma andiamo per ordine.
Con Java possiamo scrivere due tipi di programmi, molto diversi fra loro per caratteristiche e funzioni. La prima categoria Φ formata dalle applicazioni. Un’applicazione non Φ altro che un programma classico, capace di interagire con il sistema operativo e con le sue risorse. Dato che in Java non esistono le funzioni, non Φ possibile definire una funzione main() come in C++ che rappresenti il punto d’ingresso della nostra applicazione. Quello che si fa Φ invece di definire una classe principale la quale conterrα al suo interno un metodo statico chiamato main(), che verrα eseguito quando la classe viene passata all’interprete. Lo scheletro di un’applicazione Φ quindi molto semplice, come si pu≥ vedere nel listato 1. Tuttavia, c’Φ un aspetto da non trascurare. Il metodo main Φ statico, e quindi Φ lo stesso per tutte le istanze della classe che lo contiene.
Essendo un metodo statico non si possono utilizzare al suo interno variabili che non siano a loro volta statiche oppure locali al metodo.
Se adottiamo la convenzione di utilizzare il prefisso cv per tutte le variabili di
classe, iv per quelle dell’istanza e nessun prefisso per quelle locali, questo vuol
dire che il metodo main non pu≥ far riferimento a variabili di tipo iv. Per superare il
problema, si pu≥ ricorrere alla tecnica mostrata nel listato 2. Basta cioΦ creare
all’interno del metodo main un’istanza della classe che contiene il metodo
stesso, chiamandone il costruttore. Se poi ci si vuole assicurare che per ogni
applicazione venga creata una e una sola istanza, si dovrα rendere il costruttore in
questione privato, e chiamarlo solo se l’istanza in questione Φ nulla (listato 3).
Questa tecnica, detta singleton, Φ molto utile quando si vogliono evitare istanze
multiple di una stessa classe lα dove due istanze potrebbero entrare in contesa delle
stesse risorse. Una tecnica simile pu≥ essere utilizzata per limitare comunque il numero
d’istanze di una classe che possono essere utilizzate contemporaneamente. Tecniche di
questo tipo sono molto utili nell’implementazione di servizi remoti a sistemi client.
Come generare un’applicazione
A partire da questi tre listati si possono sviluppare tutta una serie di applicazioni, come vedremo in alcuni dei prossimi articoli. Generare un’applicazione Java Φ semplice. Basta creare un file il cui nome Φ lo stesso della classe che contiene il metodo main e la cui estensione Φ java, per esempio ApplicationClass.java. DopodichΘ si esegue il comando
javac ApplicationClass.java
che genera il file ApplicationClass.class. A questo punto si pu≥ eseguire l’applicazione lanciando il comando
java ApplicationClass
La seconda categoria Φ quella degli applet. Un applet Φ un oggetto che non pu≥
vivere di vita propria, ma viene eseguito in un contesto ben specifico, e cioΦ
all’interno di un browser. Questo vuol dire che un applet non pu≥ essere eseguito
singolarmente, ma viene attivata dal caricamento di una pagina Html. Questa caratteristica
comporta un vantaggio e uno svantaggio. Il vantaggio Φ che l’applet pu≥ sfruttare
quelle che sono le funzionalitα del browser. Per esempio, Φ estremamente semplice per un
applet caricare un suono e mandarlo in esecuzione. Per fare la stessa cosa in
un’applicazione Φ necessario costruire classi apposite che interagiscano
direttamente con il sistema, magari attraverso del codice nativo, cioΦ codice scritto in
un altro linguaggio e che pu≥ utilizzare le API del sistema, come, per esempio, il C. Lo
svantaggio, Φ che le applet sono state disegnate per essere scaricate dalla Rete, e come
tali possono facilmente diventare cavalli di Troia per i sistemi su cui vengono eseguite.
Per evitare ci≥, agli applet sono state imposte una serie di limitazioni, specialmente
per quello che riguarda l’accesso al sistema e ai dati in esso contenuti. Tali
limitazioni non valgono tuttavia per gli applet che vengono caricati da un file-system
locale. Un applet Φ sempre una sottoclasse della classe Applet, e prevede
l’implementazione di quattro metodi: init(), start(), stop() e destroy(). In realtα,
non Φ necessario che un applet implementi qualcuno di questi metodi, anche se poi, di
fatto, spesso lo si fa. Il metodo init viene chiamato al momento del caricamento della
pagina contenente l’applet e serve per l’inizializzazione. Analogamente il
metodo destroy Φ chiamato quando l’applet non serve pi∙, ed Φ quindi utilizzato
per liberare eventuali risorse allocate. I due metodi start e stop servono invece a far
partire e a fermare il funzionamento dell’applet, e possono anche essere richiamati
pi∙ volte mentre la pagina Φ visualizzata. Per esempio, possono servire a far partire e
a fermare un’animazione o l’esecuzione di un pezzo musicale. Oltre che a essere
richiamati esplicitamente, il metodo start parte automaticamente non appena init ha
terminato l’inizializzazione e l’applet Φ pronta per essere eseguita, mentre il
metodo stop Φ eseguito automaticamente quando un’altra pagina viene caricata oppure
il browser viene ridotto a icona. In genere di questi quattro metodi, quello che raramente
s’implementa Φ destroy, che in molti browser Φ richiamato solo quando si chiude
definitivamente il browser stesso. Un modello semplificato di applet Φ riportato nel
listato 4, mentre il listato 5 riporta una versione avanzata che sfrutta le thread per
incrementare le prestazioni nel caricamento della pagina. Attenzione per≥:
l’utilizzo di thread cos∞ come quello di pi∙ istanze dello stesso applet nella
stessa pagina richiede l’applicazione di alcune tecniche di sincronizzazione non
banali per evitare effetti collaterali.
Le limitazioni
In realtα esistono altri metodi che dovrebbero essere implementati quando si sviluppa un applet serio, come getAppletInfo() e getParameterInfo(), ma di questo parleremo quando descriveremo anche come documentare il nostro codice e come utilizzare il comando javadoc. Anche per generare un applet Φ necessario scrivere un file che abbia lo stesso nome della classe ed estensione java, e anche in questo caso si deve usare il comando
javac AppletClass.java
Tuttavia, al contrario di quanto accade con le applicazioni, per eseguire un applet Φ necessario scrivere prima una pagina Html, come quella nel listato 6, e poi caricarla in un browser o lanciare il comando
appletviewer AppletClass.html
Ma quali sono le limitazioni che ha un applet rispetto a un’applicazione?
Al momento, ma le regole sono in continua evoluzione, un applet caricato da un server remoto non pu≥ caricare librerie, utilizzare metodi nativi, leggere o scrivere direttamente file del client, aprire connessioni di rete ad altri sistemi che non siano il server da cui Φ stato caricato, eseguire processi o applicazioni sul client, e leggere alcune proprietα del client che si Φ ritenuto opportuno dovessero rimanere riservate. In pi∙, una finestra aperta da un applet si deve differenziare da una normale finestra di sistema in modo da evitare che qualcuno usi un applet per clonare il pannello di logon di un sistema e catturarne cos∞ le informazioni di accesso (utenza e parola d’ordine). Insomma, le limitazioni sono molte, ma bisogna rendersi conto che gli applet non sono state inventati per creare qualche simpatico effetto speciale sulle nostre pagine Html, bens∞ per fungere da client nei confronti di un’applicazione remota scritta in Java ed eventualmente utilizzante codice nativo, in modo da permettere di usare il browser come vera e propria interfaccia remota cross-platform di applicazioni aziendali.