Facoltà di Ingegneria · ANALISI E VALUTAZIONE DI MACCHINE VIRTUALI JAVA PER DISPOSITIVI MOBILI...

i

UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO

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

ii

A mio padre,

che ha lasciato un vuoto incolmabile

dentro di me. A mia madre.

iii

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!

iv

Introduzione 1

Cenni preliminari 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 18

1.3.3.1 Differenze di linguaggio 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.4 Le API di CreMe 38

2.3 SuperWaba 39




v

2.3.4 Le API di SuperWaba 46

2.4 Ewe 48

2.4.1 Disponibilità. 49



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

vi

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 89

4.3 Metriche quantitative: valutazioni e confronto 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

1

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 Entità Efficienza Multithreading; Chiamate a metodi;

Overhead; Interoperabiltà Operazioni di Input-Output su file e su rete;

Compatibilità con Java Usabilità Ciclo di sviluppo, Interfaccia grafica, Classi

supportate Portabilità 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.

2

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. Metrica quantitativa Efficienza 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; • 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].

3

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.

4

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.

5

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.

6

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.

7

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

8

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.

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

Sistema Operativo Nativo

Java Virtual Machine

Configurazione

Profilo Profilo opzionale Java

API specifiche

Applicazione Nativa

Applicazione J2ME Applicazione J2ME

9

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,

10

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,

per dispositivi quali telefoni cellulari.

Marzo 2003

CDC v. 1.0a JSR-36 Connected Device Configuration, fornisce un

ambiente più esteso per dispositivi più complessi.

Agosto 2002

Tabella 1.1 - Le principali configurazioni J2ME attualmente disponibili

11

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 Release

MIDP v. 2.0 JSR-118 Estende la configurazione CLDC con classi

abstract per le UI e per il Networking.

Novembre

2002

Foundation Profile v.

1.0JSR-46

Estende CDC, richiede almeno un profile

addizionale per essere completo.

Marzo 2001

Personal Profile v. 1.0

JSR-62

Profilo per piccoli devices che sostiuisce

Personal Java 1.1.x e 1.2.x.

Settembre 2002

RMI Profile v.1.0 JSR-

66

Fornisce il supporto opzionale RMI. Giugno 2002

PDA Profile JSR-75 Profilo più completo rispetto a MIPD, si

poggia su CLDC ed è destinato ai PDA.

ICDO

Game Profile JSR-134 Pensato per lo sviluppo di giochi sul J2ME

environment

ICDO

Tabella 1.2 – Alcuni profili disponibili e altri in corso d’opera (ICDO).

12

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.

http://www.jcp.org/

13

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

CLDC

CDC

J2SE

14

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.

15

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.

16

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,

17

è 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 class-

loader 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 device-

specific 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.

18

In tabella 1.3 sono illustrati i packages facenti parte della configurazione CLDC,

accompagnati da una breve descrizione.

Package Funzione

java.io classi: 11

interfacce: 5

eccezioni: 5

Consente la lettura e la scrittura dei flussi di di

I/O. Non supporta le classi BufferedStream ma

fornisce 5 implementazioni delle classi astratte

InputStream e OutputStream.

java.lang classi: 15

interfacce: 1

eccezioni: 19

Fornisce classi che sono il cuore del linguaggio

Java. Nel package sono inclusi gli oggetti

System, Thread e Runtime e la classe Math.

java.util classi: 7

interfacce: 1

eccezioni: 2

Contiene utility per la manipolazione delle

informazioni di data e ora e supporta le Java

Collection di base.

javax.microedition.io classi: 1

interfacce: 8

eccezioni: 1

E’ l’unico package specifico: implementa

classi supplementari di I/O e fornisce le

funzionalità del package java.net di J2SE.

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.

19

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

20

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.

21

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 Funzione java.io classi: 36 interfacce: 10 eccezioni: 16

Consente la lettura e la scrittura dei flussi di di I/O. Tale package contiene molte delle classi omesse in CLDC.

java.lang classi: 30 interfacce: 3 eccezioni: 24

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.

java.lang.ref classi: 5 interfacce: 0 eccezioni: 0

Contiene i reference types tra cui weak refernces.

java.lang.reflect classi: 8 interfacce: 2 eccezioni: 2

Fornisce le API di reflection

java.math classi: 1 interfacce: 0 eccezioni: 0

Contiene la sola classe BigInteger e i metodi per lavorare con oggetti del tipo BigInteger.

java.net classi: 12 interfacce: 5 eccezioni: 6

Sottoinsieme dell’omonimo package di J2SE. Consente connessioni http url-based e comunicazioni connectionless con datagrammi.

java.security, java.security.cert classi: 21 interfacce: 6 eccezioni: 13

Supporta le funzionalità di sicurezza

