Facoltà di Ingegneria

U NIVERSITÀ DEGLI S TUDI DI N APOLI F EDERICO
II
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea
ANALISI E VALUTAZIONE DI MACCHINE
VIRTUALI JAVA PER DISPOSITIVI MOBILI
RELATORE
CANDIDATO
Ch.mo Prof. Ing. Stefano Russo
Francesco Esposito
Matricola 41/19
CORRELATORE
Ing. Domenico Cotroneo
ANNO ACCADEMICO 2002-2003
i
A mio
padre,
che ha lasciato un
vuoto incolmabile
dentro di me.
A mia madre.
ii
Ringraziamenti
Ancora non riesco a credere di essere giunto alla fine di un percorso così tortuoso e
travagliato. Sono stati molti i momenti di sconforto e più di una volta ho creduto di non
farcela. Presto molte delle mie ansie e angosce saranno rimosse e resterà solo la gioia di
aver reso fieri di me, le persone che mi vogliono bene e hanno avuto fiducia in me.
Ringrazio Dio, la cui benevolenza nei miei confronti è palese, per essere comunque
presente nella mia vita e per aver detto che gli ultimi saranno i primi.
Ringrazio mio padre che anche quando non stava affatto bene si preoccupava del fatto
che io non studiassi per stare vicino a lui, “perdonami per aver perso tanto tempo da non
poterti dare la gioia che sto donando a me stesso e agli altri. Spero tu sia fiero di me,
soprattutto per il modo in cui sto cercando di condurre avanti la nostra famiglia.”
Ringrazio mia madre per non avermi fatto mai pressioni, per aver gioito oltremodo ad
ogni esame, per aver sempre lavorato e lottato per i suoi figli, per le parole di lode e
ammirazione che ha proferito nei miei riguardi. “Spero che la gioia di questo momento
possa alleviare le tue tristezze e malinconie latenti.”
Ringrazio le mie sorelle: Anna, Lina e Pina per il loro amore e per le preghiere.
Ringrazio i miei nipotini e i membri della famiglia tutta.
Ringrazio Rossella per avermi costretto a sostenere esami che avrei altrimenti
rimandato, per il suo ottimismo contagioso, per il suo affetto.
Ringrazio Gaetano, amico sincero con il quale mi appresto a concludere la tormentata
epopea. Grazie per aver sopportato i miei costanti ritardi e per aver ascoltato i miei guai
con benevola comprensione.
Grazie al prof. Stefano Russo, mio relatore, e all’ing. Domenico Cotroneo, mio
correlatore e amico, per la preziosa assistenza.
Ringrazio: Paolo o’ purton; Giancarlo o’prucion; Ciro o’polemic; Laura anche detta
Maritton, anche detta Michel Jecksòn; Marco o’nano; Pepino tozzetto; Carmine
o’tupòn; o’Macciocc; e’ Milòn; Riccardin; o’Nunziat; i Grassi (che non sono miei
parenti); o’Iaccarin; o’Lerro; o’Rosell; o’Scellòn; Michele o’sapunar; Frenco; Ale detto
Jesus; Barbara wanna be good; Annabella a’ crostatin; Tina Robert; Gianni o’suggetton;
Alex il cane solatore; Bruno ex playboy; Foffy o’diggei; Linda; Valentina; Lell’o’rull; il
braccio e il braccio; Laura a’barist; Nicola o’ginecologo; le pitone; Paolo o’pucuron;
Pierluigi o’frevon; Pippo a’pall; Rosaria donna del procione anche detto a’ svedes;
Rosario o’cloaca; Austin Funèl; Tore Marino, per il soprannome parola…
senza di voi non ce l’avrei mai fatta a invecchiare sui libri!
Grazie a tutte le donne che ho avuto, finalmente avrò i soldi per pagare ancora; grazie a
telecapri, per i cattivi pensieri; grazie ai miei pochi capelli rimasti.
Grazie ai cari ingegneri del laboratorio: Carletto, chi s’assumigl’s’pigl’; Vincenzo forza
Barra, Cristiano; Generoso, Armando, Carmine e Marcello.
Un grazie agli amici: Carmine; Imma, anche detta Concetta; Paolo, better known as
Muppet; Stanislao e Gianluca SuperWaba.
Grazie a tutti…
Addà venì baffon!
iii
Introduzione
Cenni preliminari
1
3
Capitolo 1 – Le piattaforme Java per dispositivi mobili
7
1.1 Cenni storici
7
1.2 Architettura
8
1.2.1 Java Virtual Machine
9
1.2.2 Configurazioni
10
1.2.3 Profili
11
1.3 CLDC e CDC
12
1.3.1 Confronto tra le configurazioni
12
1.3.2 Dettagli di CLDC
13
1.3.2.1 Differenze di linguaggio
15
1.3.2.2 Differenze nelle Virtual Machine
16
1.3.3 Dettagli di CDC
1.3.3.1 Differenze di linguaggio
18
19
1.3.4 I Profili nel dettaglio
23
1.3.4.1 Il profilo MIDP
24
1.4 Sviluppo di applicazioni J2ME
27
Capitolo 2 – Le Virtual Machine CDC
28
2.1 Jeode
29
2.1.1 Disponibilità
29
2.1.2 Caratteristiche
30
2.1.3 Ciclo di Sviluppo
32
2.1.4 Le API di Jeode
33
2.2 CrEme
34
2.2.1 Disponibilità
34
2.2.2 Caratteristiche
35
2.2.3 Ciclo di Sviluppo
37
2.2.4 Le API di CreMe
38
2.3 SuperWaba
39
2.3.1 Disponibilità
40
2.3.2 Caratteristiche
42
2.3.3 Ciclo di Sviluppo
44
iv
2.3.4 Le API di SuperWaba
2.4 Ewe
46
48
2.4.1 Disponibilità.
49
2.4.2 Caratteristiche
50
2.4.3 Ciclo di Sviluppo
51
2.4.4 Le API di Ewe
53
2.5 Considerazioni comparative
54
Capitolo 3 – Definizione ed implementazione dei test sperimentali
55
3.1 Il modello di qualità
55
3.1.1 Gli attributi e le entità
56
3.2 Le metriche
57
3.3 I test sperimentali: definizione e implementazione
59
3.3.1 Il multithreading
59
3.3.1.1 Considerazioni preliminari
59
3.3.1.2 Livello di multithreading
62
3.3.1.3 Prestazioni di uno stesso algoritmo multithread
63
3.3.2 Il tempo di chiamata ai metodi
64
3.3.3 Operazioni di Input/Output su file
65
3.3.4 Operazioni di Input/Output su rete
66
Capitolo 4 – Analisi e valutazione dei risultati sperimentali
68
4.1 Metriche quantitative: risultati
69
4.1.1 Impronta di memoria
69
4.1.2 Multithreading
69
4.1.2.1 Livello di Multithreading
70
4.1.2.2 Prestazioni di un algoritmo multithread
72
4.1.3 Tempo di chiamata a metodi
73
4.1.4 Overhead delle macchine virtuali
74
4.1.5 Operazioni di I/O su file
75
4.1.6 Operazioni di I/O su rete
77
4.2 Metriche quantitative: confronto
78
4.2.1 Impronta di memoria.
78
4.2.2 Multithreading
79
4.2.2.1 Livello di multithread
79
v
4.2.2.2 Prestazioni di un algoritmo multithread
82
4.2.3 Tempo di chiamata a metodi
84
4.2.4 Overhead delle macchine virtuali
86
4.2.5 Operazioni di I/O su file
87
4.2.5.1 Scrittura
87
4.2.5.2 Lettura
88
4.2.6 Operazioni I/O su rete
4.3 Metriche quantitative: valutazioni e confronto
89
90
4.3.1 Disponibilità
90
4.3.2 Ciclo di sviluppo
91
4.2.3 Classi supportate
92
4.2.4 Interfaccia utente
93
4.2.5 Compatibilità con Java
94
Conclusioni
95
Appendice A
96
A.1 Istallazione di SuperWaba su PC Desktop (Windows 98 e superiori)
96
A.2 Installazione di SuperWaba sul palmare (Compaq iPAQ 3970)
97
A.3 L’ applicazione
98
A.4 Compilazione e generazione degli eseguibili
99
A.5 Esecuzione
100
Appendice B
102
B.1 Istallazione di Ewe su PC Desktop (Windows version)
102
B.2 Installazione di Ewe sul palmare (Compaq iPAQ 3970)
103
B.3 L’ applicazione
103
B.4 Compilazione e generazione degli eseguibili
104
B.5 Esecuzione
106
Bibliografia
107
vi
Introduzione
Scopo del seguente lavoro di tesi è il confronto tra differenti macchine virtuali, destinate
ai cosiddetti “small connected devices”, cioè ai piccoli dispositivi dotati di proprietà di
connettività. L’attenzione è focalizzata in particolare sui palmari con sistema operativo
basato su WindowsCE.
Al fine di conseguire l’obiettivo si valuteranno le diverse macchine virtuali mediante la
definizione di un modello di qualità [Pressman]. La qualità si caratterizza attraverso un
insieme finito e definito di attributi, quindi un modello di qualità è composto da
attributi, ciascuno considerato con un suo peso, aventi la finalità di rappresentare la
qualità posseduta dal prodotto software considerato.
Nel definire il modello consideriamo il fatto che i palmari attuali hanno raggiunto
un’evoluzione tale, da avvalersi dell’appellativo di piccoli dispositivi principalmente in
termini relativi, cioè se rapportati agli odierni computer desktop. Per cui il numero di
applicazioni client-based realizzate per tali dispositivi è cresciuto enormemente.
In tabella 1 è mostrato l’insieme di attributi scelto per la caratterizzazione del modello
proposto e, per ciascun attributo, l’insieme delle entità che, a loro volta, caratterizzano
gli attributi.
Attributo
Efficienza
Interoperabiltà
Usabilità
Portabilità
Entità
Multithreading; Chiamate a metodi;
Overhead;
Operazioni di Input-Output su file e su rete;
Compatibilità con Java
Ciclo di sviluppo, Interfaccia grafica, Classi
supportate
Disponibilità su differenti piattaforme
hardware-software.
Tabella 1 – Modello di qualità per la valutazione delle macchine virtuali.
Definito il modello, è possibile introdurre le metriche software. Esse rappresentano lo
strumento attraverso il quale è possibile misurare le entità che caratterizzano gli attributi
del modello considerato.
Le metriche definite, sono sia qualitative sia quantitative. Esse sono descritte nella
tabella 2.
1
Metrica qualitativa
Il numero di piattaforme hardware-software che supportano le VM.
Il ciclo di sviluppo per la realizzazione delle applicazioni.
Usabilità
La tipologia di classi supportate da ciascun ambiente.
La tipologia del supporto alle Graphical User Interface.
Interoperabilità Compatibilità con java.
Portabilità
Metrica quantitativa
L’impronta di memoria (footprint memory);
Il multithreading, in termini di:
• Livello di multithreading;
• Tempo di esecuzione di uno stesso algoritmo multithread,
senza politiche di sincronizzazione.
Le chiamate a metodi, in termini di:
• Tempo medio di chiamata senza parametri;
• Tempo medio di chiamata con parametro elementare;
• Tempo medio di chiamata con parametro strutturato;
L’overhead, in termini di:
• Quantità media di memoria occupata, per l’esecuzione della
macchina virtuale.
Interoperabilità Le operazioni di Input/Output su file, in termini di:
• Tempo medio di scrittura al variare delle dimensioni del file;
Efficienza
•
Tempo medio di lettura al variare delle dimensioni del file
Le operazioni di Input/Output su rete, in termini di delay.
Tabella 2 – Metriche qualitative e quantitative.
Il
processo di misurazione passa attraverso la realizzazione di varie applicazioni
concernenti le aree di interesse menzionate in precedenza. Il dispositivo su cui saranno
eseguite le applicazioni è il palmare Compaq iPAQ 3970, con sistema operativo
PocketPC2002. Le virtual machine, oggetto della valutazione, sono le seguenti:
•
Jeode, della Insigna [Jeode];
•
CreMe, della NSICom [CrEme];
•
Superwaba [SWaba];
•
Ewe [Ewe].
2
Cenni preliminari
Considerato il recente e quanto mai crescente interesse riguardo l’uso di Java su piccoli
connected devices può sorprendere pensare che le origini di Java derivino dal progetto e
lo sviluppo di un limitato dispositivo wireless di nome “*7” [HaOCon].
Quest’ultimo è stato realizzato dalla Sun alle metà degli anni ’90. Il sistema operativo di
tale macchina, denominato “Dubbed”, ha contribuito alla formalizzazione di base del
linguaggio Java. Quindi impiantare Java sui piccoli device può considerarsi, seppur
modestamente, una sorta d’onorificenza nei riguardi delle origini di Java.
Cominciamo ad esaminare le limitazioni che caratterizzano i piccoli dispositivi poiché
tali si traducono in altrettante sfide per l’utilizzo di Java in tale ambito.
L’attenzione è rivolta a quei dispositivi mobili, quali telefoni cellulari e PDA ( Personal
Digital Assistent ), caratterizzati da consistenti limitazioni in termini di funzionalità e
risorse se confrontati ai desktop computer.
Come accennato il linguaggio Java era stato inizialmente concepito come tecnologia di
interconnessione per piccoli dispositivi, ma col tempo si è sviluppato fino a supportare
programmi per computer desktop e applicazioni mission critical server based.
Di conseguenza, al progetto iniziale, sono state aggiunte un numero considerevole di
API (Application Program Interface), incrementando significativamente le funzionalità
offerte da Java.
E’ facile intuire che le numerose API messe a disposizione da Java non possono essere
integrate in quei dispositivi caratterizzati dai vincoli di cui sopra.
Nel 1999 alla JavaOne Conference fu presentata KVM (Kilobyte Virtual Machine) per
il Palm OS, successivamente con l’arrivo di J2ME, Java è ritornato ad essere destinato
ai piccoli dispositivi.
Ci si può porre la questione se Java abbia la caratteristica di essere “suitable” per i
piccoli dispositivi. Ebbene il recente sviluppo di Java come vero e proprio linguaggio di
programmazione accompagnato dallo sviluppo del mercato dei piccoli device risponde a
tale interrogativo in maniera inequivocabilmente affermativa, ma molte caratteristiche
del linguaggio e le API devono essere adattate per rispondere ai requisiti di tali piccoli
dispositivi.
3
Gli aspetti che maggiormente sono da tenersi in considerazione riguardano le seguenti
aree chiave:
•
capacità di elaborazione in termini di CPU e memoria;
•
alimentazione;
•
connettività;
•
interfaccia utente.
Analizziamo con ordine ciascuna delle aree summenzionate.
Capacità di elaborazione
La computing capability è in diretta correlazione con il modo in cui un dispositivo
elabora le informazioni per l’utilizzatore finale. Essa è da ritenersi un attributo
composto le cui parti fondamentali sono: la velocità della CPU, la memoria totale, la
capacità delle unità di memorizzazione di massa e gli altri fattori concernenti
l’hardware.
Purtroppo la capacità di elaborazione varia notevolmente nell’ambito dei piccoli
dispositivi e l’unico denominatore comune è il fatto di essere molto limitati se
confrontati con i desktop computer.
La limitata natura dei piccoli dispositivi vincola pesantemente il Java Environment, data
la vastità delle librerie standard di Java è impossibile infatti pensare di portare
interamente le API standard su di un piccolo dispositivo.
Pertanto impiantare API che abbiano la caratteristica di essere usabili, in un piccolo
dispositivo, necessita di un oculato adattamento, d’altra parte la limitazione nelle API
porta ad una limitazione nella portabilità dei relativi programmi. Gli sviluppatori Java
hanno infatti imparato a produrre codice indipendentemente dalla specifica piattaforma
a cui una applicazione può essere destinata e questo ha incrementato, dal punto di vista
dello programmatore, la gradevolezza (appeal) nei confronti dell’ambiente Java.
L’approccio di ridimensionamento del Java Environment è tuttavia inevitabile ed
influisce sull’ appeal dell’intero ambiente poiché costringe gli sviluppatori a conoscere
le “nuove” API, ma risulta essere l’unico approccio possibile al fine di conciliare le
esigenze di tutte le parti in causa.
4
Fortunatamente, come in ogni altro campo dell’ industria dei computer, anche per i
piccoli dispositivi c’è una rapida crescita della capacità di elaborazione, basti pensare
che il Palm1000 presentato nel 1996 era equipaggiato con una memoria RAM di appena
128kb e che dopo circa quattro anni le versioni del PalmOS includevano una memoria
RAM di 8Mb. Oggigiorno siamo ad una dimensione della memoria di 64Mb. Anche la
velocità della CPU aumenta vertiginosamente con gli anni: i PalmOS del 2000 avevano
un clock intorno ai 25MHz mentre attualmente si hanno handheld che lavorano anche a
frequenze di 400MHz. Al miglioramento della capacità di elaborazione concorrono
diversi fattori, tra i quali l’integrazione dei componenti elettronici e il miglioramento
delle architetture dovuto alla crescita del mercato dei piccoli dispositivi, tale crescita è
stata favorita anche dal diffondersi delle tecnologie wireless network tra cui è in forte
ascesa Bluetooth.
Alimentazione
Diversamente dai computer desktop i piccoli dispositivi hanno, per loro natura, la
caratteristica di dover essere self-sufficient dal punto di vista dell’alimentazione. Cioè si
assume che essi possano operare senza l’ausilio diretto di una fornitura di energia
elettrica e sono dotati di una batteria ricaricabile che ha una limitata autonomia e che
rappresenta una risorsa da ottimizzare con cura, dato che la natura mobile dei device
conduce all’assunzione che essi operino lungo tempo senza poter essere ricaricati.
La necessità di conservazione della batteria influenza in maniera indiretta il processo di
acquisizione di Java sui piccoli dispositivi: chip che lavorano a frequenza più basse
richiedono meno potenza e quindi prolungano la vita della batteria e il loro uso, ciò si
riflette nella necessità di avere API ottimizzate per avere tempi di risposta accettabili dal
punto di vista dell’utilizzatore.
5
Connettività
Dato il crescente espandersi dei piccoli dispositivi, la banda delle reti wireless non è più
da considerarsi limitata . Nel 2000 la maggior parte delle applicazioni wireless based
potevano contare su di una banda di 9600 Kbps o anche meno, questo perché l’impiego
di Java era maggiormente rivolto ai telefoni cellulari, oggi siamo intorno a 10÷54 Mbps.
Comunque per i piccoli dispositivi che supportano Java, reti lente e inconsistenti, in
termini di disponibilità, possono ostacolare funzionalità che si affidano ad un
connessione a larga banda.
Le applicazioni sui piccoli dispositivi wireless devono quindi portare in conto le diverse
reti e le difficoltà di comunicazione che si incontrano su di una rete lenta e
limitatamente affidabile.
Interfaccia utente
Una delle aree in cui è più difficile standardizzare, passando attraverso varie
piattaforme, è l’interfaccia utente. La storia di Java, del resto, ci illustra quale lento
processo abbia alla fine portato ad una matura GUI ( Graphical User Interface ).
I piccoli dispositivi presentano altrettante difficoltà in questa area chiave, data la
molteplicità e la diversità dei metodi di input – output. Si pensi ad esempio alle
differenti dimensioni degli schermi di un telefonino cellulare e di un palmare o alle
diverse modalità di immissione dati di questi ultimi.
Per tale motivo non è consigliabile portare su di un piccolo dispositivo le API Swing o
AWT integralmente, anche perché queste sono state pensate per computer aventi
dimensioni degli schermi ben delineate.
Sarebbe preferibile quindi pensare ad una GUI che fosse in grado di aderire alle
caratteristiche “look and feel” dei singoli dispositivi in questione. D’altra parte, in
particolar modo per gli handheld, è possibile alleggerire le API del Java Environment,
per esempio le API AWT, lasciando al programmatore il compito di adattare la propria
applicazione alle dimensioni del device cui è destinata l’applicazione stessa.
6
Capitolo 1
Le piattaforme Java per dispositivi mobili
Il primo sforzo concreto, finalizzato alla realizzazione di piattaforme Java per i piccoli
dispositivi, è stato compiuto dalla Sun attraverso il progetto della tecnologia J2ME
(Java 2 Micro Edition) [J2ME], [HaOCon].
J2ME nasce come strumento in grado di fornire funzionalità multi-piattaforma su
piccoli dispositivi orientati alla connessione. Le stesse che hanno caratterizzato
l’infrastruttura Java standard e che ne hanno decretato il successo. In poche parole la
mission era portare Java su tali device, per cui l’obiettivo principe si può identificare
nella portabilità delle applicazioni.
Abbiamo già discusso dell’impossibilità di portare integralmente le API standard sulle
svariate tipologie di dispositivi, per cui si è dovuto affrontare un attento processo di
riduzione delle “core API” attraverso semplice soppressione e ottimizzazione.
Quest’ultima realizzata, però, lasciando inalterate le specifiche dei metodi (bisognava
cambiare il “come”, non il “cosa”).
I dispositivi in questione non hanno tutti le stesse caratteristiche, per cui, al fine di
fornire compatibilità con una platea tanto eterogenea, si è deciso di progettare
l’infrastruttura J2ME in maniera modulare. Ciascun modulo fornisce una serie si servizi
(attraverso le API), cosicché una applicazione è in grado di essere eseguita su diverse
piattaforme a patto che esse supportino gli stessi moduli dell’infrastruttura.
1.1 Cenni storici
J2ME fu presentata al mondo per la prima volta nel 1999 durante i lavori della JavaOne
conference.
Era l’epoca in cui la Sun annunciò la realizzazione della prima Virtual Machine per il
PalmOS: si trattava di Kilobyte Virtual Machine (KVM).
Nel corso del 2000 prese corpo l’intento di modularizzare l’infrastruttura J2ME con
l’introduzione, per la prima volta, di un’architettura basta su configurazioni e profili. In
tal modo, partendo da una realizzazione basata su KVM, il J2ME environment è stato
7
esteso fino ad includere numerose famiglie di dispositivi. La cosa che rende
profondamente diverso J2ME dai suoi predecessori, tra cui Personal Java e Embedded
Java, è proprio il fatto di rendere possibile la personalizzazione di J2ME per specifici
dispositivi in un modo rigorosamente standardizzato, prevenendo così il proliferare di
differenti e ridondanti versioni e garantendo un’elevata flessibilità.
1.2 Architettura
Le specifiche di J2ME hanno imposto, fin dal concepimento, la strutturazione delle API
in due livelli, in grado di fornire comunione e flessibilità. Essi sono definiti,
rispettivamente, configurazioni e profili e formano, unitamente ad una Java Virtual
Machine (JVM) un completo Java Runtime Environment per una determinata tipologia
di dispositivi.
Applicazione J2ME
Profilo
Applicazione J2ME
Profilo
opzionale
Java
API
specifiche
Applicazione
Nativa
Configurazione
Java Virtual Machine
Sistema Operativo Nativo
Figura 1.1 - Architettura J2ME
In figura 1.1 è mostrata la stratificazione dei livelli software di un dispositivo che
supporta l’ambiente J2ME:
•
Il sistema operativo fornisce i servizi di base per accedere all’hardware del
dispositivo, consente l’accesso alla memoria e gestisce l’ archiviazione delle
8
informazioni sulla memoria di massa. Inoltre esso supporta le applicazioni
native;
•
La Java virtual machine fornisce l’ambiente di esecuzione necessario ad
interpretare il bytecode Java e può eventualmente supportare le Java API
specifiche del costruttore;
•
Al di sopra della macchina virtuale si trovano le API appartenenti alla
particolare famiglia di dispositivi e le API specifiche del singolo dispositivo,
realizzate dal costruttore. Le prime sono contenute nella configurazione e nel
profilo, mentre le seconde consentono di accedere alle funzionalità proprie di
quel dispositivo e non della famiglia;
•
infine troviamo l’applicazione J2ME realizzata mediante l’utilizzo delle API
fornite ai livelli sottostanti.
1.2.1 Java Virtual Machine
Come già accennato la macchina virtuale Java fornisce un ambiente di esecuzione per
l’esecuzione dei programmi Java. Essa si pone al disopra del sistema operativo fornendo
un interprete nativo per il bytecode. Le JVM per i piccoli dispositivi hanno a
disposizione solo una quantità molto limitata di memoria per svolgere il loro compito,
inoltre necessitano di essere ottimizzate per fornire un accettabile livello di prestazioni,
in quanto la velocità di elaborazione dei piccoli dispositivi è altrettanto ridotta quanto la
memoria.
I requisiti di una siffatta macchina virtuale sono definiti da un lato dalla limitata
natura del dispositivo in questione e dall’altro dalla definizione della particolare
configurazione, la quale definisce una serie di funzionalità che la JVM deve
implementare.
La Kilobyte Virtual Machine, progettata per lavorare sui PalmOS, deve il suo nome alla
ridotta quantità di memoria di cui necessita per essere installata su di un piccolo
dispositivo. E’ sufficiente una quantità di memoria di 160kb e lavora su processori
CISC o RISC a 16 e 32 bit.
Simile alla precedente è la HVM, Hotspot Virtual Machine, la quale rappresenta una
specializzazione della KVM per i processori ARM. Essa consente un cospicuo aumento
di prestazioni dovuto all’adattabilità della compilazione a scapito di un ridotto aumento
del fabbisogno di memoria. Infine possiamo citare la CVM, C Virtual Machine,
9
progettata per supportare tutte le caratteristiche di J2SE e destinata, per tale ragione, ai
dispositivi con consistenti risorse hardware.
1.2.2 Configurazioni
Le configurazioni definiscono un insieme di API base che accomunano una serie di
dispositivi simili dal punto di vista hardware. Tali dispositivi possono essere, in realtà,
abbastanza differenti tra loro, ma sono tutti caratterizzati dall’avere alcune peculiarità
molto simili. Ad esempio la memoria disponibile, il tipo di processore e le network
capability, possono essere le stesse malgrado i differenti fattori di forma o gli ambiti
applicativi più disparati. Quindi le configurazioni hanno ragion d’essere nell’intento di
stabilire comunione tra diverse famiglie di dispositivi equipollenti, mediante la
realizzazione di un “core API” invariante da dispositivo a dispositivo.
Poiché il livello di configurazione poggia direttamente sulla JVM, può essere necessario
contemplare alcune dipendenze di basso livello, ad esempio una configurazione
potrebbe richiedere operazioni floating-point che alcune JVM, tra cui KVM, non
supportano. Ogni macchina virtuale coerente con una siffatta configurazione deve
quindi supportare gli oggetti float e double.
Quindi la configurazione oltre ad escludere API fortemente dipendenti dalla specifica
piattaforma, definisce i requisiti della macchina virtuale su cui poggia. Il concetto non
deve destare ambiguità: anche se configurazione e macchina virtuale sono strettamente
accoppiate, esse restano ben distinte.
Nonostante una configurazione sia generalmente distribuita assieme ad una macchina
virtuale, la prima non è necessariamente legata alla seconda e può funzionare con
qualsiasi JVM che sposa i suoi bisogni. La tabella 1.1 mostra le configurazioni correnti
di J2ME. In essa è indicata la versione e il numero della Java Specification Request
(JSR) definito dalla Java Community Process (JCP) [JCP].
Tecnologia
Descrizione
Release
CLDC v. 1.1 JSR-139
Connected Limited Device Configuration,
Marzo 2003
per dispositivi quali telefoni cellulari.
CDC v. 1.0a JSR-36
Connected Device Configuration, fornisce un
Agosto 2002
ambiente più esteso per dispositivi più complessi.
Tabella 1.1 - Le principali configurazioni J2ME attualmente disponibili
10
1.2.3 Profili
I profili differiscono dalle configurazioni poiché focalizzano l’attenzione su specifici
gruppi di dispositivi il cui denominatore comune è l’adesione completa ad una data
configurazione. Ad esempio il profilo MIDP (Mobile Information Device Profile),
specifico per i telefoni cellulari, differisce dal profilo PDA dedicato ai primi palmari,
ma entrambi poggiano sulla stessa configurazione (CLDC).
Le configurazioni, quindi, forniscono le funzionalità di base, mentre i profili supportano
funzionalità molto specifiche della particolare famiglia di dispositivi per cui sono stati
concepiti.
Con tale approccio modulare è possibile includere specificità in un programma
preservando la genericità delle funzionalità di base. Ciò favorisce un processo di
portabilità che, anche se non è immediato, è altamente flessibile: la migrazione di un
programma da una famiglia di dispositivi ad un'altra, consente il riuso del codice
prodotto usando una configurazione comune e impone la riscrittura del solo codice
specifico per il dispositivo, mediante l’utilizzo di un opportuno profilo.
Inoltre è possibile utilizzare profili opzionali per aggiungere funzionalità non disponibili
in quello standard. Ad esempio il profilo RMI aggiunge la funzionalità di Remote
Method Invocation alle funzionalità di base del profilo a cui si affianca. La tabella 1.2
mostra alcuni profili correnti e quelli futuri.
Tecnologia
Descrizione
MIDP v. 2.0 JSR-118
Estende la configurazione CLDC con classi Novembre
abstract per le UI e per il Networking.
Release
2002
Foundation Profile v. Estende CDC, richiede almeno un profile Marzo 2001
1.0JSR-46
addizionale per essere completo.
Personal Profile v. 1.0 Profilo per piccoli devices che sostiuisce Settembre 2002
JSR-62
Personal Java 1.1.x e 1.2.x.
RMI Profile v.1.0 JSR- Fornisce il supporto opzionale RMI.
Giugno 2002
66
PDA Profile JSR-75
Profilo più completo rispetto a MIPD, si ICDO
poggia su CLDC ed è destinato ai PDA.
Game Profile JSR-134
Pensato per lo sviluppo di giochi sul J2ME ICDO
environment
Tabella 1.2 – Alcuni profili disponibili e altri in corso d’opera (ICDO).
11
Le informazioni presenti nelle tabelle 1.1 e 1.2, sono aggiornate al marzo 2004.
Ulteriori informazioni sullo stato dei lavori e la descrizione delle specifiche, sono
reperibili al sito http://www.jcp.org/.
1.3 CLDC e CDC
Ci sono soltanto due configurazioni che coprono un largo range di famiglie di
dispositivi. Un numero così esiguo evita confusione, ma soprattutto limita fortemente la
ridondanza.
La prima è la Connected Limited Device Configuration (CLDC), essa è rivolta a
dispositivi piuttosto limitati, piccoli e di solito wireless, quali, ad esempio, telefoni
cellulari e PDA con limitate caratteristiche hardware.
La seconda configurazione è la Connected Device Configuration (CDC), che si rivolge
ai dispositivi aventi risorse tali da poter essere in grado di supportare un ambiente Java
quasi completo. La CDC rappresenta, quindi, una alternativa per quei dispositivi, come
navigatori satellitari o PDA di ultima generazione, che hanno maggiore capacità in
termini di memoria e velocità di elaborazione. I dispositivi che utilizzano la CDC hanno
inoltre la caratteristica di non dover essere necessariamente limitati dal punto di vista
dell’alimentazione ed hanno, in genere, una larghezza di banda consistente.
1.3.1 Confronto tra le configurazioni
La CDC è stata implementata mediante la realizzazione di API che formassero un
insieme più ampio che include l’insieme delle API della configurazione CLDC. Tale
scelta favorisce la portabilità delle applicazioni CLDC-based, infatti se si intende
portare un programma da CLDC a CDC, non è necessario modificare il codice
dipendente dalla configurazione.
CDC nasce, a sua volta, come un sottoinsieme dell’intero J2SE environment, differendo
da esso principalmente per l’assenza di vere e proprie API client-specific (AWT). In
aggiunta vi sono però classi addizionali, nel package javax.microedition, allo scopo di
fornire codice specifico per i client mobili.
La figura 1.2 mostra le relazioni di inclusione e di non appartenenza discusse, mediante
approccio insiemistico.
12
J2SE
CDC
CLDC
Figura 1.2 – Relazione tra gli environment CLDC, CDC, J2SE: da intendersi in senso lato.
CDC offre, come già detto, un ambiente Java quasi completo. Di seguito sono riportati
alcuni package di J2SE 1.3 non presenti nella configurazione CDC:
ü java.applet
ü java.awt.*
ü java.rmi.*
ü java.sql
ü javax.sound.*
ü javax.swing.*
Alcuni package non presenti nelle configurazioni sono forniti con i profili, mentre le
funzionalità tipo AWT sono incapsulate in profili specifici di interfaccia. Uno degli
equivoci più comuni è affermare che nella configurazione CDC sono presenti tutte e
sole le funzionalità di base che si trovano in J2SE. Niente di più falso: molti package
della configurazione CDC sono stati ridotti in numero di classi e in complessità di
queste ultime, l’environment CDC è più completo rispetto a quello offerto da CLDC,
ma resta sempre ottimizzato per poter afferire ad un ambito limitato.
1.3.2 Dettagli di CLDC
Le API appartenenti alla configurazione CLDC, sono state prodotte, come già
accennato, mediante un processo di riduzione delle API standard di J2SE, basato
sull’eliminazione e sulla ottimizzazione in termini di complessità. Nessuna classe e
nessun metodo sono stati aggiunti alle API base che la configurazione condivide con
13
J2SE, mentre il codice specifico, per CLDC , è stato inserito nel package
javax.microedition, proprio di J2ME.
CLDC ha due obiettivi supplementari, specifici per le famiglie di dispositivi cui è
destinata. Infatti molti di questi dispositivi, tra cui i telefoni cellulari, sono stati a lungo
limitati dalle funzionalità iniziali fornite con il device al momento della vendita, stiamo
parlando dell’OEM (Original Equipment Manufacturer). Un primo obiettivo è, quindi,
aggiungere flessibilità ad un dispositivo, in modo da adattarlo ai nuovi bisogni dei suoi
utilizzatori. Ciò rimuove i confini concernenti la staticità delle funzionalità del
dispositivo ed offre un concreto sbocco al concetto di updating.
Il secondo obiettivo è una diretta conseguenza del primo ed è il nascere di terze parti in
grado di sviluppare applicazioni per i dispositivi che supportino la configurazione
CLDC, creando di fatto un modo per accedere ad un mercato precedentemente
irraggiungibile.
A guidare la selezione di una configurazione, per una famiglia di dispositivi, sono le
capability della stessa che prescindono da fattori, quali ad esempio, l’interfaccia utente.
I requisiti di base, che un dispositivo deve possedere per supportare la CLDC, sono
davvero esigui se confrontati con quelli posseduti da un desktop computer, tra i
principali possiamo elencare i seguenti:
•
da un minimo di 160kb fino a giungere a 512kb di memoria totale;
•
processori a 16 o 32 bit con un clock di almeno 16MHz;
•
128kb di memoria non volatile destinata a contenere la JVM e le librerie CLDC;
•
32kb di memoria volatile per il Java Runtime, questo include lo stack e ogni
applicazione caricata a tempo di esecuzione;
•
bassi consumi e alimentazione a batterie;
•
connessione di rete, di solito wireless, che può essere intermittente e con vincoli
di banda stringenti (anche meno di 9600bps).
Il fattore chiave è la memoria: essa definisce i confini tra le famiglie di dispositivi che
usano la configurazione CLDC e quelle che usano la CDC.
La natura limitata della configurazione CLDC impone alcuni vincoli sia sul linguaggio
Java, sia sulla macchina virtuale, su cui poggia la configurazione stessa. Esploriamo, di
seguito, tali limitazioni nel dettaglio.
14
1.3.2.1 Differenze di linguaggio
La sintassi del linguaggio Java è rimasta invariata, le differenze nel linguaggio
riguardano principalmente la riduzione e l’eliminazione delle API. Riportiamo di
seguito queste ultime:
o Gruppi di thread: il supporto ai thread continua ed essere fornito e anzi, risulta
essere particolarmente utilizzato sui piccoli dispositivi. Ciò che è stato
sottoposto ad eliminazione è il supporto ai gruppi di thread, anche perché la
limitata natura del device consente di supportare generalmente solo pochi
thread.
o Oggetto finalization: in ogni classe in ambiente Java standard, è possibile
definire un metodo finalize, il quale, un istante prima che l'oggetto venga
eliminato dal garbage collector, è richiamato dalla JVM per rilasciare ogni altra
risorsa allocata all’oggetto oltre alla memoria (ad esempio file aperti o
connessioni socket). Tale funzionalità è stata rimossa poiché complica
notevolmente il processo di garbage collection.
o Weak references: tali funzionalità consentono al programmatore di segnalare alla
JVM che un dato oggetto può essere sottoposto a garbage collection. Anch’esse
sono state eliminate poiché complicano la garbage collection.
o Numeri floating-point: gli oggetti floating-point, double e float, sono stati
rimossi nella configurazione CLDC. Questo può sembrare strano, ma c’è da
osservare che, il supporto ai numeri floating-point è assente nella maggior parte
dei piccoli device e che, una emulazione software, sarebbe troppo costosa.
o Serialization: essa consente la conversione di un oggetto Java residente in
memoria, in una successione di byte. Tale tecnica è molto utilizzata quando
occorre trasferire oggetti attraverso la rete. Gli oggetti che possono essere
serializzati implementano l’interfaccia serializable ed includono solo oggetti che
sono
dichiarati
come
serializzabili.
Nella
configurazione
CLDC
la
serializzazione non è possibile poiché necessita di API a loro volta eliminate.
Conseguentemente funzionalità dipendenti dalla serializzazione, quali ad
esempio la RMI, sono assenti nella CLDC.
o Java Native Interface: la JNI fornisce un approccio standardizzato per accedere
a librerie e applicazioni native. La richiesta di memoria, necessaria per tale
funzionalità, preclude la sua implementazione nei dispositivi CLCD-based.
15
o Reflection: Le reflection API forniscono un modo molto flessibile per esaminare
oggetti e interagire con essi a runtime. Esse generano meta-informazioni e
consentono ad un programma di interagire dinamicamente con oggetti atempo di
esecuzione. La reflection è particolarmente utile per quei programmi, tipo
debugger, che hanno bisogno di esaminare a tempo di esecuzione lo stato degli
oggetti in memoria. E’ immediato osservare che la reflection aggiunge un
overhead consistente e per questo è stato sottoposta ad eliminazione.
o Eccezioni ed errori: il supporto alle eccezioni e agli errori è presente nella
CDLC, ma il loro numero è stato ridotto come conseguenza dell’eliminazione di
parte delle API. Le classi rimaste continuano a lanciare le stesse eccezioni e
sotto le stesse condizioni, questo per favorire la compatibilità tra J2SE e J2ME.
o AWT e Swing: tutte le API di interfaccia utente sono state rimosse nella
configurazione CLDC: Graphical User Interface API, sono state progettate per
specifiche famiglie di device, nei vari profili.
o Collections: pur implementando le classi Hashtable, Vector, Stack ed
Enumeration , la CLDC non fornisce le API per tutte le collezioni di oggetti,
data la loro vastità.
o Networking e I/O: la configurazione CLDC non fa nessuna assunzione riguardo
la natura delle connessioni di rete, per cui molte networking API non sono
incluse in tale configurazione. Al loro posto è stato introdotto un framework di
connessione generica.
o Sicurezza: il modello di security della J2SE è molto complesso, richiede molto
spazio fisico e consistente tempo di CPU, per tale motivo le security API hanno
subito una drastica riduzione. Quest’ultima ha portato all’impiego di un modello
di sicurezza in J2ME semplificato che prende il nome di sandbox model.
1.3.2.2 Differenze nelle Virtual Machine
Molti dei cambiamenti della configurazione CLDC, sono il risultato delle limitazioni
imposte dal tipo di dispositivo e dalle capability dei livelli sottostanti. La macchina
virtuale, di conseguenza, è stata modificata per aderire al modello semplificato.
Analizziamo i cambiamenti:
o Nessun class loader definito dall’utente: le classi Java sono caricate a runtime
mediante class-loader. La VM possiede un class-loader di default ma, in J2SE,
16
è possibile creare un loader costruito interamente in Java. Quest’ultimo può
essere caricato dal loader di default ed essere utilizzato per caricare le classi in
modo ottimizzato. Nell’environment J2ME ciò non è consentito, inoltre il classloader di default non consente il caricamento di quegli oggetti che tentano di
fare l’override delle API base.
o Assenza di verifica dei classfile: ogni classfile Java, caricato dalla macchina
virtuale, è sottoposto a verifica prima di essere utilizzato. Tale azione assicura la
correttezza del bytecode e previene tentativi di caricare codice malizioso. Per
diminuire l’overhead conseguente, il processo di verifica è stato ottimizzato
grazie all’utilizzo di un preverificatore.
o Nessun supporto diretto per il Java environment/application setup: la CLDC non
fornisce supporto alcuno per il controllo dell’installazione di nuove applicazione
e per la loro esecuzione. Tale supporto è invece realizzato in un modo devicespecific dipendente, quindi, dall’implementazione J2ME per il dato device.
L’Application Management Software (AMS) abilita l’utente finale a caricare,
eseguire e rimuovere applicazioni J2ME sul dispositivo su cui è installato
o Preloading e prelinking: le classi possono essere prelinkate e immagazzinate su
memoria non volatile per un caricamento più veloce.
17
In tabella 1.3 sono illustrati i packages facenti parte della configurazione CLDC,
accompagnati da una breve descrizione.
Package
Funzione
java.io
Consente la lettura e la scrittura dei flussi di di
classi:
11
interfacce: 5
eccezioni: 5
java.lang
classi:
I/O. Non supporta le classi BufferedStream ma
fornisce 5 implementazioni delle classi astratte
InputStream e OutputStream.
Fornisce classi che sono il cuore del linguaggio
15
interfacce: 1
Java. Nel package sono inclusi gli oggetti
System, Thread e Runtime e la classe Math.
eccezioni: 19
java.util
classi:
Contiene utility per la manipolazione delle
7
interfacce: 1
informazioni di data e ora e supporta le Java
Collection di base.
eccezioni: 2
javax.microedition.io
E’ l’unico package specifico: implementa
classi:
classi supplementari di I/O e fornisce le
1
interfacce: 8
funzionalità del package java.net di J2SE.
eccezioni: 1
Tabella 1.3 – I package di CLDC v.1.0 (JSR-30 – Release maggio 2000).
1.3.3 Dettagli di CDC
La configurazione CDC è rivolta a quei dispositivi maggiormente performanti rispetto
ai dispositivi a cui è rivolta la CLDC, come ad esempio i PDA di ultima generazione.
Anche la CDC ha un insieme di API che è stato sottoposto a riduzione, ma include una
vasta collezione di classi derivanti dall’ ambiente J2SE. La configurazione CDC si
propone, quindi, di colmare il gap esistente tra la CLDC e la versione standard di Java,
mantenendo la piena compatibilità verso il basso, attraverso la riproposizione di tutte le
classi della configurazione CLDC.
E’ importante tener presente che CDC è stata progettata rivolgendo particolare
attenzione all’interoperabilità con Personal Java. In tal modo, le applicazioni che
correntemente girano su Personal Java, possono essere facilmente trasportate
nell’environment CDC, mediante utilizzo di profili appropriati.
18
I requisiti di base, che un dispositivo deve possedere per supportare la CDC si possono
riassumere, nei seguenti:
•
Più di 2Mb di memoria totale disponibile per il Java environment;
•
Processori a 32 bit
•
Connessione di rete, spesso wireless, che può essere intermittente e con vincoli
di banda non molto stringenti.
•
Una Java Virtual Machine completa, che supporti tutte le funzionalità standard.
Così come la CLDC è generalmente accoppiata al profilo MIDP, di cui parleremo tra
breve, la CDC si accompagna ad un profilo che complementa la sua configurazione
base. Tale profilo, il foundation profile, non include le GUI API che sono viceversa
fornite a mezzo di profili opzionali. La configurazione CDC è distribuita assieme alla
CVM (C Virtual Machine). Essa è una JVM completa, supporta tutte le funzionalità
tipiche di ogni JVM standard ed è perciò profondamente diversa dalla KVM.
Conseguenza dell’impiego della CVM è il fatto che i vincoli sulla CDC riguardano solo
il linguaggio e non la virtual machine.
1.3.3.1 Differenze di linguaggio
Anche nella configurazione CDC la sintassi del linguaggio Java è rimasta invariata, le
differenze di linguaggio, dovute al processo di riduzione delle API, sono, in tale
configurazione, più esigue che nella CLDC. Di seguito sono riportate le principali
differenze tra le due configurazioni in merito al linguaggio. Anticipiamo il fatto che
molte delle limitazioni presenti in CDLC non hanno ragione di esistere in tale ambito:
o Gruppi di thread: poiché i requisiti minimi dei dispositivi che supportano la
configurazione CDC, sono considerevolmente più robusti, rispetto al caso dei
dispositivi CLDC-based, i gruppi di thread prendono posto in tale
configurazione.
o Oggetto finalization: la finalization era stata rimossa dalla CLDC per via
dell’overhead insostenibile per i dispositivi cui la configurazione era destinata e
perché complicava la garbage collection da parte della sottostante JVM. Visto
che la CDC è rivolta a dispositivi più performanti e che la macchina virtuale su
19
cui poggia è conforme allo standard Java per le JVM, la configurazione CDC
supporta l’oggetto finalization.
o Weak references: la CDC rimuove tale limitazione e anzi, supporta l’intero
package java.lang.ref che contiene, tra l’ altro, la weak reference.
o Numeri floating-point: diversamente da quanto accade per la CLDC, il supporto
ai numeri floating-point è fornito nella CDC. Questo grazie alle maggiori
potenzialità disponibili nei dispositivi a cui è rivolta la configurazione e
all’impiego della CVM, la quale supporta i tipi double e float.
o Serialization: la serializzazione non è stata sacrificata all’interno della
configurazione CDC. Tale funzionalità è, anzi, necessaria in una architettura più
flessibile rispetto alla CLDC e la sua implementazione è resa possibile grazie
alle caratteristiche fisiche dei dispositivi cui la configurazione CDC stessa è
rivolta.
o Java Native Interface: la configurazione CDC implementa la JNI, ma non solo.
Essa supporta anche altre interfacce quali l’ interfaccia di debug (JVMDI) e la
profiling interface (JVMPI). Queste tre interfacce, si basano su interfacce C e
poiché la CVM del livello sottostante è scritta in C, il loro mantenimento nella
configurazione è stato possibile.
o Reflection: la configurazione CDC supporta le reflection API, diversamente da
quanto accade nella CLDC. Tali API sono contenute nel package
java.lang.reflect.
o Eccezioni ed errori: in CDC sono contenuti errori ed eccezioni in numero minore
rispetto al J2SE environment. Tale numero è, d’altra parte, maggiore rispetto al
caso CLDC, ciò è una conseguenza del maggior numero di API che trovano
posto in tale configurazione.
o AWT e Swing: così come accade per la CLDC, le API di interfaccia utente sono
state rimosse nella configurazione CDC: il compito è delegato ai profili. Come
vedremo tra breve, il Personal Profile prevede le stesse funzionalità presenti in
Personal Java, tra cui l’implementazione di API AWT-based.
o Collections: nella configurazione CDC è presente un supporto completo alle
collezioni di oggetti.
o Networking e I/O: la CDC contiene un insieme di I/O API molto più espanso
rispetto alla CLDC. Inoltre è implementato un sottoinsieme delle API del
package java.net di J2SE. CLDC fornisce il solo package javax.microedition.
20
o Sicurezza: è presente in CDC il modello di security della J2SE, anche se,
ovviamente, in forma ridotta. La CLDC, diversamente, supporta solo un modello
semplificato di sicurezza.
In tabella 1.4 sono illustrati i package facenti parte della configurazione CDC insieme
con una breve descrizione delle funzionalità che questi offrono:
Package
java.io
Funzione
Consente la lettura e la scrittura dei flussi di di I/O.
Tale package contiene molte delle classi omesse in
CLDC.
classi:
36
interfacce: 10
eccezioni: 16
java.lang
Fornisce classi che sono il cuore del linguaggio Java.
Nel package sono inclusi gli oggetti System, Thread
e Runtime. Inoltre sono incluse le classi Double e
Float.
Contiene i reference types tra cui weak refernces.
classi:
30
interfacce: 3
eccezioni: 24
java.lang.ref
classi:
5
interfacce: 0
eccezioni: 0
java.lang.reflect
Fornisce le API di reflection
classi:
8
interfacce: 2
eccezioni: 2
java.math
Contiene la sola classe BigInteger e i metodi per
lavorare con oggetti del tipo BigInteger.
classi:
1
interfacce: 0
eccezioni: 0
java.net
Sottoinsieme dell’omonimo package di J2SE.
Consente
connessioni
http
url-based
e
comunicazioni connectionless con datagrammi.
classi:
12
interfacce: 5
eccezioni: 6
java.security, java.security.cert
Supporta le funzionalità di sicurezza
classi:
21
interfacce: 6
eccezioni: 13
java.text, java.text.resources
classi:
11
interfacce: 0
eccezioni: 1
java.util,
java.util.zip
Fornisce caratteristiche di internazionalizzazione per
il supporto di lingue multiple
java.util.jar, Contiene ultilities per la manipolazione di data e ora
e implementa le java collections di base.
classi:
44
interfacce: 11
eccezioni: 7
javax.microedition.io
Implementa classi supplementari di I/O
classi:
1
interfacce: 8
eccezioni: 1
Tabella 1.4 – I packages di CLC v.1.0 (JSR-36 – Release marzo 2001).
Allo scopo di dare un’idea al lettore di quanto siano distanti le configurazioni CLDC e
CDC, dalle API base dell’ambiente J2SE, riportiamo di seguito la tabella 1.5 che mostra
21
i package di J2SE v.1.3.1, di CLDC v.1.0 e CDC v.1.0. Per ciascun package è indicato
il numero di classi, di interfacce e di eccezioni:
J2SE
CDC
CLDC
Package
C
I
E
C
I
E
C
I
E
java.io
50
10
16
36
10
16
11
2
5
java.lang
31
3
24
30
3
24
15
1
19
java.lang.ref
5
-
-
5
-
-
-
-
-
java.lang.reflect
8
2
2
8
2
2
-
-
-
java.math
2
-
-
1
-
-
-
-
-
java.net
21
6
8
12
5
6
-
-
-
java.security
39
9
15
19
6
11
-
-
-
java.security.cert
8
1
6
2
-
2
-
-
-
java.text
20
2
1
11
-
1
-
-
-
java.util
36
13
5
32
11
4
7
1
2
java.util.jar
7
-
1
6
-
1
-
-
-
java.util.zip
14
1
2
6
-
2
-
-
-
-
-
1
8
1
1
8
1
Javax.microedition.io -
Tabella 1.5 – Java Environment a confronto (C - Classi; I - Interfacce; E - Eccezioni).
22
1.3.4 I Profili nel dettaglio
Per disporre di un ambiente J2ME su di un particolare device, è necessario avere
almeno una virtual machine, una configurazione e un profilo. Profili opzionali possono
poi essere installati per offrire funzionalità aggiuntive.
I profili realizzano la specificità, necessaria all’ambiente, attraverso tre strade:
•
Fornendo il supporto alle GUI
•
Consentendo la persistenza
•
Implementando le Abstract Networking API, della configurazione sottostante.
Data la flessibilità che i profili conferiscono all’architettura J2ME, vi sono molteplici
progetti che sono stati portati a termine, per sposare le necessità di svariate famiglie di
dispositivi, e altri in corso d’opera.
Di seguito riportiamo alcuni profili CLDC – based, corredati da una breve descrizione:
o Mobile Information Device Profile (MIDP): è il primo reso disponibile dalla
Sun, esso fornisce la GUI ed altre funzionalità proprie dei dispositivi mobili,
quali i telefoni cellulari. Il MIDP è anche disponibile per i palmari PalmOS.
o Personal Digital Assistano Profile (PDAP): ancora in via di sviluppo, tale
profilo sostituirà il MIDP sui PDA, adattandosi all’hardware e alla interfaccia
utente propria dei palmari.
o Altre API: tra i profili opzionali per la configurazione CLDC, evidenziamo:le
API relative alla riproduzione di popolari formati audio: Mobile Media API
(JSR-135) ; le API per il supporto dello standard Bluetooth e le API USB
(Universal Serial Bus).
Elenchiamo ora alcuni profili basati sulla configurazione CDC:
o Foundation Profile: forma uno strato indispensabile per molti profili CDCbased. Tale profilo è il primo ufficialmente rilasciato dalla Sun per la
configurazione CDC.
o Personal Bases Profile: implementa le funzionalità di base per il Personal
Profile. Esso non fornisce compatibilità con l’ambiente Personal Java.
23
o Personal Profile: completa il Personal Bases Profile apportando piena
compatibilità con Personal Java.
o Altri profili: tra quelli opzionali citiamo il profilo RMI (Remote Method
Invocation), le Mobile Media API (JSR-135) e il Game Profile. Quest’ultimo
richiede l’impiego del Foundation Profile e non è stato ancora portato a termine.
1.3.4.1 Il profilo MIDP
Il Mobile Information Device Profile, è in assoluto il profilo più diffuso, essendo tra
l’altro orientato a dispositivi, come i telefoni cellulari, che hanno una diffusione quasi
capillare nei paesi industrializzati.
Le funzionalità che il MIDP apporta alla configurazione su cui poggia, la CLDC, si
possono riassumere nelle seguenti:
•
GUI di basso livello;
•
Persistenza;
•
Connettività di rete HTTP-based;
•
Supporto temporale alle applicazioni;
•
Gestione del ciclo di vita delle applicazioni (MIDlet).
Le API introdotte nel profilo, basate sull’implementazione delle precedenti aree chiave,
completano i package della CLDC e ne formano di nuovi.
I requisiti dei dispositivi che sposano il profilo MIDP sono quelli della configurazione
CLDC, in aggiunta essi devono avere:
•
Un piccolo display;
•
Un modo per fornire input al device, ad esempio una piccola tastiera o un touch
screen;
•
Memoria non volatile sufficiente a contenere, oltre alla macchina virtuale e alla
configurazione, anche il profilo. In realtà i 128k, indicati come requisito della
CLDC, possono essere sufficienti allo scopo;
•
Almeno 8k di memoria di memoria non volatile per l’archiviazione dei dati delle
applicazioni;
24
Nella tabella 1.6 sono riportati i package del profilo MIDP 1.0 con la sola descrizione
delle funzionalità aggiunte alla configurazione CLDC.
Package
Funzione
java.io
Invariata rispetto alla CLDC.
java.lang
Identica alla CLDC con la sola aggiunta dell’ eccezione
IllegalStateException.
java.util
Aggiunge i timer e un modo standardizzato per schedulare
task da eseguirsi in background o in maniera pianificata.
javax.microedition.lcdui
Fornisce GUI APIs high-level e low-level.
javax.microedition.rms
Il package Record Management System aggiunge il
supporto per la persistenza per le Midlet.
javax.microedition.midlet
Definisce l’interfaccia midlet.
javax.microedition.io
Aggiunge una connessione http.
Tabella 1.6 – Package inclusi nel profilo MIDP.
Dei precedenti, descriviamo solo il package che definisce l’interfaccia Midlet:
javax.microedition.midlet
Il termine MIDlet deriva da Mobile Information Device e dal termine Applet.
Quest’ultima si riferisce alla tecnologia web-based che per prima ha catalizzato
l’attenzione sul linguaggio Java.
Le midlet, quindi, devono il loro nome alla similitudine con le applet e come queste, le
interfacce MIDlet definiscono le classi necessarie per la gestione del ciclo di vita delle
applicazioni MIDP.
La partenza e la terminazione reale di una midlet non sono manipolate dall’utente finale:
così come accade per un’applet che è gestita da un web browser, esiste una applicazione
ospite che gestisce il ciclo di vita di una midlet. Tale applicazione è l’ Application
Manager Software (AMS), esso è platform-specific e interagisce con le midlet
attraverso i metodi definiti nell’interfaccia MIDlet.
25
L’AMS facilita l’interazione tra l’applicazione MIDP e il sottostante Java runtime,
attraverso la gestione del caricamento, l’inizializzazione e la terminazione delle midlet.
Questo
significa
che
le
responsabilità
del
programmatore
finiscono
con
l’implementazione della classe astratta MIDlet.
Il package javax.microedition.midlet definisce una sola classe: la Midlet class. Essa
contiene tutti i metodi, necessari all’ambiente Java del dispositivo, per lanciare,
sospendere e terminare tutte le midlet caricate. Attraverso l’interfaccia MIDlet è
possibile definire gli stati in cui la midlet stessa può trovarsi e fornire i callback method
all’ AMS che controlla le transizioni tra stati.
Gli stati in cui una midlet può trovarsi sono tipicamente: active, paused e destroyed.
Al momento della creazione di una midlet, essa si trova nello stato di pausa e in tale
stato ritorna ogni qualvolta l’AMS decide che la midlet non ha bisogno di essere attiva.
Si passa allo stato attivo, quando l’AMS chiama il metodo startApp della midlet. Infine,
quando una midlet non è più in memoria, il sistema di gestione chiama il metodo
destroyApp della midlet.
Una eccezione MIDletStateChangeException può essere lanciata se si verifica un errore
di transizione tra gli stati.
Active
pauseApp()
destryApp()
startApp()
Paused
Destroyed
constructor
Figura 1.3 – Ciclo di vita di una MIDlet: transizioni degli stati.
26
1.4 Sviluppo di applicazioni J2ME
Per sviluppare le applicazioni rivolte all’ambiente J2ME, ci si può avvalere dell’uso di
toolkit, disponibili gratuitamente su internet.
In tale ambito, riveste particolare
importanza il J2ME Wirelss Toolkit, messo a disposizione dalla Sun e reperibile al sito
http://java.sun.com/j2me/download.html.
La versione corrente del J2MEWT è la 2.0 che ha la particolarità di supportare il MIDP
2.0. Dalla pagina web precedente, è inoltre possibile scaricare le configurazioni e i
profili di interesse, al fine di costruire un ambiente J2ME completo e adatto ai propri
scopi.
Riportiamo di seguito i file che è possibile scaricare dal sito della Sun, in riferimento
alla tecnologia J2ME:
Wireless Toolkit
§
Wireless Toolkit 2.0
CLDC Technology
§
Connected Limited Device Configuration (CLDC) 1.1
§
Connected Limited Device Configuration (CLDC) 1.0.4
§
Mobile Information Device Profile (MIDP) 2.0
§
Mobile Information Device Profile (MIDP) 1.0.3
§
Optional Package
§
Mobile Media API for J2ME
§
Wireless Messaging API
CDC Technology
§
Connected Device Configuration (CDC) and Foundation Profile 1.0
§
J2ME Personal Basis Profile 1.0
§
J2ME Personal Profile 1.0
§
J2ME Personal Profile Runtime Environment
§
Optional Package
§
J2ME RMI Optional Package
27
Capitolo 2
Le Virtual Machine CDC
La configurazione CDC, Connected Device Configuration, è stata introdotta nell’ambito
del progetto modulare di J2ME, il quale è organizzato in configurazioni e relativi
profili.
Essa si rivolge ai quei dispositivi le cui caratteristiche hardware consentono di
supportare un ambiente Java completo, per cui l’insieme di API di CDC, pur essendo
stato sottoposto ad un processo di riduzione, include una vasta collezione di classi
derivanti dall’ ambiente J2SE. Tale configurazione, completata dall’insieme delle classi
contenute nei profili e da una JVM, costituisce un ambiente Java completo.
Per macchine virtuali CDC intendiamo quelle macchine che offrono un ambiente Javacompliant1 oppure un ambiente Java-based. Il primo si riferisce ad un ambiente
conforme allo standard Java della Sun. Il secondo, invece, si riferisce ad un ambiente,
destinato alla stessa classe di dispositivi a cui si rivolge la CDC, il cui linguaggio abbia
una sintassi Java ma le cui API siano completamente ridefinite e potenzialmente
incompatibili con le API standard di Java.
Nei paragrafi successivi descriveremo le seguenti macchine virtuali:
Java-compliant
ü Jeode PDA Edition;
ü CrEme versione 4.0
Java-based
ü SuperWaba versione 4.11
ü Ewe versione 1.3
1
la configurazione CDC è stata progettata rivolgendo particolare attenzione all’interoperabilità con
Personal Java.
28
2.1 Jeode
La prima piattaforma Jeode prodotta dalla Insigna, per i sistemi basati su WindowsCE,
supportava le specifiche Personal Java e Embedded Java della Sun. Essa ebbe infatti
superato i relativi test di compatibilità diventando una Java Virtual Machine autorizzata.
La macchina virtuale Jeode PDA Edition rappresenta invece, una implementazione
certificata della specifica Personal Java 1.2 di Sun.
La piattaforma fornisce un vero e proprio ambiente di sviluppo affiancando al Jeode
Runtime, alcuni tool di sviluppo che aiutano il programmatore nell’implementazione e
nella configurazione delle proprie applicazioni, in modo da aderire alle specifiche
imposte dalle limitazioni dei piccoli dispositivi. Il Runtime è composto dalla Virtual
Machine (EVM) e dall’insieme delle classi che l’ambiente fornisce.
2.1.1 Disponibilità
Il runtime di Jeode è disponibile per varie tipologie di processori e di sistemi operativi.
Tra i primi assumono rilievo: x86, MIPS, ARM, Hitachi SH e PowerPC. Mentre
l’insieme dei sistemi operativi che supportano il runtime, include tra gli altri:
WidowsCE, PocketPC, Linux, VxWorks, Windows, WindowsNT Embedded e Itron.
Infine il runtime è stato integrato, come plug-in, nei browser per WindowsCE,
PocketPC e WindowsNT Embedded, in modo da consentire il caricamento e
l’esecuzione delle applet Java.
29
2.1.2 Caratteristiche
Nella tabella 2.1, sono riportate alcune caratteristiche dell’ambiente Jeode, suddivise per
aree chiave:
Virtual Machine
Supportata da molte piattaforme hardware
Sofisticata combinazione di interpretazione e compilazione
Garbage Collection di tipo concorrente
Consente le creazione di librerie native C
Supporto completo ai thread, alle eccezioni, e ai tipi double e long
Input/Ouput
Supporto per il protocollo TCP/IP, UDP
Supporto per serial port, socket API
User Interface
Supporto per le AWT
Tabella 2.1 – Caratteristiche salienti della piattaforma Jeode.
Le caratteristiche di maggiore interesse della piattaforma, sono quelle che riguardano la
macchina virtuale. La Jeode Embedded Virtual Machine (EVM) ottimizza le prestazioni
delle applicazioni attraverso:
ü una speciale tecnica di generazione del codice nativo;
ü un’implementazione concorrente della garbage collection.
ü un’implementazione completa dei thread (green model).
La macchina virtuale realizzata dalla Insigna implementa una tecnologia ADC, Adaptive
Dynamic Compilation. Essa prende spunto dalla tecnologia di compilazione JIT (Just In
Time), ma differisce da essa in quanto richiede meno memoria, non fa uso di memoria
virtuale e compila dinamicamente solo il codice che rappresenta il corrente collo di
bottiglia per le prestazioni dell’applicazione, cioè solo il codice ritenuto critico per il
programma in esecuzione. La restante parte di codice è tradotto mediante
interpretazione, come mostrato in figura 2.1.
30
Figura 2.1 – La tecnologia ADC implementata da Jeode.
Quando un’applicazione viene lanciata, la traduzione del codice è realizzata mediante
interpretazione, in tal modo, rispetto alla compilazione JIT, si riduce il tempo di startup. Successivamente la macchina virtuale determina i segmenti di codice che occorrono
più di frequente, li compila e li memorizza in un buffer di memoria.
La garbage collection è cruciale in quanto, tale è la gestione della memoria, specie per i
dispositivi aventi consistenti limitazioni hardware. La Jeode EVM implementa una
tecnologia concorrente che è in grado, tra l’altro, di evitare la frammentazione della
memoria. La realizzazione del garbage collector è realizzata attraverso un thread
prelazionabile, così come la realizzazione del compilatore dinamico-adattativo.
Infine resta da evidenziare il fatto che a ciascun thread Java, la macchina virtuale fa
corrispondere un thread di basso livello nei sistemi operativi real-time, fornendo
integrazione con i thread nativi e sinergia con lo schedulatore del sistema operativo.
Java Thread X
Java Thread Y
RTOS
Task A
Task B
Task C
Figura 2.2 – Java thread su un sistema operativo real-time (RTOS).
31
2.1.3 Ciclo di Sviluppo
Il ciclo di sviluppo di un’applicazione, destinata ad essere eseguita sulla macchina
virtuale Jeode, coincide in pratica, con quello di un’applicazione destinata al Java
runtime.
Di conseguenza è necessario disporre dell’ambiente di sviluppo Java (JDK), sulla
propria macchina [J2SE].
Il ciclo di sviluppo può, quindi, espletarsi nei seguenti passi:
•
Generazione del codice sorgente, della propria applicazione, mediante un editor
di testo o un qualsiasi tool di sviluppo. Bisogna comunque avere l’accortenza di
utilizzare le API messe a disposizione dell’ambiente.
•
Compilazione del file sorgente, attraverso il compilatore java ed eventualmente,
archiviazione delle classi in un archivio “jar”.
•
Creazione del link per l’esecuzione dell’applicazione sulla macchina virtuale.
•
Installazione dei file dell’applicazione, sul dispositivo palmare.
.
32
2.1.4 Le API di Jeode
Le librerie di classi della piattaforma Jeode, che costituiscono le core API, sono quelle
definite nella specifica Personal Java 1.2 e sono descritte in tabella 2.2. Per una
descrizione dettagliata, si rinvia alla documentazione ufficiale, disponibile sul sito della
Sun.
java.lang
Fornisce le classi core del linguaggio Java.
java.util
Contiene classi di utilità.
java.io
Classi base per l’I/O.
java.net
Fornisce un’infrastruttura flessibile per il networking.
java.util.zip
Classi per la compressione e la decompressione dei dati.
java.lang.reflect
Consente ai programmi Java di ispezionare e manipolare oggetti a
runtime.
java.math
Fornisce i tipi long, float e double.
java.text
Consente la conversione di numeri, data e ora.
Java.rmi
Remote Method Invocation
java.security
Contiene le classi per la crittazione e la computazione di firme digitali
java.sql
Fornisce le classi per la gestione delle interrogazioni ai database.
java.applet
Supporto per l’implementazione delle applet Java
java.awt
Abstract Window Toolkit
Tabella 2.2 – Classi base della piattaforma Jeode.
33
2.2 CrEme
CrEme è una macchina virtuale prodotta dalla NSICom e rappresenta la versione CE di
JSCP, una macchina virtuale Java sviluppata per i sistemi operativi real-time.
Il runtime di CrEme è basato sulla configurazione CDC di J2ME della Sun, corredata
dai profili Foundation Profile e Personal Profile, quindi CrEme è pienamente
compatibile con la specifica Personal Java.
Anche CrEme, così come Jeode, fornisce un vero e proprio ambiente di sviluppo
affiancando al runtime, alcuni tool che aiutano il programmatore nell’implementazione
delle proprie applicazioni, in modo da aderire alle specifiche imposte dalle limitazioni
dei piccoli dispositivi. In particolare è disponibile un emulatore della macchina virtuale
CrEme per computer desktop.
2.2.1 Disponibilità
Il runtime di CrEme è disponibile per varie tipologie di processori e di sistemi operativi.
Tra i primi assumono rilievo: x86, MIPS, ARM, SH3, XSCALE e PowerPC. Mentre
l’insieme dei sistemi operativi che supportano il runtime, include tra gli altri:
WidowsCE, PocketPC, WidowsCE.net, per i restanti è comunque disponibile la Virtual
Machine JSCP.
34
2.2.2 Caratteristiche
Nella tabella 2.3, sono riportate alcune caratteristiche dell’ambiente CrEme, suddivise
per aree chiave:
Virtual Machine
Supportata da molte piattaforme hardware
generazione del codice nativo basata sulla tecnologia Just In Time
Garbage Collection di tipo asincrona
Consente le creazione di librerie native C
Supporto completo ai thread, alle eccezioni, e ai tipi double e long
Input/Ouput
Supporto per il protocollo TCP/IP, UDP
Supporto per serial port, socket API.
User Interface
Truffle (default), tinyAWT, package opzionale Swing
Tabella 2.3 – Caratteristiche salienti della piattaforma CreMe.
Gli aspetti di maggiore interesse della CreMe Virtual Machine sono i seguenti:
ü tecnica di generazione del codice nativo basata sulla tecnologia Just In Time;
ü implementazione asincrona della garbage collection.
ü implementazione dei thread secondo un modello definito “blue threads”
[JSCPTM].
La macchina virtuale CreMe implementa, per la generazione del codice nativo, una
tecnologia JIT (Just In Time), chiamata JBooster; che è in grado di limitare la
compilazione alle porzioni di codice più rilevanti all’interno dei metodi. JBooster
aggiunge in media tra i 100KB e i 200KB ai requisiti di memoria di CreMe, a favore di
un significativo aumento delle prestazioni.
Il garbage collector è implementato attraverso un thread con tre livelli di priorità:
green, yellow e red. Quando i requisiti di memoria sono blandi, il thread in questione
viene eseguito con una bassa priorità, green, e non è prevista alcuna compattazione per
arginare il fenomeno della frammentazione della memoria; al diminuire della
35
disponibilità di memoria il thread cambia la sua priorità diventando yellow; infine
quando la situazione diventa critica il thread assume la priorità più alta, red, ed effettua
la compattazione della memoria. Il motivo di tale soluzione tecnica deriva dal modello
di gestione dei thread, denominato blue threads.
Il modello blue threads prevede che tutti i thread Java siano incapsulati nella Virtual
Machine. Ciò vuol dire che la macchina virtuale CreMe, unitamente a tutte le
applicazioni Java che girano su di essa, sono trattate dal sistema operativo real-time
come un unico task. Uno scenario di tale situazione è mostrato in figura 2.3.
Java Thread X
Java Thread Y
CrEme Task
RTOS
CrEme
Kernel
OS Task A
OS Task B
Java Thread Z
Java Thread U
Java Thread V
OS Task C
OS Task D
Figura 2.3 – Il modello dei thread della piattaforma CreMe.
In altre parole non c’è una corrispondenza biunivoca tra i thread del sistema operativo e
i thread Java, per cui la gestione e la schedulazione di questi ultimi è a carico della
macchina virtuale.
In particolare lo schedulatore di CreMe è senza prelazione ed usa una tecnica di polling.
Esso interroga ciclicamente un timer al fine di determinare la terminazione di un quanto
di tempo. Ciò rende la macchina virtuale più piccola e meno complicata, dal momento
che i cambi di contesto avvengono in istanti di tempo ben determinati e conosciuti dallo
schedulatore, per cui non sono necessari meccanismi di protezione del codice.
36
2.2.3 Ciclo di Sviluppo
Il ciclo di sviluppo di un’applicazione, destinata ad essere eseguita sulla macchina
virtuale CreMe, è molto simile a quello di un’applicazione destinata al Java runtime e
coincide, in pratica, con il ciclo di sviluppo di Jeode.
È necessario anzitutto disporre dell’ambiente di sviluppo Java (JDK), sulla propria
macchina.
Il ciclo di sviluppo può, quindi, espletarsi nei seguenti passi:
•
Generazione del codice sorgente, della propria applicazione, mediante un editor
di testo o un qualsiasi tool di sviluppo. Bisogna comunque avere l’accortenza di
utilizzare le API messe a disposizione dell’ambiente.
•
Compilazione del file sorgente, attraverso il compilatore java ed eventualmente,
archiviazione delle classi in un archivio “jar”.
•
Creazione del link per l’esecuzione dell’applicazione sulla macchina virtuale.
•
Installazione dei file dell’applicazione, sul dispositivo palmare.
37
2.2.4 Le API di CreMe
Le librerie di classi della piattaforma CrEme includono quelle definite nelle specifiche
di Personal Java e offrono, come package opzionale, il supporto alle Swing:
java.lang
Fornisce classi core del linguaggio Java.
java.util
Contiene classi di utilità.
java.io
Classi base per l’I/O.
java.net
Fornisce un’infrastruttura flessibile per il networking.
java.util.zip
Classi per la compressione e la decompressione dei dati.
java.lang.reflect
Consente ai programmi Java di ispezionare e manipolare oggetti a
runtime.
java.math
Fornisce i tipi long, float e double.
java.text
Consente la conversione di numeri, data e ora.
Java.rmi
Remote Method Invocation
java.security
Contiene le classi per la crittazione e la computazione di firme digitali
java.sql
Fornisce le classi per la gestione delle interrogazioni ai database.
java.applet
Supporto per l’implementazione delle applet Java
java.awt
Abstract Window Toolkit
javax.swing
Swing v 1.1.1 (package opzionale)
Tabella 2.4 – Classi base della piattaforma CrEme.
38
2.3 SuperWaba
SuperWaba è una piattaforma Open Source, nata da un progetto brasiliano e finalizzata
allo sviluppo di applicazioni destinate ai palmari,. La sua realizzazione risale agli inizi
del 2000 e rappresenta un’estensione di Waba, una progetto anch’esso open source,
nato inizialmente per applicazioni sui telefoni cellulari e successivamente destinato al
mercato dei PDA.
La piattaforma SuperWaba definisce un linguaggio, una macchina virtuale, un formato
per i class file e un insieme di classi base.
Il linguaggio ha una sintassi Java, di conseguenza gli sviluppatori possono utilizzare il
tool di sviluppo che preferiscono. Sfortunatamente le API di SuperWaba hanno poco in
comune con le API standard di Java, anzi, è necessario precisare che SuperWaba non ha
alcuna relazione con la Sun e non implementa nessuna delle specifiche di Java. Questo
può sembrare, a primo impatto, un consistente freno alla diffusione di SuperWaba, ma
c’è da considerare il fatto che anche le API di J2ME derivano da un processo di
riduzione delle API standard di Java. Ciò è indispensabile date le caratteristiche limitate
dei piccoli dispositivi e obbliga, in ogni caso, il programmatore a conoscere i
sottoinsiemi che derivano da tale processo di riduzione.
Sono molte le ragioni della diffusione di SuperWaba , tra queste spicca il fatto che la
piattaforma è rilasciata con la licenza GNU LGPL che consente, tra l’altro, ai
programmatori di sviluppare applicazioni per fini commerciali.
39
2.3.1 Disponibilità
SuperWaba sposa il concetto “write once, run anywhere ” che ha permesso la diffusione
a larga scala di Java. Le applicazioni realizzate mediante tale piattaforma, possono
essere eseguite sui dispositivi basati su PalmOS e su quelli basati su WindowsCE,
inoltre è possibile anche l’esecuzione su computer desktop, mediante emulatori, e sui
web browser, mediante applet.
Di seguito è riportata una lista di dispositivi su cui è stato verificato il corretto
funzionamento di SuperWaba2:
PalmOS devices
•
AlphaSmart: Dana, Dana.wireless
•
Handspring: Treo 180, Visor Pro (PalmOS 3.5), Visor Platinum, Visor Prism,
Treo 600
•
Palm:
o
Professional, III, IIIx, IIIc, IIIe, V, Vx
o
M105, M500, M505, M515, M125, Palm 130
o
Zire, Zire 71, Zire21
o
Tungsten C, Tungsten W, Tungsten T, Tungsten T2, Tungsten T3,
Tungsten E
•
Samsung: SPH-I330, Kyocera Smartphone 6035, Kyocera 7135
•
Sony CLIE: S300, T-615, S360, TG50, N770C/E, NX70V, NX60, SJ30, SL10,
SJ33, SJ20
•
Symbol: SPT 1500, 1550 and 1700
2
L’assenza di un particolare modello nella lista, non vuol dire che SuperWaba non sia istallabile su di
esso.
40
Windows CE/PocketPC device
•
Compaq: iPaq 3670, iPaq H3970, iPaq 3900, iPaq 2210, iPaq 1910, Pocket PC
Aero 1550
•
Dell: Axim A5, Axim X5
•
HP: Jornada 540 (SH3), Jornada 680/690
•
HTC: Falcon
•
Symbol: PDT8100 (Pocket PC 3.0), PDT8146 (Pocket PC 2002)
•
Toshiba: e350 Intel PXA
•
Vandem: Clio (HPC 2.11) - Installazione manuale, file per MIPS
•
ViewSonic: V35, V37
32-bit Windows
•
Windows 98
•
Windows NT
•
Windows XP
•
Windows 2000
Linux
•
Mediante WINE (Windows Emulator)
41
2.3.2 Caratteristiche
Nella tabella 2.5, sono riportate le principali caratteristiche dell’ambiente SuperWaba,
suddivise per aree chiave:
Virtual Machine
Supportata da molte piattaforme hardware
Consente le creazione di librerie native C
Supporto Unicode
Supporto per i display grayscale (Palm OS 2.0 and up) e colore. Alta risoluzione in tutti i PDA
Supporto ai thread, alle eccezioni, e ai tipi double e long
Extension libraries
Classi per la visualizzazione di informazioni GPS, basate sul protocollo Garmin GPS
Supporto per la lettura dei formati di file PalmoDoc e PalmZip
Supporto per gli algoritmi di crittografia: Blowfish, MD5, SHA1, TEA
Personal Information Abstract Layer (PIMal) : fornisce accesso ai dati PIM su Pocket PC e Palm OS
Game API, che supportano Sprites, buttoni animati, etc.
Input/Ouput
Supporto per il protocollo TCP/IP, serial port, USB, InfraRed, Bluetooth.
Supporto per Secure Digital e Memory Stick card
Supporto per il formato file PDB su Pocket PC, ciò rende i database Palm intercambiabili tra le piattaforme
Database Connectitivity Specification(WDBC): driver per IBM Db2e e PDB SQL manipulation (PDB Driver)
Capabilities di stampa.
User Interface
Due differenti stili per Palm OS e Windows CE.
In entrambi gli stili, tutti i controlli posseggono lo stato di visible e disable
Finestre di popup trascinabili
Posizionamento relativo
Tabella 2.5 – Caratteristiche salienti del SuperWaba Development Kit (SuperWaba SDK).
42
Una caratteristica che va approfondita riguarda la gestione dei thread realizzata da
SuperWaba. La piattaforma implementa un modello molto semplificato dei thread,
infatti essi sono senza prelazione e non forniscono alcun tipo di concorrenza.
Il modello prevede che il metodo run venga invocato ogni volta che il sistema è in stato
di Idle. Una importante conseguenza di tale scelta implementativa è che il metodo run
deve essere il più semplice e veloce possibile, pena il degrado delle prestazioni del
piccolo device o addirittura il blocco della macchina virtuale. Ciò significa che la
semantica del metodo run è cambiata: esso non può avere al suo interno un ciclo
infinito, dovrà essere cura del programmatore fare in modo che questo sia egualmente
implementato considerando che il metodo run dell’oggetto di tipo thread è invocato
ogni volta che il sistema è Idle.
Inoltre ci sono altri due metodi che devono essere sempre presenti anche se non hanno
istruzione al loro interno: started e stopped. Quest’ultimo, in particolare, può essere
invocato per determinare la terminazione thread.
Figura 2.4 -
Alcuni dei componenti dell’ interfaccia utente, in stile Windows CE e Palm OS
rispettivamente (risoluzione 160X160).
43
2.3.3 Ciclo di Sviluppo
Innanzitutto è necessario disporre dell’ambiente di sviluppo Java (JDK), sulla propria
macchina. Il JDK è indispensabile ai fini della generazione del file con estensione
“class”, a partire dal file della propria applicazione con estensione “java”. Il bytecode di
SuperWaba è infatti compatibile con il bytecode Java e può essere eseguito, mediante
applet, su di una qualsiasi macchina virtuale Java standard.
Inoltre il runtime di java è utilizzato per generare i file eseguibili, destinati ai palmari.
Per quest’ultimo motivo, è consigliabile copiare l’intera cartella del kit di sviluppo di
SuperWaba, sull’unita disco della propria postazione di lavoro
È possibile eseguire il download del kit, gratuitamente e previa registrazione, dal sito
ufficiale: http://www.superwaba.com.br/. Il kit contiene, oltre al necessario per
l’installazione di SuperWaba sui dispositivi, un’ampia documentazione comprensiva
delle API messe a disposizione dall’ambiente e la licenza d’uso.
Il ciclo di sviluppo di un’applicazione SuperWaba si articola nei seguenti passi:
•
Generazione del codice sorgente, della propria applicazione, mediante un editor
di testo o un qualsiasi tool di sviluppo3. La sintassi è quella del linguaggio java,
mentre le API da considerare sono quelle messe a disposizione dall’ambiente.
•
Installazione dell’emulatore SuperWaba sul proprio Computer Desktop. Tale
operazione, pur non essendo strettamente necessaria, facilita il processo di
realizzazione e testing della applicazione.
•
Compilazione del file sorgente, attraverso il compilatore java. La versione del
JDK da utilizzare è, preferibilmente, la 1.2.x, ma è possibile utilizzare anche le
versioni 1.1.x, 1.3.x e superiori. In questi ultimi due casi, bisogna compilare con
l’opzione “-target 1.1”.
•
Generazione del file con estensione “pdb”. Esso rappresenta un archivio
contenente le classi utente di cui alla fase precedente e ogni altro file contenuto
nell’applicazione, quali ad esempio file immagine o sonori. Tale file di archivio
è prodotto mediante l’esecuzione di un programma java, Warp, fornito nel kit di
sviluppo della piattaforma SuperWaba.
•
Generazione dei file eseguibili destinati ai PDA. Attraverso l’esecuzione del
programma java, Exegen, è possibile ottenere, in un sol passo, il file eseguibile
3
Tutti i programmi SuperWaba, con interfaccia utente, devono necessariamente avere una ed una sola
“main window”, realizzata mediante la classe MainWindow.
44
per i dispositivi basati su PalmOS, quello per i dispositivi basati su WindowsCE
e il link a quest’ultimo.
•
Installazione del file archivio con estensione “pdb”, del file eseguibile e del
relativo link, sul dispositivo palmare. I primi due devono essere copiati in una
cartella creata nella directory contenente la macchina virtuale, mentre l’ultimo
può essere copiato laddove si ritiene più opportuno.
I dettagli sulle installazioni e la sintassi dei comandi “Warp” e ”Exegen”, sono contenuti
nel file “SuperWaba.pdf” che è fornito assieme alla documentazione della piattaforma
SuperWaba.
In appendice A è descritto un esempio di installazione della piattaforma SuperWaba e lo
sviluppo, comprensivo del testing sull’emulatore, di un esempio semplice.
45
2.3.4 Le API di SuperWaba
Le
API
base,
fornite
dall’ambiente
SuperWaba,
sono
archiviate
nel
file
“SuperWaba.pdb”. Esso contiene le classi base suddivise nei package mostrati nella
tabella 2.6:
Package Inclusi nel file SuperWaba.pdb
java.lang
waba.fx
waba.io
Tale package contiene alcune delle classi del package originale
java.lang, e di queste possiede solo un sottoinsieme dei metodi.
Contiene classi per i fonts, classi geometriche e classi per la gestione
delle immagini e dei suoni.
Classi base per l’I/O, per accedere ai file PDB, per la gestione delle
socket e delle porte seriali.
Tale package contiene le classi che si interfacciano con le
waba.sys
caratteristiche del Sistema Operativo sottostante e le classi per la
conversione degli oggetti.
waba.ui
Questo rappresenta uni dei package più importanti, contiene tutti gli
oggetti e I controlli per la creazione delle interface utente.
Classi di utilità per la gestione delle date e per la generazione dei
waba.util
numeri casuali. Contiene inoltre gli oggetti per le strutture di dati
(Vettori e Hashtable).
Tabella 2.6 – Classi base di default della piattaforma SuperWaba.
Nel caso in cui si dovessero usare classi che non sono contenute nei package di default,
è necessario installare i package di estensione corrispondenti alle classi utilizzate. Nella
tabella 2.7 sono indicati i package supplementari ed una loro descrizione, in tabella 2.8
sono invece descritti i package opzionali a pagamento.
46
Package di estensione (installazione opzionale)
Tratta con applicazioni proprie di Palm OS:
superwaba.ext.palm.io.builtin
Agenda, Mail, etc.
superwaba.ext.xplat.game
Framework per la creazione di giochi.
superwaba.ext.xplat.io
Classi extra per la gestione dell’I/O.
superwaba.ext.xplat.io.gps
Classi per la visualizzazione dei dati GPS.
superwaba.ext.xplat.io.gps.garmin
Implementa il protocollo Garmin GPS.
Classi per supportare il simbolo scanner per Palm
superwaba.ext.xplat.io.scanner
OS e Pocket PC.
superwaba.ext.xplat.sql
Sottoinsieme delle classi del package java.sql.
superwaba.ext.xplat.sql.db2e
Estensione del package xplat.sql.
superwaba.ext.xplat.sql.db2e.db2ex
Implementa una interfaccia nativa alternativa a
WDBC.
Classi di interfaccia utente, forniscono funzionalità
superwaba.ext.xplat.ui
supplementare.
superwaba.ext.xplat.util
Classi di utilità aggiuntive.
superwaba.ext.xplat.util.crypto
Classi per la crittazione e la decrittazione dei dati.
superwaba.ext.xplat.util.datergf
Classi per la manipolazione avanzata di data e ora.
superwaba.ext.xplat.util.props
Classi che definiscono proprietà.
superwaba.ext.xplat.util.xml
Fornisce un parser xml leggero e veloce.
Tabella 2.7 – Packages di estensione la cui installazione è opzionale. Sono disponibili gratuitamente.
Package di estensione a pagamento (installazione
opzionale)
superwaba.ext.xplat.io.print
superwaba.ext.xplat.io.search
Definiscono il comportamento per le librerie di stampa.
Contiene una classe usata per accelerare l’accesso
sequenziale di un PDB (per Palm OS).
Tabella 2.8 - Package supplementari di installazione opzionale. Sono disponibili a pagamento.
47
2.4 Ewe
Ewe è una piattaforma Open Source finalizzata allo sviluppo di applicazioni destinate ai
palmari. La piattaforma definisce un linguaggio, una Virtual Machine interpretata e un
insieme di classi base.
Il linguaggio ha una sintassi Java, per cui gli sviluppatori, come nel caso di SuperWaba,
possono utilizzare il tool di sviluppo che preferiscono, ma la macchina virtuale non usa
nessuna delle librerie standard di Java, al contrario essa utilizza librerie di classi definite
e implementate dalla piattaforma Ewe.
Una differenza sostanziale, con SuperWaba, riguarda la compatibilità con le API Java,
infatti, pur non definendo librerie conformi alle specifiche Java standard, Ewe ha
dedicato particolare attenzione al processo di migrazione delle applicazioni Java in
applicazioni Ewe.
Infatti per la conversione di un programma Java in uno Ewe, spesso è sufficiente
sostituire i package Java con i package Ewe e aggiungere, o modificare, poche linee di
codice dell’applicazione.
Ewe, così come SuperWaba , è rilasciata con la licenza GNU LGPL, per cui è possibile
sviluppare le proprie applicazioni, corredarle con la Ewe Vitual Machine e distribuire il
tutto anche per scopi commerciali.
48
2.4.1 Disponibilità.
La piattaforma Ewe è disponibile per diverse classi di sistemi:
dispositivi Windows CE/PocketPC
•
Dispositivi con sistema operativo PocketPC e PocketPC 200x
•
Casio Cassiopeia BE-300 PDA
•
PalmPC
•
HandHeld PC Pro/2000
32-bit Windows Computer Desktop
•
Windows 95
•
Windows 98
•
Windows ME
•
Windows NT
•
Windows 2000
•
Windows XP
Linux devices
•
Macchine Linux con la libreria GTK+1.2
•
Macchine Linux con la libreria Qt
•
Sharp Zaurus PDA
Inoltre sono in via di sviluppo versioni della macchina virtuale per i PDA PalmOS 5 e
per il PDA Simputer Linux.
49
2.4.2 Caratteristiche
Nella tabella 2.9, sono riportate alcune caratteristiche dell’ambiente Ewe, suddivise per
aree chiave:
Virtual Machine
Supportata da diverse piattaforme hardware
Consente le creazione di librerie native C
Supporto ai thread, alle eccezioni, e ai tipi double e long
Extension features
API per l’accesso ai registri di sistema
Supporto per gli algoritmi di crittografia: Blowfish, SHA1
Implementazione di database portabili e sincronizzabili
API di comunicazione tra dispositivo mobile e Computer desktop
Input/Ouput
Supporto per il protocollo TCP/IP, serial port, InfraRed.
User Interface
Libreria di GUI comparabili, a livello di funzionalità, alle Swing GUI disponibili per il JDK 1.2.
Tabella 2.9 – Caratteristiche salienti della piattaforma Ewe.
Per quanto riguarda l’implementazione dei thread, la piattaforma Ewe propone un
modello sostanzialmente analogo al modello dei thread di SuperWaba. Ewe fornisce un
ambiente a singolo thread che non consente prelazione e non supporta alcun tipo di
concorrenza.
Anche se il sistema operativo sottostante la virtual machine supporta il multithreading,
il runtime consente l’esecuzione di uno ed un solo thread per volta.
Le API per la gestione dei thread Ewe, sono virtualmente le stesse contenute nel
package java.lang.Thread. La differenza sta nel fatto che un thread utente Ewe, deve
necessariamente invocare una serie di metodi sleep, per consentire l’aquisizione del
controllo da parte degli altri thread. D’altra parte, poiché molte operazioni di I/O e di
interfaccia utente hanno delle chiamate implicite al metodo suddetto, non sempre
occorre intervenire nell’implementazione dei metodi dei thread.4
4
La piattaforma Ewe non fornisce il supporto alla concorrenza dei thread utente, ma quest' ultima può
essere comunque realizzata da programma.
50
2.4.3 Ciclo di Sviluppo
Innanzitutto è auspicabile disporre dell’ambiente di sviluppo Java sulla propria
macchina. In realtà ad essere indispensabile è la presenza di un compilatore java,
disponibile anche sul sito della piattaforma. Il compilatore è necessario per la
generazione del bytecode e deve utilizzare, per tale scopo, le librerie di classi
proprietarie della piattaforma.
A partire dal bytecode è possibile ottenere il file eseguibile destinato al dispositivo
palmare e alla propria postazione desktop. Allo
scopo è necessario installare, sul
computer desktop, la Ewe virtual machine, la quale consente di poter eseguire
un’applicazione, Jewel.ewe, che è in grado di produrre un file eseguibile che funge
anche da archivio per le classi utente. È da notare che tale operazione è indispensabile
se si intende collocare la propria applicazione in una qualsiasi posizione all’interno del
file system del dispostivo palmare. Per capire meglio tale affermazione, è necessario
descrivere la macchina virtuale Ewe in corso di esecuzione. Essa si presenta sottoforma
di Launcher che è in grado di generare collegamenti alle applicazioni e di mostrarli su
di un pannello. Le classi appartenenti ad una specifica applicazione, per poter essere
riferite dal Launcher, devono essere necessariamente installate in una cartella di nome
“classes”. In genere tale modo di procedere è utilizzato per scopi di debug, cioè per
provare l’applicazione sul dispositivo prima di generare il file eseguibile. Una volta
generato l’eseguibile, che per la Ewe virtual Machine ha estensione “ewe”, esso può
essere riferito dal Launcher, ma può anche essere eseguito cliccando semplicemente su
di esso, qualora il programma fosse privo di parametri.
Tutto quanto occorre per lo sviluppo di applicazioni Ewe, è reperibile al sito web
ufficiale: http://www.ewesoft.com/.
Il ciclo di sviluppo di un’applicazione Ewe può espletarsi nei seguenti passi:
•
generazione del codice sorgente, della propria applicazione, mediante un editor
di testo o un qualsiasi tool di sviluppo. La sintassi è quella del linguaggio java,
mentre le API da considerare sono quelle messe a disposizione dall’ambiente.
•
Installazione della macchina virtuale Ewe sul proprio Computer Desktop. Tale
operazione, serve ad eseguire l’applicazione Jewel.ewe che produce i file
eseguibili;
51
•
Compilazione del file sorgente, attraverso un compilatore java;
•
generazione dei file eseguibili destinati al PDA e al computer desktop;
•
installazione del file eseguibile sul dispositivo palmare ed eventualmente sulla
postazione desktop;
•
creazione del collegamento all’applicazione, dalla console del Launcher della
macchina virtuale. Tale operazione è opzionale solo nel caso che l’applicazione
sia senza parametri d’ingresso e sia nel formato eseguibile.
In appendice B è descritto un esempio di installazione della piattaforma Ewe e lo
sviluppo, comprensivo del testing sulla macchina virtuale Ewe (PC version), di un
esempio semplice.
52
2.4.4 Le API di Ewe
Le API base, fornite dalla piattaforma Ewe, sono mostrate in tabella 2.10:
Package di Ewe
ewe.data
Fornisce classi per il trattamento dei dati.
ewe.database
Fornisce una implementazione indipendente dal dispositivo
di un database.
ewe.filechooser
Tale package fornisce un FileChooser.
ewe.fx
Fornisce le funzioni base del disegno 2D.
ewe.graphics
Fornisce le funzioni avanzate del disegno 2D tra cui quelle
necessarie per I giochi e le animazioni.
ewe.graphics.pagedisplay Classi per la visualizzazione delle pagine
ewe.io
Fornisce le librerie di I/O – molte classi si rispecchiano nella
java.io.
ewe.math
Fornisce il supporto per i tipi BigInteger e BigDecimal.
ewe.net
Fornisce il supporto alla comunicazione TCP/IP in modo
molto simile al package java.net.
ewe.reflect
Fornisce il supporto per la Java Reflection.
ewe.security
Fornisce il supporto per la crittazione simmetrica e a chiave
pubblica. Supporto per la firma digitale.
ewe.sys
Classi di sistemi, tra cui l’implementazione dei thread.
ewe.ui
Classi per le GUI Ewe.
ewe.ui.formatted
Fornisce il supporto per la visualizzazione del testo
formattato.
ewe.util
Classi di utilità.
ewe.util.zip
Supporto per i file Zip.
ewex.registry
Supporto per l’accesso ai registri di sistema nei sistemi
Windows.
java.lang
Tale package contiene alcune delle classi del package
originale java.lang, e di queste possiede solo un sottoinsieme
dei metodi.
Tabella 2.30 – Classi della piattaforma Ewe.
53
2.5 Considerazioni comparative
In tabella 2.11 è riportata una comparazione tra i package messi a disposizione dagli
ambienti di esecuzione delle piattaforme considerate.
Java.lang
Util
I/O
Net
Zip
Reflect
Math
trattamento dei dati
RMI
Security
SQL
Applet
User Interface
Game API
Accesso registri di sistema
Visualizzazione dati GPS
Protocollo Garmin GPS
Classi specifiche per PPC e PalmOS
API di comunicazione tra PC e PDA
Jeode
a
a
a
a
a
a
a
a
a
a
a
a
a
CrEme
a
a
a
a
a
a
a
a
a
a
a
a
a
SuperWaba
a
a
a
a
a
a
a
Ewe
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
Tabella 2.11 – API a confronto.
Le macchine virtuali Jeode e CrEme sono molto simili dal punto di vista delle classi
supportate, d’altra parte sono entrambe Java-compliant.
Da notare, inoltre, che le macchine virtuali Java-based controbilanciano la loro limitata
compatibilità con Java, fornendo API specifiche per i dispositivi su cui sono disponibili.
54
Capitolo 3
Definizione ed implementazione dei test sperimentali
A monte del processo di valutazione delle differenti macchine virtuali, c’è la definizione
di un modello di qualità per un sistema software. Esso è caratterizzato da un insieme di
attributi che sia
rappresentativo del prodotto software, macchina virtuale, e che
costituisca la base per poter discriminare tra le macchine virtuali considerate.
La scelta degli attributi è legata allo stato attuale della tecnologia dei palmari, il quale
consente l’impiego di tali dispositivi per applicazioni client-based, grazie anche al
proliferare di infrastrutture di rete wireless.
A valle di tutto il discorso ci sono le entità che caratterizzano gli attributi e le metriche,
qualitative e quantitative, costruite su di esse.
In tale capitolo è presentato, nel dettaglio, il modello di qualità proposto e sono definite
le metriche e le applicazioni che consentono di effettuare le misure in relazione alle
metriche quantitative definite.
3.1 Il modello di qualità
In figura 3.1 è mostrato lo schema del modello proposto, per la valutazione delle
differenti macchine virtuali:
Modello
Efficienza
Interoperabilità
Usabilità
Portabilità
Figura 3.1 - La qualità caratterizzata attraverso un insieme finito e definito di attributi.
55
3.1.1 Gli attributi e le entità
Gli attributi che caratterizzano il modello di qualità proposto, a loro volta sono definiti
da un insieme di entità. In tale paragrafo è data una definizione degli attributi presenti
nel modello, corredata dalle entità scelte per caratterizzarli.
•
Efficienza: è il grado con il quale il software esegue le funzioni per le quali è
stato progettato, con il minimo spreco di risorse di calcolo. Essa rappresenta,
quindi, il livello di utilizzazione delle risorse hardware del dispositivo.
Le entità caratterizzanti sono le seguenti:
o Impronta di memoria;
o Multithreading;
o Chiamate a metodi;
o Overhead
•
Interoperabilità: rappresenta la capacità di un sistema software di integrarsi e
interagire con altri sistemi. In tale ottica, particolare rilievo assumono gli
standard di comunicazione. Le entità coinvolte sono le seguenti:
o Operazioni di I/O su file;
o Operazioni di I/O su rete;
o Compatibilità con Java standard.
•
Usabilità.
•
Portabilità: rappresenta la facilità con la quale un prodotto software può essere
trasferito da un sistema di elaborazione, o ambiente, ad un altro. Tale attributo
misura, quindi, il grado di indipendenza dalla macchina e il grado di
indipendenza dal software.
L’entità caratterizzante scelta è la seguente:
o Disponibilità su differenti piattaforme hardware-software
56
3.2 le metriche
Le metriche definite per la valutazione delle macchine virtuali, sono di carattere sia
quantitativo sia qualitativo. Nella tabella 3.1 seguono le metriche del primo tipo, con
l’indicazione degli attributi di qualità a cui afferiscono.
Metrica quantitativa
Efficienza
L’impronta di memoria (footprint memory).
Il multithreading.
Il tempo di chiamata ai metodi.
L’overhead per l’esecuzione della macchina virtuale.
Interoperabilità Il tempo per le operazioni di Input/Output su file.
Il tempo per le operazioni di Input/Output su rete.
Tabella 3.1 – Metriche quantitative.
•
L’impronta di memoria rappresenta la quantità di memoria di archiviazione,
necessaria alla installazione delle macchine virtuali, sul dispositivo palmare.
•
Il multithreading è espresso in termini di:
o Livello di multithread.
o Tempo di esecuzione di uno stesso algoritmo multithread, senza politiche
di sincronizzazione.
•
Il tempo di chiamata a metodi, si particolarizza in:
o Tempo medio di chiamata di un metodo senza parametri.
o Tempo medio di chiamata di un metodo con un parametro elementare.
o Tempo medio di chiamata di un metodo con un parametro strutturato.
•
L’overhead è inteso in termini di:
o Quantità media di memoria occupata, per l’esecuzione della macchina
virtuale.
•
Il tempo per le operazioni di Input/Output su file si riferisce a:
o Tempo medio di scrittura al variare delle dimensioni del file
o Tempo medio di lettura al variare delle dimensioni del file.
•
Le operazioni di Input/Output su rete, sono da intendersi in termini di delay.
57
Nella tabella 3.2 sono elencate le metriche di carattere qualitativo:
Metrica qualitativa
Portabilità
Il numero di piattaforme hardware-software che supportano le VM.
Usabilità
Il ciclo di sviluppo per la realizzazione delle applicazioni.
La tipologia di classi supportate da ciascun ambiente.
La tipologia del supporto alle Graphical User Interface.
Interoperabilità Compatibilità con java.
Tabella 3.2 – Metriche qualitative.
58
3.3 I test sperimentali: definizione e implementazione
In tale paragrafo sono definiti i test sperimentali ed è proposta una loro
implementazione [Herbert]. Per la valutazione dell’impronta di memoria, footprint
memory, e per la valutazione dell’overhead generato da ciascuna macchina virtuale, non
è necessario sviluppare alcuna applicazione. Infatti per la prima è sufficiente osservare
la quantità di memoria di archiviazione, del dispositivo palmare, prima e dopo
l’installazione di ciascuna macchina virtuale. Per la seconda valutazione si utilizza un
monitor software.
3.3.1 Il multithreading
Si è già discusso, nel precedente capitolo, del fatto che le macchine virtuali Ewe e
SuperWaba, non forniscono un vero e proprio supporto al multithread. Tali ambienti
sono a thread singolo, non consentono prelazione e non supportano alcun tipo di
concorrenza. Per tali ragioni il livello di multithread, è verificato per le macchine
virtuali Jeode e CrEme. Invece le prestazioni, in termini di tempo di esecuzione di uno
stesso algoritmo multithread, sono valutate in riferimento a tutte le macchine virtuali,
dal momento che, anche per quanto riguarda Ewe e SuperWaba, è possibile che un
thread ceda volontariamente il controllo in favore degli altri thread (modello
cooperativo).
3.3.1.1 Considerazioni preliminari
Per meglio definire e implementare l’applicazione che consente di stimare il livello di
multithread, si è reso necessario lo studio del comportamento di Jeode e CrEme in
relazione alla priorità dei thread. Allo scopo si sviluppata una applicazione (di cui si
riportano in questo stesso paragrafo i risultati) in cui il thread principale istanzia due
thread figli, hiThread e loThread, ciascuno dei quali incrementa una propria variabile
membro intera, fino a quando il principale non invoca su di essi un metodo che causa la
terminazione dei thread stessi. Successivamente il thread principale invoca il metodo
run dei due thread, si sospende per dieci secondi e al suo risveglio provoca la
terminazione dei thread figli e attende la loro effettiva terminazione (metodo join).
59
Infine il thread padre visualizza, sullo standard output, il valore di ciascuna variabile.
Da tali valori è possibile ottenere un stima della percentuale di utilizzo del processore
da parte dei due thread figli.
Lo schema dell’algoritmo è il seguente:
ü il thread principale imposta la propria priorità, istanzia due thread figli e ne
imposta la priorità;
ü il thread principale avvia l’esecuzione dei thread figli, in successione;
ü ciascun thread figlio incrementa la propria variabile membro (intera) fino a
quando non viene invocato il metodo che ne causa la loro terminazione;
ü il thread principale si sospende per dieci secondi (sleep) dopodiché chiama il
metodo per la terminazione dei figli, in successione.
ü infine il thread principale aspetta la reale terminazione dei figli (join) e
visualizza sullo standard output il valore di ciascuna variabile membro dei suoi
figli.
Al variare della priorità dei thread figli, si ottengono i seguenti risultati:
•
Thread con la stessa priorità: la specifica Java non impone alcun comportamento
in caso di thread a priorità eguale, consiglia solo che essi siano implementati in
modo tale da cedere occasionalmente il controllo, per dare una possibilità di
esecuzione agli altri thread. La tabella 3.3 mostra il risultato di una esecuzione
dell’applicazione summenzionata, nelle condizioni di precedenza appena
discusse:
J2SE
Jeode
CrEme
loThread 201148849
185547214
21015895
hiThread 200972548
189014587
21152192
Tabella 3.3 – Thread figli a priorità uguale.
Dall’analisi dei risultati, si può assumere che i thread ad uguale priorità sono
eseguiti a turno: sia Jeode sia CrEme gestiscono i thread di pari priorità con una
politica di scheduling round-robin.
60
•
Thread con priorità differente: al thread loThread è assegnata una priorità più
bassa rispetto alla priorità data al thread hiThread. In tabella 3.4 sono riportati i
risultati ottenuti dall’esecuzione dell’applicazione in tale condizioni:
J2SE
Jeode
CrEme
loThread 9200243
0
0
hiThread 393097456
371094429
42304385
Tabella 3.4 – Thread figli a priorità differente.
Dai risultati di cui alla tabella precedente si evince che, sulle piattaforme Jeode e
CrEme, i thread a priorità più bassa vanno in starvation alla presenza di thread a
priorità più alta, che non cedano mai il controllo. Inoltre osservando i valori in
tabella 3.3 e 3.4, si nota che i thread della macchina virtuale Jeode hanno un
utilizzo dei cicli di CPU molto maggiore rispetto a quelli sulla macchina CrEme.
•
Thread con priorità differente, la prelazione: inserendo una sospensione di
cinque millisecondi tra l’invocazione dei metodi start dei due thread figli, si può
determinare il comportamento di Jeode e CrEme nei riguardi della prelazione.
In tabella 3.5 si riportano i risultati:
Jeode
CrEme
LoThread 13
31745
HiThread 377425962
42203007
Tabella 3.5 – Jeode, CrEme e la prelazione.
L’analisi dei risultati conferma quanto è riportato nella documentazione ufficiale
delle piattaforme Jeode e CrEme: entrambe hanno una gestione dei thread basata
sulle priorità, ma la macchina virtuale Jeode implementa un modello di gestione
con prelazione. Evidentemente il thread a maggior priorità, nel caso di CrEme,
attende che termini un quanto di tempo prima di acquisire definitivamente il
controllo. Jeode invece prelazione il thread a priorità più bassa a favore di quello
a priorità più alta. La percentuale di utilizzo della CPU del thread “loThread” è,
nel caso di Jeode, lo 0.0000031% (praticamente zero) mentre per CrEme è circa
lo 0.075%.
61
3.3.1.2 Livello di multithreading
Definizione del test:
si vuole dare una stima del massimo numero di thread supportati da ciascuna delle due
piattaforme. Tale stima si può ottenere osservando il numero di thread in
corrispondenza del quale si verifica uno dei due eventi:
ü il sistema solleva una eccezione del tipo out of memory;
ü il sistema va in trash.
Implementazione:
l’applicazione prevede che il thread principale istanzi due classi di thread, una classe
FaiQualcosa e una classe FaiNulla. La prima ridefinisce il metodo run in modo da
eseguire operazioni che abbiano una certa rilevanza temporale, in tal modo è alta la
probabilità che, in presenza di più thread aventi tutti la stessa priorità, quando il thread
FaiQualcosa acquisisca il controllo del processore, esso non esaurisca il suo compito in
un unico quanto di tempo. Nella fattispecie tale thread avvalora una matrice di grandi
dimensioni per un determinato numero di volte e calcola il tempo impiegato per farlo.
La classe FaiNulla ridefinisce il metodo run in modo da realizzare un ciclo indefinito
che semplicemente “consumi” cicli del processore.
Si è scelta una strategia di tipo controllato, cioè il numero di thread presenti nel sistema
è immesso come parametro da riga di comando. In tale modo è possibile ottenere stime
temporali, dell’esecuzione del thread FaiQualcosa, quando si presume che il sistema sia
in condizioni di regime, cioè quando tutti i thread sono stati schedulati.
In particolare il thread principale compie le seguenti azioni:
ü Istanzia e avvia il thread FaiQualcosa per un numero fissato di volte (in maniera
sincronizzata), in modo tale da avere più rilevazioni temporali senza che vi siano
altri thread nel sistema.
ü Istanzia e lancia i thread FaiNulla e determina il tempo necessario a compiere
tale azione. Tale tempo concorre a determinare lo stato di trash del sistema.
ü Istanzia e avvia il thread FaiQualcosa per un numero di volte proporzionale al
numero di thread FaiNulla (sempre in maniera sincronizzata), in tale modo si
cerca di avere valutazioni temporali a regime.
62
Dalla conoscenza dei tempi di esecuzione del thread FaiQualcosa, in condizioni di
monopolio della CPU, è possibile osservare il degrado delle prestazione del thread in
questione, quando nel sistema vi siano un certo numero di thread FaiNulla.
Se l’andamento delle stime temporali è non lineare, al crescere del numero totale di
thread del sistema, allora si può assumere che il sistema sia andato in trash.
Come già detto anche il tempo necessario a lanciare il numero fissato di thread
FaiNulla, concorre a determinare tale stato di deterioramento della prestazioni generali
del sistema. D’altra parte se in un’applicazione si istanziano un certo numero di thread,
non è per mero divertimento.
Da notare che ogni stima di tempo è memorizzata in un file distinto, questo per evitare
che i thread siano in competizione sullo stesso dispositivo di output.
3.3.1.3 Prestazioni di uno stesso algoritmo multithread
Definizione:
Si intende dare una stima delle prestazioni, in termini di tempo di esecuzione, di uno
stesso algoritmo multithread, che non adoperi politiche di sincronizzazione.
Implementazione:
L’applicazione sviluppata, per assolvere allo scopo preposto, è il prodotto tra due
matrici. La scelta è stata polarizzata dalla considerazione che un algoritmo parallelo, per
essere eseguito efficientemente, deve godere delle proprietà commutativa e associativa
[Fadini].
Questo è proprio il caso dell’algoritmo del prodotto matriciale, infatti ciascun elemento
della matrice prodotto è espresso come sommatoria di mintermini.
A tale considerazione si aggiunga il fatto che, trovandoci in ambiente multithread, è
nullo il tempo di comunicazione, visto che i dati possono condividere lo stesso spazio di
indirizzamento.
L’algoritmo proposto è a grana fine, cioè se la matrice è di ordine n, allora sono
istanziati n2 thread ciascuno dei quali calcola un elemento della matrice prodotto. Tale
scelta è motivata dal fatto che lo scopo del test non è realizzare un algoritmo
multithread efficiente, ma valutare l’efficienza dell’algoritmo all’aumentare del numero
di thread, in tal modo è possibile osservare, ad esempio, quanto incide il cambio di
contesto nelle prestazioni generali dell’algoritmo.
63
3.3.2 Il tempo di chiamata ai metodi
Definizione:
Si vuole calcolare il tempo medio di chiamata di un metodo di una classe, nei seguenti
casi:
ü l’oggetto chiamante non passa alcun parametro all’oggetto chiamato;
ü l’oggetto chiamante passa un parametro elementare all’oggetto chiamato;
ü l’oggetto chiamante passa un parametro strutturato all’oggetto chiamato.
Per tempo di chiamata di un metodo si intende, in tale contesto, il tempo che intercorre
tra l’invocazione del metodo di un oggetto e il ritorno del controllo al chiamante. In
particolare il metodo chiamato non esegue alcuna istruzione.
Implementazione:
L’applicazione realizzata esegue le seguenti azioni per ciascun tipo di chiamata:
ü fissa un istante di tempo prima dell’invocazione del metodo.
ü invoca il metodo in questione, per un numero prefissato e sufficientemente
grande di volte.
ü calcola il tempo trascorso a partire dall’istante di tempo fissato in precedenza.
ü calcola il tempo medio.
Si osservi che iterare per un elevato numero di volte, in realtà, fornisce un valore medio
come effetto collaterale. Questo perché il tempo da calcolare è talmente piccolo da non
essere adatto alla sensibilità del meccanismo di rilevazione offerto dalle librerie delle
varie piattaforme.
64
3.3.3 Operazioni di Input/Output su file
Definizione:
si vuole calcolare il tempo medio di esecuzione delle operazioni su file, nei seguenti
termini:
ü Tempo medio di scrittura al variare delle dimensioni del file.
ü Tempo medio di lettura al variare delle dimensioni del file.
Implementazione:
L’applicazione realizzata prevede che si possa immettere, da riga di comando, la
dimensione del file espressa in byte. L’applicazione realizzata esegue le seguenti azioni:
ü fissa un istante di tempo di riferimento per l’operazione di scrittura;
ü esegue la scrittura del file delle dimensioni specificate;
ü calcola il tempo trascorso a partire dall’istante di tempo fissato in precedenza e
lo memorizza in un file di testo;
ü fissa un nuovo istante di tempo di riferimento;
ü esegue le lettura del file scritto precedentemente;
ü calcola il tempo impiegato per effettuare la lettura;
ü memorizza il tempo di lettura in un file testuale;
ü itera i passi precedenti un numero di volte pari al numero di campioni scelto per
determinare la caratterizzazione sintetica dei tempi di lettura e scrittura.
65
3.3.4 Operazioni di Input/Output su rete
Definizione:
Il ritardo di rete rappresenta il tempo che intercorre tra l’invio e la effettiva ricezione di
un flusso di byte [Tanenbaum]. Si intende calcolare una stima del ritardo di rete da
punto a punto (end-to-end delay) e a livello TCP.
Implementazione:
La soluzione implementata si propone di calcolare il round trip time, inteso come il
tempo impiegato dallo stream per arrivare a destinazione e da lì ritornare. Il ritardo di
rete può quindi essere stimato dimezzando tale valore.
Il vantaggio di tale approccio risiede nella semplicità dell’algoritmo e nel modesto
overhead computazionale. E’ difatti sufficiente fissare un riferimento temporale a invio
effettuato ed un secondo non appena il flusso di dati è ritornato, la differenza tra i due
timestamp rappresenta proprio il round trip delay.
La struttura dell’applicazione è di tipo client-server, il cliente viene mandato in
esecuzione sul dispositivo palmare ed effettua le seguenti operazioni:
ü Crea il canale di comunicazione con il servente (Socket TCP).
ü Crea il flusso di dati, di lunghezza fissa, da trasmettere al server.
ü Definisce il numero di campioni sulla base dei quali è possibile ottenere una
caratterizzazione sintetica del ritardo di rete.
ü Stima il ritardo di rete a partire dal round trip time, così come descritto in
precedenza.
ü Memorizza la stima ottenuta in un vettore e si sospende per un secondo.
ü Ripete le ultime due azioni per un numero di volte pari al numero di campioni.
ü Calcola la media delle stime memorizzate nel vettore di stime, escludendo dal
calcolo il massimo e il minimo valore.
La sospensione del client, rappresenta un ragionevole margine di sicurezza affinché non
vi siano conflitti sul canale di comunicazione, infatti alla ricezione di un messaggio
segue sempre l’invio del successivo, fino al raggiungimento del numero di campioni.
66
Il server è mandato in esecuzione su di un computer desktop, esso è implementato
mediante estensione della classe Thread e ridefinisce il metodo run in modo da eseguire
le seguenti operazioni:
ü Creazione di un canale di comunicazione (ServerSocket TCP).
ü Accettazione delle richieste di connessione da parte dei client.
ü Realizzazione di un ciclo infinito in cui si effettua la ricezione dei messaggi
provenienti dai client e la trasmissione degli stessi messaggio, al mittente
(echoing)
67
Capitolo 4
Analisi e valutazione dei risultati sperimentali
In tale capitolo sono presentati e analizzati i risultati dei test sperimentali, in relazione
alle metriche quantitative e qualitative. Inoltre è proposta un’analisi comparativa dei
risultati ottenuti per le differenti macchine virtuali.
In figura 4.1 è presentato lo schema delle metriche del modello di qualità proposto.
Metriche
Quantitative
•
•
•
•
•
•
Impronta di memoria.
Multithreading.
Tempo di chiamata a
metodi.
Overhead delle VM.
Tempo per le operazioni
di Input/Output su file.
Tempo per le operazioni
di Input/Output su rete.
Qualitative
•
•
•
•
•
Piattaforme hw-sw che
supportano le VM.
Ciclo di sviluppo
Tipologia di classi
supportate
Tipo di supporto alle
Graphical User Interface.
Compatibilità con java.
Figura 4.1 – Metriche quantitative e qualitative.
68
4.1 Metriche quantitative: risultati
Nel precedente capitolo è stata data una definizione dei test sperimentali ed è stata
descritta l’implementazione proposta. Tutte le applicazioni sono state eseguite sul
palmare Compaq iPAQ 3970, con sistema operativo PocketPC2002 e 33Mb di
memoria. In tale paragrafo si riportano i risultati ottenuti nel processo di misurazione.
4.1.1 Impronta di memoria
L’impronta di memoria (footprint memory) rappresenta la quantità di memoria
necessaria all’istallazione di ciascun macchina virtuale. I risultati ottenuti sono indicati
nella tabella 4.1:
Footprint Memory
Jeode
CrEme
SuperWaba
Ewe
2736 Kb
4448 Kb
360Kb
2048 Kb
Tabella 4.4 - Impronta di memoria
4.1.2 Multithreading
I test sperimentali che riguardano il multithreading sono espressi in termini di:
•
Livello di multithread.
•
Tempo di esecuzione di uno stesso algoritmo multithread, senza politiche di
sincronizzazione.
E’ necessario sottolineare, ancora una volta, che le macchine virtuali Ewe e SuperWaba,
non forniscono un vero e proprio supporto al multithreading, per tale motivo la
valutazione del livello di multithreading ha senso solo per le macchine virtuali javacompliant considerate. Invece la stima delle prestazioni, in termini di tempo di
esecuzione di uno stesso algoritmo multithread, contempla anche le due macchine
virtuali java-based, dal momento che esse sono consentono ad un thread di cedere
volontariamente il controllo a favore degli altri.
69
4.1.2.1 Livello di Multithreading
Il livello di multithread è espresso mediante il calcolo di una stima del massimo numero
di thread che una piattaforma può supportare. L’algoritmo implementato sul testbed ha
prodotto i risultati riportati nelle tabelle 4.2 e 4.3. In esse è indicato:
•
il numero di thread presenti nel sistema (NThread), escluso il thread principale;
•
il tempo impiegato dalle macchine virtuali per istanziare il numero di thread di
cui al punto precedente (TFN);
•
media e deviazione standard dei campioni (TFQ e DTFQ). Questi ultimi sono
ricavati dalle misurazioni dei tempi di esecuzione del thread FaiQualcosa,
quando nel sistema sono presenti un numero di thread pari a NThread. I tempi
sono espressi in millisecondi.
NThread
0
5
10
20
50
100
Jeode
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
560.3
10.62
5211
3196.5
36.93
24299
5831.9
9.10
107427
11091.4
12.83
640798
26856.1
4.36
2927444
53125.2
11.20
CrEme
4177.8
34.50
25
5640.9
58.50
38
6624.1
27.14
60
9177.1
28.39
124
16879.3
17.13
644
29799.2
22.91
Tabella 4.2 – Risultati del test per il livello di multithreading: TFN – Tempo per istanziare un numero di
thred FaiNulla pari a NThread; TFQ, DTFQ – Tempo medio e deviazione standard, per l’esecuzione del
thread FaiQualcosa, quando nel sistema sono presenti un numero di thread pari a NThread. Tempi in
millisecondi (ms).
70
NThread
200
300
400
1000
1100
1200
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
TFN
TFQ
DTFQ
Jeode
8962324
105709.5
46.91
15434686
158077.7
10.03
trash
trash
trash
trash
-
CrEme
922
55522.2
36.52
1222
81151.4
35.62
8587
106609.7
57.45
445742
324242.8
54.94
2348423
357896.8
56.36
o.o.m.
-
Tabella 4.3 – Risultati del test per il livello di multithreading: TFN – Tempo per istanziare un numero di
thred FaiNulla pari a NThread; TFQ, DTFQ – Tempo medio e deviazione standard, per l’esecuzione del
thread FaiQualcosa, quando nel sistema sono presenti un numero di thread pari a NThread; trash – Il
sistema è andato in trash; o.o.m. – out of memory. Tempi in millisecondi (ms).
.
71
4.1.2.2 Prestazioni di un algoritmo multithread
L’applicazione stima le prestazioni, in termini di tempo di esecuzione, dell’algoritmo
multithread del prodotto tra due matrici quadrate.
Nelle tabelle 4.4 e 4.5 sono riportati i tempi medi di esecuzione (espressi in
millisecondi) e la deviazione standard, al variare della dimensione delle matrici.
Dim
20
50
100
110
145
150
Jeode
CrEme
SuperWaba Ewe
5137,3
1650,4
416,2
1000
36122,8
11797,2
13771
20900
138166
47549,9
213377,8
218200
170229,8
o.o.m.
316321,5
304300
297889,5
o.o.m.
o.o.m.
948500
347803,1
o.o.m.
o.o.m.
o.o.m.
Tabella 4.4 - Tempi medi di esecuzione (in ms) dell’algoritmo multithread: o.o.m.- out of memory;
Dim – dimensioni delle matrici (quadrate).
Dim
20
50
100
110
145
150
Jeode
CrEme
SuperWaba Ewe
62.9
42.5
10.1
0.9
608.2
284.7
182.7
737.8
824.9
393.2
1504.4
1751.2
1161.6
o.o.m.
2526.2
1494.4
1950.4
o.o.m.
o.o.m.
5642.1
2635.1
o.o.m.
o.o.m.
o.o.m.
Tabella 4.5 – Deviazione standard dei tempi di esecuzione (in ms) dell’algoritmo multithread.
o.o.m.- out of memory; Dim – dimensioni delle matrici (quadrate).
72
4.1.3 Tempo di chiamata a metodi
Il tempo di chiamata a metodi, si particolarizza in:
•
Tempo medio di chiamata di un metodo senza parametri.
•
Tempo medio di chiamata di un metodo con un parametro elementare.
•
Tempo medio di chiamata di un metodo con un parametro strutturato.
Nelle tabelle 4.6 e 4.7 sono riportati i risultati ottenuti.
A
B
C
Jeode
CrEme
SuperWaba Ewe
1,40E-04
6,64E-04
1,59E-03
3,60E-03
1,45E-04
7,38E-04
1,75E-03
3,90E-03
1,43E-04
7,39E-04
1,75E-03
3,90E-03
Tabella 4.6 – Tempi medi di chiamata a metodi (in ms): A – senza parametri; B – con un parametro
elementare; C – con un parametro strutturato.
A
B
C
Jeode
CrEme
SuperWaba Ewe
9,95E-07
4,45E-06
3,43E-05
5,16E-04
7,25E-07
3,77E-06
5,29E-05
5,68E-04
3,30E-06
3,14E-06
8,18E-05
3,16E-04
Tabella 4.7 – Deviazione Standard dei tempi di chiamata a metodi (in ms): A – senza parametri; B – con
un parametro elementare; C – con un parametro strutturato
73
4.1.4 Overhead delle macchine virtuali
L’overhead delle macchine virtuali è stato valutato in termini di quantità media di
memoria, necessaria per l’esecuzione della macchina virtuale. Lo strumento utilizzato
per effettuare la stima è un monitor software di memoria, in particolare è stato utilizzato
il monitor in dotazione al sistema operativo del dispositivo.
In tabella 4.8 sono riportati i dati sperimentali ottenuti e la caratterizzazione sintetica
della quantità di memoria necessaria all’esecuzione delle macchine virtuali (runtime
memory).
Jeode
3,11
3,14
3,10
3,12
3,30
3,18
3,14
3,00
3,19
3,17
Media
Dev.Standard
CrEme SuperWaba
2,64
0,43
2,60
0,46
2,61
0,45
2,66
0,45
2,60
0,43
2,71
0,47
2,66
0,45
2,64
0,44
2,70
0,46
2,63
0,43
3,15
2,65
0,0766304 0,0383695
Ewe
1,31
1,28
1,33
1,28
1,27
1,32
1,33
1,29
1,28
1,34
0,45
1,30
0,0141814 0,0258414
Tabella 4.8 – Risultati sperimentali della valutazione del runtime memory (Mb).
Nonostante si sia utilizzato un monitor software, è stato necessario definire e
implementare una semplice applicazione che si sospendesse per un determinato lasso di
tempo prima di terminare. Tale scelta è stata motivata dalla considerazione che la
macchina virtuale Ewe si presenta come ambiente per l’esecuzione delle applicazioni,
quando viene eseguita (Launcher).
Si noti che la sospensione dell’applicazione facilita la rilevazione dei dati del monitor.
74
4.1.5 Operazioni di I/O su file
Il tempo per le operazioni di Input/Output su file si riferisce a:
•
Tempo medio di scrittura al variare delle dimensioni del file
•
Tempo medio di lettura al variare delle dimensioni del file.
L’applicazione realizzata calcola i tempi per le operazioni di scrittura e lettura di un file
delle dimensioni specificate di seguito:
•
1 Mbyte;
•
2 Mbyte;
•
4 Mbyte;
•
8 Mbyte.
Le tabelle 4.9 e 4.10 riportano i risultati ottenuti dalla misurazione, relativamente
all’operazione di scrittura su file.
1 Mb
2 Mb
4 Mb
8 Mb
Jeode
85942,4
173465,8
344502
684094,9
CrEme
SuperWaba
127163,5
68521,1
249476,3
150381,2
506416,4
302278,8
966851,8
539380,6
Ewe
583500
1089800
2188900
4644700
Tabella 4.9 – Tempi medi di scrittura su file (in ms).
1 Mb
2 Mb
4 Mb
8 Mb
Jeode
1234,97
2090,61
2477,91
6411,57
CrEme
SuperWaba
3854,18
3297,23
7532,56
4962,60
12856,52
8293,50
20692,25
22403,88
Ewe
13167,72
6779,05
19339,03
53564,19
Tabella 4.10 – Deviazione standard dei tempi di scrittura su file (in ms).
75
Le tabelle 4.11 e 4.12 riportano i risultati ottenuti dalla misurazione, relativamente
all’operazione di lettura su file.
1 Mb
2 Mb
4 Mb
8 Mb
Jeode
91498,1
201732,3
397884,6
769549,7
CrEme
SuperWaba
35272,7
68018
62568,8
138754,2
138718,9
282489,9
248284,7
548836,9
Ewe
57600
94900
196500
446900
Tabella 4.11 - Tempi medi di lettura su file (in ms).
1 Mb
2 Mb
4 Mb
8 Mb
Jeode
2898,88
8051,88
15342,55
37210,72
CrEme
SuperWaba
4174,11
1078,11
6768,23
1496,21
11481,81
7627,87
17074,49
23308,71
Ewe
6866,99
2079,00
6587,02
18917,66
Tabella 4.12 – Deviazione standard dei tempi di lettura su file (in ms).
76
4.1.6 Operazioni di I/O su rete
Il tempo medio per le operazioni di input-output su rete, è inteso in termini di delay end
to end ed è stato calcolato dimezzando una stima del round trip time.
Si è posta particolare attenzione affinché il testbed fosse lo stesso per ogni processo di
misurazione, in particolare è stata configurata una rete privata mediante l’utilizzo di due
schede di rete Wi-Fi: una installata sul dispositivo palmare e l’altra su di un PC
portatile. La posizione relativa dei dispositivi è rimasta inalterata durante l’intero
processo di misurazione e per evitare eventuali conflitti, sull’utilizzo del canale di
comunicazione, è stato inserito un margine di tempo di sicurezza, dal lato client, tra la
ricezione di un messaggio e la trasmissione del successivo.
I risultati ottenuti sono riportati nella tabella 4.13. Ciascun elemento della tabella
rappresenta una media su cento campioni, al fine di verificare che in durante il calcolo
di tale media non vi siano state interferenze di rilievo sul canale di comunicazione, il
calcolo è stato eseguito più volte per ciascuna macchina virtuale
Jeode
CrEme
Ewe
SuperWaba
4,85
6,63
5,1
3,4
4,93
6,57
5,1
3,31
4,56
6,25
5,1
3,57
4,96
6,59
5.1
3,81
4,91
6,27
5,1
3,55
6,45
5,1
3,61
4,97
6,5
5,1
3,49
4,61
6,61
5,1
3,35
4,77
4,87
6,49
5,13
3,37
4,79
6,53
5,1
3,46
Media
4,822
6,489
5,103
3,492
DevStand 0,14172 0,133204 0,009487 0,14987402
Tabella 4.13 – Stime del ritardo di rete (in millisecondi).
.
77
4.2 Metriche quantitative: confronto
In tale paragrafo sono riportate le caratterizzazioni sintetiche delle grandezze misurate
attraverso il processo di misurazione ed è presentata un’analisi comparativa dei valori
riportati.
4.2.1 Impronta di memoria.
Nella tabella 4.14 sono riportati i risultati relativi all’impronta di memoria, espressi in
kilobyte.
Footprint Memory
Jeode
CrEme
SuperWaba
Ewe
2736 Kb
4448 Kb
360Kb
2048 Kb
Tabella 4.14 – Footprint Memory.
In figura 4.2 è visualizzata la comparazione relativa del fabbisogno di memoria richiesto
da ciascuna macchina virtuale.
4500
4000
3500
Kb
3000
Jeode
2500
CrEme
2000
SuperWaba
1500
Ewe
1000
500
0
Virtual Machine
Figura 4.2 – Impronte di memoria a confronto.
Si osservino i due estremi:
SuperWaba ha un fabbisogno di memoria, per la sua installazione, tanto esiguo da
essere adatta anche a dispositivi con capacità di memoria davvero limitate.
78
CrEme presenta invece una situazione diametralmente opposta: la sua richiesta di
memoria per l’installazione è consistente al punto da doverne tener conto anche nei
PDA di ultima generazione.
4.2.2 Multithreading
In tale sezione è proposta un’analisi comparativa del livello di multithreading
supportato dalle macchine virtuali java-compliant e delle prestazioni dell’algoritmo
multithread del prodotto matriciale.
4.2.2.1 Livello di multithread
In tabella 4.15 sono riportati i tempi, espressi in millisecondi, per la generazione del
numero di thread, NThread, sulle macchine virtuali Jeode e CrEme.
NThread TJeode
TCrEme
5
5211
25
10
24299
38
20
107427
60
50
640798
124
100
2927444
644
200
8962324
922
300
15434686
1222
trash
400
8587
500
trash
8915
1000
trash 445742
1100
trash 2348423
o.o.m.
1200
trash
Tabella 4.15 – Numero di thread presenti nel sistema e tempo per istanziarli (in ms).
Dall’analisi dei dati è possibile stabilire dei maggioranti per la stima del livello di
multithreading, in particolare:
•
Jeode: lanciando l’applicazione con un valore del numero di thread pari a 400, il
sistema non è in grado di istanziare il numero di thread desiderato, quando è
trascorso un tempo superiore alle 24 ore dall’inizio dell’esecuzione. Per cui si
può ritenere che il sistema sia andato in trash.
79
•
CrEme: l’applicazione eseguita sulla piattaforma CrEme continua ad istanziare
thread, fino a quando il sistema non lancia una eccezione del tipo out of memory
(o.o.m.). Da tale osservazione si può desumere che il livello di multithreading è,
nel caso di CrEme, strettamente legato alla capacità di memoria del dispositivo.
Nel caso in esame, un maggiorante è fissato in 1200 thread, con una memoria
disponibile di circa 33Mb.
Il fatto che il livello di multithread, nel caso di CrEme, sia strettamente legato alla
memoria del dispositivo, è un risultato che non desta stupore e che anzi ci si poteva
aspettare. Si Ricordi infatti che il modello dei thread di CrEme, blue thread, prevede
una gestione del multithread totalmente a carico della macchina virtuale, mentre nel
modello di gestione dei thread di Jeode, a ciascun thread java corrisponde un thread del
sistema operativo real-time.
Si analizza di seguito la variazione del tempo di esecuzione del thread FaiQualcosa, al
crescere del numero di thread nel sistema. La tabella 4.16 riporta la media dei risultati
ottenuti dall’esecuzione dell’applicazione.
Nthread
0
5
10
20
50
100
200
300
400
1000
1100
1200
Jeode
560.3
3196,5
5831,9
11091,4
26856,1
53125,2
105709,5
158177,7
trash
trash
trash
trash
CrEme
4177.8
5640,9
6624,1
9177,1
16879,3
29799,3
55522,2
81151,4
106609,7
324242,8
357896,8
o.o.m.
Tabella 4.16 – Tempi di esecuzione del thread FaiQualcosa al variare del numero NThread di thread.
Per meglio evidenziare la differenza delle prestazioni del thread FaiQualcosa, al variare
del numero di thread, si consideri la figura 4.3.
80
120000
100000
80000
ms
60000
Jeode
CrEme
40000
20000
0
0
5
10
20
50
100
200
NThread
Figura 4.3 – Tempi medi di esecuzione del thread FaiQualcosa.
Si osservi che il tempo di esecuzione del thread FaiQualcosa sulla macchina virtuale
Jeode, è molto minore del tempo di esecuzione dello stesso thread eseguito su CrEme,
quando nel sistema non vi sono altri thread a parte il thread principale. Al crescere del
numero di thread nel sistema si può notare, dal grafico, che il bilancio è favorevole a
Jeode finquando NThread si aggira intorno alla decina. Da un certo punto in avanti,
CrEme risulta avere prestazioni temporali nettamente inferiori rispetto a Jeode, il che
lascia supporre che la piattaforma CrEme abbia un tempo di cambio di contesto molto
minore rispetto a quello della piattaforma Jeode. Questo perché il modello di gestione
dei thread di CrEme, essendo gestito dalla macchina virtuale, ha un contesto da salvare
più leggero. Tale aspetto risulta essere però controbilanciato da un uso intensivo della
memoria, come conferma l’utilizzo del monitor di memoria durante l’esecuzione
dell’applicazione realizzata e il fatto che il livello di multithreading sia limitato dalla
memoria disponibile del dispositivo palmare.
Le precedenti considerazioni spingono ad ipotizzare che, per quanto riguarda gli
algoritmi multithread, Jeode abbia un maggiore overhead in termini di utilizzo della
CPU rispetto a CrEme la quale sembra avere un overhead maggiore in termini di
utilizzo della memoria rispetto alla prima piattaforma.
81
4.2.2.2 Prestazioni di un algoritmo multithread
La tabella 4.17 mostra i risultati medi ottenuti, per le varie piattaforme, al variare delle
dimensioni delle matrici.
Dim
20
50
100
110
145
150
Jeode
CrEme
SuperWaba Ewe
5137,3
1650,4
416,2
1000
36122,8
11797,2
13771
20900
138166
47549,9
213377,8
218200
170229,8
o.o.m.
316321,5
304300
297889,5
o.o.m.
o.o.m.
948500
347803,1
o.o.m.
o.o.m.
o.o.m.
Tabella 4.17 Tempi medi di esecuzione (in ms) dell’algoritmo multithread (o.o.m.- out of memory).
Le figure 4.4 e 4.5 evidenziano le differenze di prestazioni quando l’algoritmo
multithread è eseguito su tutte le piattaforma considerate.
1000000
900000
800000
700000
600000
ms 500000
400000
300000
200000
100000
0
Jeode
CrEme
SuperWaba
Ewe
20
50
100
110
145
150
Dimensione matrici
Figura 4.4 – Prestazioni dell’algoritmo al variare delle dimensioni delle matrici. L’assenza di una barra
vuol dire che la macchina virtuale corrispondente, ha prodotto una eccezione del tipo out of memory.
82
40000
35000
30000
25000
Jeode
CrEme
SuperWaba
Ewe
ms 20000
15000
10000
5000
0
20
50
Dimensione matrici
Figura 4.5 - Particolare della figura 4.4.
Dall’analisi delle figure si osserva che fino a quando la dimensione delle matrici non
supera un certo valore, le prestazioni migliori, in termini temporali, le offrono le
macchine virtuali Java-based. Si ricordi però che esse non offrono un vero e proprio
supporto al multithreading.
Al crescere delle dimensioni delle matrici, si nota che le piattaforme Java-based
cominciano a peggiorare le loro prestazioni nei confronti delle macchine Javacompliant. Questo perché aumentare le dimensioni delle matrici equivale ad accrescere
quadraticamente il numero di thread.
Differenziando l’analisi per le due famiglie di macchine virtuali, sia ha:
•
Java-based: Ewe risulta avere prestazioni migliori dal punto di vista dell’utilizzo
della memoria, l’applicazione eseguita sulla piattaforma Ewe lancia infatti una
eccezione out of memory per un valore maggiore delle dimensioni delle matrici
rispetto a SuperWaba. Quest’ultima ha, però, prestazioni migliori, dal punto di
vista temporale, finquando la dimensione delle matrici si aggira intorno al
centinaio.
•
Java-compliant: i risultati confermano le ipotesi fatte nell’analisi del livello di
multithreading, in relazione all’overhead e al tempo di cambio di contesto, degli
algoritmi multithread.
83
4.2.3 Tempo di chiamata a metodi
Il tempo di chiamata a metodi, è inteso in termini di:
•
tempo medio di chiamata di un metodo senza parametri;
•
tempo medio di chiamata di un metodo con un parametro elementare;
•
tempo medio di chiamata di un metodo con un parametro strutturato.
Nella tabella 4.18 sono riportati i risultati sperimentali ottenuti per le varie macchine
virtuali.
A
B
C
Jeode
CrEme
SuperWaba Ewe
1,40E-04
6,64E-04
1,59E-03
3,60E-03
1,45E-04
7,38E-04
1,75E-03
3,90E-03
1,43E-04
7,39E-04
1,75E-03
3,90E-03
Tabella 4.18 – Tempi medi di chiamata a metodi (in ms): A – senza parametri; B – con un parametro
elementare; C – con un parametro strutturato
In figura 4.6 meglio si evidenzia la comparazione tra i risultati ottenuti dalle differenti
piattaforme
84
Jeode
CrEme
SuperWaba
Ewe
4,00E-03
3,50E-03
3,00E-03
2,50E-03
ms 2,00E-03
1,50E-03
Ewe
SuperWaba
CrEme
1,00E-03
5,00E-04
Un parametro
strutturato
Jeode
Un parametro
elementare
Senza parametri
0,00E+00
Figura 4.6 – Tempi medi di chiamata a metodi (in millisecondi).
La figura precedente si commenta da sola, piuttosto è interessante avanzare l’ipotesi che
Jeode abbia un maggiore overhead in termini di utilizzo della CPU, seguita nell’ordine
da CrEme, SuperWaba ed Ewe.
85
4.2.4 Overhead delle macchine virtuali
Nella figura 4.7 è mostrata la comparazione dell’overhead, in termini di quantità media
di memoria utilizzata, dalle varie macchine virtuali.
4,00
3,00
Mb 2,00
1,00
0,00
Virtual Machine
Jeode
3,15
CrEme
2,65
SuperWaba
0,45
Ewe
1,30
Jeode
CrEme
SuperWaba
Ewe
Figura 4.7 – Runtime Memory.
Si noti che la macchina virtuale che fornisce la stima più bassa è SuperWaba. Un valore
così contenuto del runtime memory ed una esigua impronta di memoria, hanno favorito
lo sviluppo della piattaforma SuperWaba in un momento in cui i dispositivi mobili
erano molto modesti dal punto di vista delle risorse hardware.
86
4.2.5 Operazioni di I/O su file
Il tempo per le operazioni di Input/Output su file sono relative al tempo medio di
scrittura e al tempo medio di lettura
di un file, al variare delle dimensioni di
quest’ultimo.
4.2.5.1 Scrittura
La tabella 4.19 mostra i risultati medi ottenuti lanciando la relativa applicazione sulle
differenti macchine virtuali.
1 Mb
2 Mb
4 Mb
8 Mb
Jeode
85942,4
173465,8
344502
684094,9
CrEme
SuperWaba
127163,5
68521,1
249476,3
150381,2
506416,4
302278,8
966851,8
539380,6
Ewe
583500
1089800
2188900
4644700
Tabella 4.19 – Tempi medi di scrittura su file (in ms).
Jeode
CrEme
SuperWaba
Ewe
5000000
4500000
4000000
3500000
3000000
ms 2500000
2000000
1500000
1000000
Ewe
SuperWaba
CrEme
500000
0
1 Mb
2 Mb
Jeode
4 Mb
8 Mb
Figura 4.8 – Comparazione dei tempi medi di scrittura.
87
La figura 4.8 evidenzia che i tempi medi di scrittura su file hanno un andamento lineare
con la dimensione del file stesso.
Le prestazioni migliori le offrono, in ordine, le piattaforme SuperWaba e Jeode. Ewe
risulta essere poco efficiente per quanto concerne la scrittura su file.
4.2.5.2 Lettura
La tabella 4.20 mostra i risultati medi, ottenuti eseguendo la relativa applicazione sulle
differenti piattaforme.
Jeode
91498,1
201732,3
397884,6
769549,7
1 Mb
2 Mb
4 Mb
8 Mb
CrEme
SuperWaba
35272,7
68018
62568,8
138754,2
138718,9
282489,9
248284,7
548836,9
Ewe
57600
94900
196500
446900
Tabella 4.20 - Tempi medi di lettura su file (in msec).
800000
700000
600000
500000
Jeode
CrEme
ms 400000
SuperWaba
Ewe
300000
200000
100000
0
1 Mb
2 Mb
4 Mb
8 Mb
Figura 4.9 - Comparazione dei tempi medi di lettura.
Dalla figura 4.9 è possibile notare l’andamento lineare anche per l’operazione di lettura,
inoltre la piattaforma Ewe presenta tempi medi di lettura molto minori rispetto ai tempi
medi di scrittura (circa un ordine di grandezza).
88
4.2.6 Operazioni I/O su rete
In figura 4.10 è mostrata la comparazione dei valori medi delle stime del ritardo di rete,
per le differenti macchine virtuali:
8
6
ms 4
2
0
Virtual Machine
Jeode
4,822
CrEme
6,489
SuperWaba
3,492
Ewe
5,103
Figura 4.10 – Ritardo di rete (msec).
Le prestazioni migliori, in termini di ritardo di rete, risultano essere quelle di
SuperWaba. In relazione a tale risultato è importante osservare che la piattaforma
SuperWaba implementa metodi di lettura e scrittura direttamente sull’oggetto di tipo
socket5. È possibile, quindi, ipotizzare che questo aspetto concorra ad ottimizzare il
ritardo di rete della macchina virtuale.
5
Il metodo della lettura sulla socket, è non bloccante.
89
4.3 Metriche quantitative: valutazioni e confronto
In tale paragrafo è riportata una valutazione delle metriche qualitative definite, in
un’ottica comparativa.
4.3.1 Disponibilità
In tabella 4.21 è riportata la disponibilità delle macchine virtuali, per i principali sistemi
operativi per dispositivi palmari.
WindowsCE/PocketPC
PalmOS
Linux
Jeode
a
CrEme
a
a
a
SuperWaba
a
a
Ewe
a
a
Tabella 4.21 – Disponibilità delle macchine virtuali.
Si osservi che SuperWaba è l’unica piattaforma ad essere disponibile sia per i
dispositivi basati su WindowsCE/PocketPC sia su quelli basati su PalmOS, per contro
non è stata ancora implementata una versione per i linux PDA.
Le restanti macchine virtuali presentano invece uniformità di disponibilità, se si
considera che CrEme è la versione CE di JSCP e che quest’ultima è disponibile anche
per i sistemi linux.
90
4.3.2 Ciclo di sviluppo
Le applicazioni destinate ad essere eseguite sulle varie macchine virtuali, hanno cicli di
sviluppo differenti. In tale paragrafo è presentato un confronto tra i cicli di sviluppo.
Innanzitutto è possibile osservare una similitudine, dei cicli di sviluppo, in dipendenza
del fatto che essi siano relativi alle macchine Java-compliant o Java-based.
•
Java-compliant: Il ciclo di sviluppo di un’applicazione destinata ad essere
eseguita sulle piattaforme Jeode e CrEme, è analogo a quello di un’applicazione
da eseguirsi sul Java runtime. Tale caratteristica è quindi da considerarsi un
requisito desiderabile per quei programmatori che sono soliti sviluppare
applicazioni in Java.
•
Java-based: tali macchine virtuali hanno un ciclo di sviluppo più articolato
rispetto alle precedenti. Trattiamo separatamente i due ambienti:
o SuperWaba: è indispensabile la generazione dei file eseguibili. Tale
operazione è realizzata attraverso l’esecuzione di due applicazioni Java
(da computer desktop) che non hanno ambiente grafico.
o Ewe: la generazione del file eseguibile è auspicabile ma non
obbligatoria. Una applicazione può essere eseguita, sul dispositivo
palmare, anche a partire dal bytecode. In tal caso, però, è necessario che
il file in questione sia contenuto in una cartella di nome classes. Inoltre
l’applicazione per la generazione del file eseguibile è dotata di ambiente
grafico, per cui ha un impatto più immediato, sull’utente, rispetto alla
piattaforma SuperWaba.
91
4.2.3 Classi supportate
In tabella 4.22 è riportata una comparazione tra le tipologie di package messi a
disposizione dagli ambienti di esecuzione delle piattaforme considerate.
Java.lang
Util
I/O
Net
Zip
Reflect
Math
trattamento dei dati
RMI
Security
SQL
Applet
User Interface
Game API
Accesso registri di sistema
Visualizzazione dati GPS
Protocollo Garmin GPS
Classi specifiche per PPC e PalmOS
API di comunicazione tra PC e PDA
Jeode
a
a
a
a
a
a
a
a
a
a
a
a
a
CrEme
a
a
a
a
a
a
a
a
a
a
a
a
a
SuperWaba
a
a
a
a
a
a
a
Ewe
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
Tabella 4.22 – API a confronto.
Le macchine virtuali Jeode e CrEme sono molto simili dal punto di vista delle classi
supportate, d’altra parte sono entrambe Java-compliant: Jeode PDA Edition è
un’implementazione certificata di Personal Java, CrEme 4.0 è una implementazione
della configurazione CDC con il Foundation Profile e Personal Profile.
Le macchine virtuali Java-based forniscono API molto specifiche per i dispositivi su cui
sono disponibili. Inoltre esse hanno il supporto per le Game API (profilo non ancora
implementato dall’ambiente J2ME).
92
4.2.4 Interfaccia utente
In tabella 4.23 è evidenziato il tipo di interfaccia utente messo a disposizione da
ciascuna macchina virtuale. Va precisato che le piattaforme Ewe e SuperWaba hanno
interfacce grafiche che non sono propriamente le java swing, ma che sono paragonabili
ad esse in termini di funzionalità.
Jeode
Truffle
AWT
Swing
a
CrEme
a
a
opt
SuperWaba
Ewe
a
a
Tabella 4.23 – Interfaccie utente disponili sulle macchine virtuali (opt - opzionale).
Da notare che Jeode e CrEme sono analoghe anche dal punto di vista dell’interfaccia
utente, se si considera che le GUI Truffle sono una versione particolarmente leggera
delle AWT e si prescinde dalle Swing API che, sulla piattaforma CrEme, hanno una
installazione opzionale.
93
4.2.5 Compatibilità con Java
Per compatibilità con Java si intende, in tale contesto, l’entità delle modifiche che
bisogna apportare ad un codice sorgente, concepito per essere eseguito sul runtime Java
standard, affinchè esso possa essere eseguito sulle macchine virtuali per i dispositivi
mobili.
Per quanto riguarda le macchine virtuali java-compliant, la compatibilità è completa a
patto che nel codice di partenza siano state utilizzate classi supportate dagli ambienti di
esecuzione delle PDA virtual machine. Offrendo Jeode e CrEme le stesse API, esse
hanno lo stesso livello di compatibilità.
Discorso a parte meritano le macchine virtuali java-based, esse infatti non
implementano alcuna libreria java standard, per cui seppure il linguaggio di
programmazione per lo sviluppo delle applicazioni ha una sintassi java, è sempre
necessaria una modifica del codice sorgente.
Nell’ambito delle macchine Java-based, Ewe e SuperWaba sono profondamente diverse
nei riguardi della compatibilità con Java.
SuperWaba necessita di una vera e propria ristrutturazione del codice, ciò è evidente fin
da subito considerando il fatto che le applicazioni scritte per essa devono
obbligatoriamente estendere una classe, MainWindow, che è l’equivalente del metodo
main di Java.
Ewe, invece, pur non definendo librerie conformi alle specifiche Java standard, ha
dedicato particolare attenzione al processo di migrazione delle applicazioni Java in
applicazioni Ewe. Per cui per la conversione di un programma Java in uno Ewe, spesso
è sufficiente sostituire i package Java con i package Ewe e aggiungere, o modificare,
poche linee di codice dell’applicazione.
In definitiva Ewe ha un grado di compatibilità con Java, nettamente superiore rispetto a
SuperWaba.
94
Conclusioni
Il recente sviluppo di Java come vero e proprio linguaggio di programmazione,
accompagnato dall’ evoluzione e dal conseguente sviluppo di mercato dei dispositivi
palmari, accresce l’interesse riguardo l’uso di Java sui piccoli dispositivi.
L’attuale stato della tecnologia propone uno scenario alquanto eterogeneo, infatti i test
sperimentali eseguiti sul testbed hanno dimostrato che, a parità di sistema operativo,
non si ha uniformità di risultati nelle prestazioni delle differenti macchine virtuali.
Risulta quindi fondamentale l’implementazione delle java virtual machine, ma è
altrettanto basilare l’ottimizzazione delle API messe a disposizione da ciascuna
piattaforma.
Non è possibile eleggere una macchina virtuale principe in assoluto, ma è possibile
discernere in termini relativi in base ai requisiti dei dispositivi e al relativo campo di
impiego.
Ad esempio, se si dispone di dispositivi palmari di prima generazione, la scelta è in
pratica obbligata verso la piattaforma SuperWaba, il cui ridottissimo fabbisogno di
memoria ha per anni favorito la sua diffusione.
Se invece si hanno a disposizione palmari di ultima generazione e si richiede un reale
supporto al multithreading, è possibile scegliere tra le piattaforme Jeode e CrEme.
La prima ha un livello di multithreading più spinto, ma presenta un elevato overhead in
termini di utilizzo della memoria (il livello di multithreading è strettamente correlato
con la memoria disponibile). Tale aspetto merita particolare attenzione dal momento che
l’impronta di memoria di tale piattaforma ha dimensioni ragguardevoli.
La seconda ha invece un overhead, in termini di utilizzo della CPU, tale da innescare
dinamiche di trashing al crescere del numero di thread (il livello di multithreading è
limitato dall’elevato utilizzo del processore).
Infine resta da considerare il fatto che la piattaforma Ewe ha talvolta prestazioni, in
termini di tempo di esecuzione, nettamente inferiori rispetto alle altre macchine virtuali.
Essa fornisce, però, una interfaccia utente di tipo advanced similmente a SuperWaba e,
rispetto a quest’ultima, presenta una maggiore compatibilità con Java standard.
95
APPENDICE A
In tale appendice è descritto un esempio completo di installazione della piattaforma
SuperWaba sul dispositivo palmare, dell’emulatore sul computer desktop e lo sviluppo,
comprensivo del testing sull’emulatore, di un esempio semplice.
A.1 Istallazione di SuperWaba su PC Desktop (Windows 98 e superiori)
Si espleta attraverso i seguenti passi:
•
Copia della cartella SuperWabaSDK sul proprio disco di lavoro
(C:\SuperWabaSDK).
•
Creazione di una cartella di nome “SuperWaba” sul disco (C:\SuperWaba).
•
Copia nella cartella C:\SuperWaba dei seguenti file:
ü C:\SuperWabaSDK\lib\WIN32\SuperWaba.exe
ü C:\SuperWabaSDK\lib\XPLAT\SuperWaba.pdb
ü C:\SuperWabaSDK\lib\MSW.pdb oppure 5SW.pdb oppure HSW.pdb
oppure LSW.pdb oppure MSW2X.pdb
ü Ogni
altra
libreria
necessaria,
contenuta
nella
cartella
C:\SuperWabaSDK\lib\XPLAT
96
A.2 Installazione di SuperWaba sul palmare (Compaq iPAQ 3970)
Per installare la piattaforma sul dispositivo mobile è possibile seguire due strade:
•
Installazione automatica: è sufficiente disporre di un collegamento activeSync e
mandare in esecuzione, da postazione fissa, il file CEinstall_RunMe.bat
contenuto nella cartella C:\SuperWabaSDK\lib\CE.
•
Installazione manuale: bisogna copiare i seguenti file nella cartella \SuperWaba
del dispositivo:
ü SuperWaba.exe (Macchina Virtuale).
ü SuperWaba.pdb (API).
ü MSW.pdb (font).
ü Ogni altra libreria opzionale necessaria.
Il kit mette a disposizione diverse versioni della macchina virtuale a seconda del
tipo di processore del dispositivo mobile. La versione corretta è, nel nostro caso,
quella contenuta nella cartella C:\SuperWabaSDK\lib\ce\PocketPC\ARM.
97
A.3 L’applicazione
Si tratta del classico esempio HelloWorld. Il programma utilizza i seguenti oggetti,
appartenenti alle GUI API di SuperWaba:
ü un box per la visualizzazione di un messaggio di testo,
ü un tastino per la chiusura dell’applicazione;
ü un gestore di eventi.
Il codice completo è riportato di seguito:
HelloWorld.java
import waba.ui.*;
public class HelloWorld extends MainWindow
{
Button btnOff;
ListBox lb;
public HelloWorld()
{
super("Hello World!",TAB_ONLY_BORDER);
}
public void onStart()
{
add(lb = new ListBox(),LEFT, TOP+1);
add(btnOff = new Button("off"),RIGHT, SAME);
lb.setRect(LEFT,AFTER+3,FILL,FILL);
lb.add("Salve mondo, sono Ciccio!");
}
public void onEvent(Event e)
{
if (e.type == ControlEvent.PRESSED)
{
if (e.target == btnOff){
exit(0);
}
}
}
}
98
A.4 Compilazione e generazione degli eseguibili
La sequenza completa delle comandi è visualizzata in figura A.1:
Figura A.1 – Compilazione ed esecuzione. Comando Warp: c – crea; /c – override dell’identificatore
dell’archivio pdb. Comando Exegen: /e – crea eseguibile; /l – crea un link; /c deve essere lo stesso di
cui al comando Warp.
Assicurarsi di impostare correttamente i path di esecuzione e la variabile di ambiente
classpath. Di seguito si riportano i comandi necessari a configurare l’ambiente di
esecuzione sul computer desktop:
set PATH=C:\j2sdk1.4.1_01\bin;%PATH%
set CLASSPATH=%CLASSPATH%;C:\SuperWabaSDK\lib\SuperWaba.jar;C:
\SuperWabaSDK\Utils
Tali comandi possono essere lanciati da shell di windows oppure memorizzati in un file
batch.
99
A.5 Esecuzione
L’applicazione può essere mandata in esecuzione:
o sull’emulatore;
o sul dispositivo mobile;
o attraverso applet java.
•
Mediante emulatore SuperWaba sul PC desktop, attraverso il seguente comando:
C:\SuperWaba>superwaba HelloWorld HelloWorld aaaa
Figura A.2 – Esecuzione mediante emulatore .
100
•
Mediante applet sulla Java Virtual Machine, con il comado:
C:\SuperWaba\HelloWorld>java waba.applet.Applet HelloWorld
Figura A.3 – Esecuzione mediante applet.
•
Sul dispositivo palmare eseguiendo le azioni seguenti:
ü creare la cartella, \SuperWaba\HelloWorld , sul palmare;
ü copiare nella cartella precedente i file HelloWorld.pdb e HelloWorld.exe;
ü copiare il file HelloWorld.lnk in un directory qualsiasi del file system.
101
APPENDICE B
In tale appendice è descritto un esempio completo di installazione della piattaforma Ewe
sia sul dispositivo palmare sia sul computer desktop. Inoltre è presentato lo sviluppo di
un esempio semplice.
B.1 Istallazione di Ewe su PC Desktop (Windows version)
L’installazione della macchina virtuale Ewe, sulla propria postazione di lavoro, è
realizzata mandando in esecuzione il seguente file eseguibile, reperibile sul sito
ufficiale:
Ewe-Win32.exe
Inoltre bisogna essere sicuri di aver copiato, sul disco di lavoro, il file contenente le
librerie della piattaforma:
Ewe-Classes.zip
A tal proposito si consiglia di predisporre la macchina nel modo indicato in figura B.1:
Figura B.1 – Installazione delle cartelle della piattaforma Ewe.
102
B.2 Installazione di Ewe sul palmare (Compaq iPAQ 3970)
Installazione automatica: è sufficiente disporre di un collegamento activeSync e
mandare in esecuzione, da postazione fissa, il file Ewe-PocketPC-v130.zip.
B.3 L’ applicazione
Si tratta ancora una volta dell’esempio classico HelloWorld. Il programma utilizza un
oggetto, appartenente alle GUI API di Ewe, mediante il quale è possibile realizzare una
finestra di pop-up con una intestazione. Nella finestra si può visualizzare del testo e
inserire un tastino che chiude la finestra col mouse o attraverso la pressione del tasto
enter.
Il codice completo è riportato di seguito6:
HelloWorld.java
import ewe.sys.*;
import ewe.ui.*;
public class HelloWorld {
public static void main(String args[])
{
Vm.startEwe(args);
MessageBox mb = new MessageBox(
"Hello World",
"Salve Mondo, sono Ciccio!",MessageBox.MBOK);
mb.execute();
Vm.exit(0);
}
}
6
La prima e l’ultima istruzione del metodo main devono essere rispettivamente Vm.startEwe(args) e
Vm.exit(0).
103
B.4 Compilazione e generazione degli eseguibili
La generazione del bytecode, a partire dal file sorgente, è realizzata attraverso un
qualsiasi compilatore Java. Assicurarsi di impostare correttamente i path di esecuzione e
la variabile di ambiente classpath. Di seguito si riportano i comandi necessari a
configurare l’ambiente di esecuzione sul computer desktop:
set PATH=C:\j2sdk1.4.1_01\bin;%PATH%
set PATH=C:\Program Files\Ewe;%PATH%
set CLASSPATH=%CLASSPATH%;C:\ewe\Ewe-SDKClasses-v130\classes\EweClasses.zip
Tali possono essere lanciati da shell di windows oppure memorizzati in un file batch.
Il file eseguibile ha estensione “ewe” sia per il dispositivo mobile che per il PC, e può
essere lanciato a patto di aver installato correttamente le rispettive macchine virtuali.
Il file eseguibile si ottiene dal bytecode attraverso il programma Jewel.ewe.
104
Figura B.2 – Jewel.ewe: consente di generare gli eseguibili per la piattaforma Ewe.
Il file Jewel.ewe si trova nella directory C:\ewe\Ewe-SDKUtilities-v130\programs.
In figura B.2 è riportata un’istantanea del processo di generazione del file
HelloWorld.ewe, mentre in figura B.3 è riportato l’insieme dei file che sono necessari
alla generazione del file eseguibile.
Figura B.3 – Preview Files
105
B.5 Esecuzione
Se l’applicazione è senza parametri d’ingresso, allora la generazione del link non è
necessaria, basta copiare il file HelloWorld.ewe sul dispositivo palmare e lanciarlo come
qualsiasi altro programma eseguibile.
Se invece l’applicazione prevede parametri è necessario creare un collegamento
all’applicazione mediante il Launcher della macchina virtuale Ewe, ewe.exe, che si
trova nella cartella C:\Program Files\Ewe.
Figura B.4 – La Ewe VM, si presenta sottoforma di Launcher.
L’applicazione può essere mandata in esecuzione anche senza la generazione
dell’eseguibile:
o Su PC: lanciando il comando C:\ewe HelloWorld;
o Su PDA: copiando il file HelloWorld.class in una cartella sul palmare di nome
classes e riferendo tale file tramite il launcher della macchina virtuale.
Figura B.5 – Salve Mondo!
106
Bibliografia
[Pressman]
R. Pressmam, “Principi di Ingegneria del Software”, Terza
edizione,
McGraw-Hill, 2000.
[Jeode]
http://www.insignia.com/, Insignia Solutions.
[CrEme]
http://www.nsicom.com/, NSI Group.
[SWaba]
http://www.superwaba.com.br/.
[Ewe]
http://www.ewesoft.com/.
[HaOCon]
I. Haque, B. O’Connor, “J2ME Enterprise Development”, Wiley
US, 2002.
[J2ME]
http://java.sun.com/j2me/, Sun Microsystems
[JCP]
http://www.jcp.org/, Java Community Process
[J2SE]
http://java.sun.com/j2se/, Sun Microsystems
[JSCPTM]
NSICom, The JSCP Thread Model, 1999
[Herbert]
S. Herbert, “Java 2: la guida completa”, quinta edizione, McGrawHill, 2003
[Fadini]
A cura di B. Fadini, “Sistemi Informatici e Calcolo Parallelo”,
Franco Angeli, 1991
[Tanenbaum]
A. S. Tanenbaum, “Reti ci calcolatori”, quarta edizione, Addison
Wesley, 2003
107