java.text, java.text.resources classi: 11 interfacce: 0 eccezioni: 1

Fornisce caratteristiche di internazionalizzazione per il supporto di lingue multiple

java.util, java.util.jar, java.util.zip classi: 44 interfacce: 11 eccezioni: 7

Contiene ultilities per la manipolazione di data e ora e implementa le java collections di base.

javax.microedition.io classi: 1 interfacce: 8 eccezioni: 1

Implementa classi supplementari di I/O

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

22

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 - - -

Javax.microedition.io - - - 1 8 1 1 8 1 Tabella 1.5 – Java Environment a confronto (C - Classi; I - Interfacce; E - Eccezioni).

23

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 CDC-

based. 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.

24

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;

25

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.

26

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.

Figura 1.3 – Ciclo di vita di una MIDlet: transizioni degli stati.

Active

Paused Destroyed

pauseApp()

startApp()

destryApp()

constructor

27

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

http://java.sun.com/j2me/download.html

28

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 Java-

compliant1 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.

29

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.

30

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.

31

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 start-

up. 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.

Figura 2.2 – Java thread su un sistema operativo real-time (RTOS).

RTOS Task A

Task B

Task C

Java Thread X

Java Thread Y

32

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.

.

33

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.

34

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.


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.

35


Nella tabella 2.3, sono riportate alcune caratteristiche dell’ambiente CrEme, suddivise

per aree chiave:

Virtual Machine


generazione del codice nativo basata sulla tecnologia Just In Time

Garbage Collection di tipo asincrona


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

36

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.

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.

CrEme Kernel

RTOS

Java Thread V

Java Thread U

Java Thread Z

Java Thread Y

Java Thread X

CrEme Task

OS Task A

OS Task B

OS Task C

OS Task D

37


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:


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.

38

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.

39

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.

40


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.

41

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)

42


Nella tabella 2.5, sono riportate le principali caratteristiche dell’ambiente SuperWaba,

suddivise per aree chiave:

Virtual Machine



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).

43

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).

44


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:


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.

http://www.superwaba.com.br/

45

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.

46

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 Tale package contiene alcune delle classi del package originale

java.lang, e di queste possiede solo un sottoinsieme dei metodi.

waba.fx Contiene classi per i fonts, classi geometriche e classi per la gestione

delle immagini e dei suoni.

waba.io Classi base per l’I/O, per accedere ai file PDB, per la gestione delle

socket e delle porte seriali.

waba.sys

Tale package contiene le classi che si interfacciano con le

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.

waba.util

Classi di utilità per la gestione delle date e per la generazione dei

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.

47

Package di estensione (installazione opzionale)

superwaba.ext.palm.io.builtin Tratta con applicazioni proprie di Palm OS:

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.

superwaba.ext.xplat.io.scanner Classi per supportare il simbolo scanner per Palm

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.

superwaba.ext.xplat.ui Classi di interfaccia utente, forniscono funzionalità

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 Definiscono il comportamento per le librerie di stampa.

superwaba.ext.xplat.io.search 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.

48

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.

49

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.

50


Nella tabella 2.9, sono riportate alcune caratteristiche dell’ambiente Ewe, suddivise per

aree chiave:

Virtual Machine

Supportata da diverse piattaforme hardware


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.

51


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;

http://www.ewesoft.com/

52

• 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.

53

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.

54

2.5 Considerazioni comparative

In tabella 2.11 è riportata una comparazione tra i package messi a disposizione dagli

ambienti di esecuzione delle piattaforme considerate.

Jeode CrEme SuperWaba Ewe Java.lang a a a a

Util a a a a

I/O a a a a

Net a a a a

Zip a a a a

Reflect a a a

Math a a a a

trattamento dei dati a a a a

RMI a a Security a a a a

SQL a a a a

Applet a a User Interface a a a a

Game API a a

Accesso registri di sistema a

Visualizzazione dati GPS a Protocollo Garmin GPS a Classi specifiche per PPC e PalmOS a API di comunicazione tra PC e PDA 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.

55

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:

Figura 3.1 - La qualità caratterizzata attraverso un insieme finito e definito di attributi.

Modello

Efficienza Interoperabilità Usabilità Portabilità

56

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

57

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.

58

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.

59

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).

60

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.

61

• 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%.

62

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.

63

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.

64

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.

65

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.

66

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.

67

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)

68

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.

Figura 4.1 – Metriche quantitative e qualitative.

Metriche

• 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.

• Piattaforme hw-sw che supportano le VM.

• Ciclo di sviluppo • Tipologia di classi

supportate • Tipo di supporto alle

Graphical User Interface. • Compatibilità con java.

Quantitative Qualitative

69

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:

Jeode CrEme SuperWaba Ewe

Footprint Memory 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 java-

compliant 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.

70

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 Jeode CrEme TFN - -

0 TFQ 560.3 4177.8 DTFQ 10.62 34.50 TFN 5211 25

5 TFQ 3196.5 5640.9 DTFQ 36.93 58.50 TFN 24299 38

10 TFQ 5831.9 6624.1 DTFQ 9.10 27.14 TFN 107427 60

20 TFQ 11091.4 9177.1 DTFQ 12.83 28.39 TFN 640798 124

50 TFQ 26856.1 16879.3 DTFQ 4.36 17.13 TFN 2927444 644

100 TFQ 53125.2 29799.2 DTFQ 11.20 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).

71

NThread Jeode CrEme TFN 8962324 922

200 TFQ 105709.5 55522.2 DTFQ 46.91 36.52 TFN 15434686 1222

300 TFQ 158077.7 81151.4 DTFQ 10.03 35.62 TFN trash 8587

400 TFQ - 106609.7 DTFQ - 57.45 TFN trash 445742

1000 TFQ - 324242.8 DTFQ - 54.94 TFN trash 2348423

1100 TFQ - 357896.8 DTFQ - 56.36 TFN trash o.o.m.

1200 TFQ - - DTFQ - -

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).

.

72

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 Jeode CrEme SuperWaba Ewe 20 5137,3 1650,4 416,2 1000 50 36122,8 11797,2 13771 20900 100 138166 47549,9 213377,8 218200 110 170229,8 o.o.m. 316321,5 304300 145 297889,5 o.o.m. o.o.m. 948500 150 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 Jeode CrEme SuperWaba Ewe 20 62.9 42.5 10.1 0.9 50 608.2 284.7 182.7 737.8 100 824.9 393.2 1504.4 1751.2 110 1161.6 o.o.m. 2526.2 1494.4 145 1950.4 o.o.m. o.o.m. 5642.1 150 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).

73

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.

Jeode CrEme SuperWaba Ewe A 1,40E-04 6,64E-04 1,59E-03 3,60E-03 B 1,45E-04 7,38E-04 1,75E-03 3,90E-03 C 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.


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

74

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 CrEme SuperWaba Ewe 3,11 2,64 0,43 1,31 3,14 2,60 0,46 1,28 3,10 2,61 0,45 1,33 3,12 2,66 0,45 1,28 3,30 2,60 0,43 1,27 3,18 2,71 0,47 1,32 3,14 2,66 0,45 1,33 3,00 2,64 0,44 1,29 3,19 2,70 0,46 1,28 3,17 2,63 0,43 1,34 Media 3,15 2,65 0,45 1,30 Dev.Standard 0,0766304 0,0383695 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.

75

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.

Jeode CrEme SuperWaba Ewe 1 Mb 85942,4 127163,5 68521,1 583500 2 Mb 173465,8 249476,3 150381,2 1089800 4 Mb 344502 506416,4 302278,8 2188900 8 Mb 684094,9 966851,8 539380,6 4644700

Tabella 4.9 – Tempi medi di scrittura su file (in ms).

Jeode CrEme SuperWaba Ewe 1 Mb 1234,97 3854,18 3297,23 13167,72 2 Mb 2090,61 7532,56 4962,60 6779,05 4 Mb 2477,91 12856,52 8293,50 19339,03 8 Mb 6411,57 20692,25 22403,88 53564,19

Tabella 4.10 – Deviazione standard dei tempi di scrittura su file (in ms).

76

Le tabelle 4.11 e 4.12 riportano i risultati ottenuti dalla misurazione, relativamente

all’operazione di lettura su file.

Jeode CrEme SuperWaba Ewe 1 Mb 91498,1 35272,7 68018 57600 2 Mb 201732,3 62568,8 138754,2 94900 4 Mb 397884,6 138718,9 282489,9 196500 8 Mb 769549,7 248284,7 548836,9 446900

Tabella 4.11 - Tempi medi di lettura su file (in ms).

Jeode CrEme SuperWaba Ewe 1 Mb 2898,88 4174,11 1078,11 6866,99 2 Mb 8051,88 6768,23 1496,21 2079,00 4 Mb 15342,55 11481,81 7627,87 6587,02 8 Mb 37210,72 17074,49 23308,71 18917,66

Tabella 4.12 – Deviazione standard dei tempi di lettura su file (in ms).

77

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 4,97 6,45 5,1 3,61 4,61 6,5 5,1 3,49 4,77 6,61 5,1 3,35 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).

.

78

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 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.

0500

10001500200025003000350040004500

Kb

Virtual Machine

JeodeCrEmeSuperWabaEwe

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.

79

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 400 trash 8587 500 trash 8915 1000 trash 445742 1100 trash 2348423 1200 trash o.o.m.

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.

80

• 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 Jeode CrEme 0 560.3 4177.8 5 3196,5 5640,9 10 5831,9 6624,1 20 11091,4 9177,1 50 26856,1 16879,3 100 53125,2 29799,3 200 105709,5 55522,2 300 158177,7 81151,4 400 trash 106609,7 1000 trash 324242,8 1100 trash 357896,8 1200 trash 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.

81

0

20000

40000

60000

80000

100000

120000

ms

0 5 10 20 50 100 200NThread

JeodeCrEme

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.

82

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 Jeode CrEme SuperWaba Ewe 20 5137,3 1650,4 416,2 1000 50 36122,8 11797,2 13771 20900 100 138166 47549,9 213377,8 218200 110 170229,8 o.o.m. 316321,5 304300 145 297889,5 o.o.m. o.o.m. 948500 150 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.

0100000200000300000400000500000600000700000800000900000

1000000

ms

20 50 100 110 145 150Dimensione 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.

83

0

5000

10000

15000

20000

25000

30000

35000

40000

ms

20 50Dimensione 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 Java-

compliant. 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.

84

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.


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

85

Senz

a pa

ram

etri

Un

para

met

roel

emen

tare

Un

para

met

rost

ruttu

rato

JeodeCrEme

SuperWabaEwe

0,00E+005,00E-041,00E-031,50E-032,00E-032,50E-033,00E-033,50E-034,00E-03

ms


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.

86

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.

0,00

1,00

2,00

3,00

4,00

MbJeodeCrEmeSuperWabaEwe

Jeode 3,15CrEme 2,65SuperWaba 0,45Ewe 1,30

Virtual Machine

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.

87

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.

Jeode CrEme SuperWaba Ewe 1 Mb 85942,4 127163,5 68521,1 583500 2 Mb 173465,8 249476,3 150381,2 1089800 4 Mb 344502 506416,4 302278,8 2188900 8 Mb 684094,9 966851,8 539380,6 4644700

Tabella 4.19 – Tempi medi di scrittura su file (in ms).

1 Mb 2 Mb 4 Mb 8 Mb

JeodeCrEme

SuperWabaEwe

0500000

10000001500000

2000000

2500000

3000000

3500000

4000000

4500000

5000000

ms


Figura 4.8 – Comparazione dei tempi medi di scrittura.

88

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 CrEme SuperWaba Ewe 1 Mb 91498,1 35272,7 68018 57600 2 Mb 201732,3 62568,8 138754,2 94900 4 Mb 397884,6 138718,9 282489,9 196500 8 Mb 769549,7 248284,7 548836,9 446900

Tabella 4.20 - Tempi medi di lettura su file (in msec).

0

100000

200000

300000

400000

500000

600000

700000

800000

ms

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).

89

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:

0

2

4

6

8

ms

Jeode 4,822

CrEme 6,489

SuperWaba 3,492

Ewe 5,103

Virtual Machine

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.

90

4.3 Metriche quantitative: valutazioni e confronto

In tale paragrafo è riportata una valutazione delle metriche qualitative definite, in

un’ottica comparativa.


In tabella 4.21 è riportata la disponibilità delle macchine virtuali, per i principali sistemi

operativi per dispositivi palmari.

Jeode CrEme SuperWaba Ewe WindowsCE/PocketPC a a a a PalmOS a Linux a 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.

91

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.

92

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.

Jeode CrEme SuperWaba Ewe Java.lang a a a a

Util a a a a

I/O a a a a

Net a a a a

Zip a a a a

Reflect a a a

Math a a a a

trattamento dei dati a a a a

RMI a a Security a a a a

SQL a a a a

Applet a a User Interface a a a a

Game API a a

Accesso registri di sistema a

Visualizzazione dati GPS a Protocollo Garmin GPS a Classi specifiche per PPC e PalmOS a API di comunicazione tra PC e PDA 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).

93

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 CrEme SuperWaba Ewe Truffle a

AWT a a Swing opt 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.

94

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.

95

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.

96

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

97

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.

98

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); } } } }

99

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.

100

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 .

101

• 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.

102

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.

103

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).

104

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\Ewe-Classes.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.

105

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

106

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!

107

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, McGraw-

Hill, 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

http://www.insignia.com/

http://www.nsicom.com/

http://www.superwaba.com.br/

http://www.ewesoft.com/

http://java.sun.com/j2me/

http://www.jcp.org/

http://java.sun.com/j2se/

Facoltà di Ingegneria · ANALISI E VALUTAZIONE DI MACCHINE VIRTUALI JAVA PER DISPOSITIVI MOBILI...

Documents

Transcript of Facoltà di Ingegneria · ANALISI E VALUTAZIONE DI MACCHINE VIRTUALI JAVA PER DISPOSITIVI MOBILI...