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 Ch.mo Prof. Ing. Stefano Russo CANDIDATO Francesco Esposito Matricola 41/19 CORRELATORE Ing. Domenico Cotroneo ANNO ACCADEMICO 2002-2003 i
A mio padre, che ha lasciato un vuoto incolmabile dentro di me. A mia madre. ii
Ringraziamenti Ancora non riesco a credere di essere giunto alla fine di un percorso così tortuoso e travagliato. Sono stati molti i momenti di sconforto e più di una volta ho creduto di non farcela. Presto molte delle mie ansie e angosce saranno rimosse e resterà solo la gioia di aver reso fieri di me, le persone che mi vogliono bene e hanno avuto fiducia in me. Ringrazio Dio, la cui benevolenza nei miei confronti è palese, per essere comunque presente nella mia vita e per aver detto che gli ultimi saranno i primi. Ringrazio mio padre che anche quando non stava affatto bene si preoccupava del fatto che io non studiassi per stare vicino a lui, perdonami per aver perso tanto tempo da non poterti dare la gioia che sto donando a me stesso e agli altri. Spero tu sia fiero di me, soprattutto per il modo in cui sto cercando di condurre avanti la nostra famiglia. Ringrazio mia madre per non avermi fatto mai pressioni, per aver gioito oltremodo ad ogni esame, per aver sempre lavorato e lottato per i suoi figli, per le parole di lode e ammirazione che ha proferito nei miei riguardi. Spero che la gioia di questo momento possa alleviare le tue tristezze e malinconie latenti. Ringrazio le mie sorelle: Anna, Lina e Pina per il loro amore e per le preghiere. Ringrazio i miei nipotini e i membri della famiglia tutta. Ringrazio Rossella per avermi costretto a sostenere esami che avrei altrimenti rimandato, per il suo ottimismo contagioso, per il suo affetto. Ringrazio Gaetano, amico sincero con il quale mi appresto a concludere la tormentata epopea. Grazie per aver sopportato i miei costanti ritardi e per aver ascoltato i miei guai con benevola comprensione. Grazie al prof. Stefano Russo, mio relatore, e all ing. Domenico Cotroneo, mio correlatore e amico, per la preziosa assistenza. Ringrazio: Paolo o purton; Giancarlo o prucion; Ciro o polemic; Laura anche detta Maritton, anche detta Michel Jecksòn; Marco o nano; Pepino tozzetto; Carmine o tupòn; o Macciocc; e Milòn; Riccardin; o Nunziat; i Grassi (che non sono miei parenti); o Iaccarin; o Lerro; o Rosell; o Scellòn; Michele o sapunar; Frenco; Ale detto Jesus; Barbara wanna be good; Annabella a crostatin; Tina Robert; Gianni o suggetton; Alex il cane solatore; Bruno ex playboy; Foffy o diggei; Linda; Valentina; Lell o rull; il braccio e il braccio; Laura a barist; Nicola o ginecologo; le pitone; Paolo o pucuron; Pierluigi o frevon; Pippo a pall; Rosaria donna del procione anche detto a svedes; Rosario o cloaca; Austin Funèl; Tore Marino, per il soprannome parola senza di voi non ce l avrei mai fatta a invecchiare sui libri! Grazie a tutte le donne che ho avuto, finalmente avrò i soldi per pagare ancora; grazie a telecapri, per i cattivi pensieri; grazie ai miei pochi capelli rimasti. Grazie ai cari ingegneri del laboratorio: Carletto, chi s assumigl s pigl ; Vincenzo forza Barra, Cristiano; Generoso, Armando, Carmine e Marcello. Un grazie agli amici: Carmine; Imma, anche detta Concetta; Paolo, better known as Muppet; Stanislao e Gianluca SuperWaba. Grazie a tutti Addà venì baffon! iii
Introduzione 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.1 Disponibilità 34 2.2.2 Caratteristiche 35 2.2.3 Ciclo di Sviluppo 37 2.2.4 Le API di CreMe 38 2.3 SuperWaba 39 2.3.1 Disponibilità 40 2.3.2 Caratteristiche 42 2.3.3 Ciclo di Sviluppo 44 iv
2.3.4 Le API di SuperWaba 46 2.4 Ewe 48 2.4.1 Disponibilità. 49 2.4.2 Caratteristiche 50 2.4.3 Ciclo di Sviluppo 51 2.4.4 Le API di Ewe 53 2.5 Considerazioni comparative 54 Capitolo 3 Definizione ed implementazione dei test sperimentali 55 3.1 Il modello di qualità 55 3.1.1 Gli attributi e le entità 56 3.2 Le metriche 57 3.3 I test sperimentali: definizione e implementazione 59 3.3.1 Il multithreading 59 3.3.1.1 Considerazioni preliminari 59 3.3.1.2 Livello di multithreading 62 3.3.1.3 Prestazioni di uno stesso algoritmo multithread 63 3.3.2 Il tempo di chiamata ai metodi 64 3.3.3 Operazioni di Input/Output su file 65 3.3.4 Operazioni di Input/Output su rete 66 Capitolo 4 Analisi e valutazione dei risultati sperimentali 68 4.1 Metriche quantitative: risultati 69 4.1.1 Impronta di memoria 69 4.1.2 Multithreading 69 4.1.2.1 Livello di Multithreading 70 4.1.2.2 Prestazioni di un algoritmo multithread 72 4.1.3 Tempo di chiamata a metodi 73 4.1.4 Overhead delle macchine virtuali 74 4.1.5 Operazioni di I/O su file 75 4.1.6 Operazioni di I/O su rete 77 4.2 Metriche quantitative: confronto 78 4.2.1 Impronta di memoria. 78 4.2.2 Multithreading 79 4.2.2.1 Livello di multithread 79 v
4.2.2.2 Prestazioni di un algoritmo multithread 82 4.2.3 Tempo di chiamata a metodi 84 4.2.4 Overhead delle macchine virtuali 86 4.2.5 Operazioni di I/O su file 87 4.2.5.1 Scrittura 87 4.2.5.2 Lettura 88 4.2.6 Operazioni I/O su rete 89 4.3 Metriche quantitative: valutazioni e confronto 90 4.3.1 Disponibilità 90 4.3.2 Ciclo di sviluppo 91 4.2.3 Classi supportate 92 4.2.4 Interfaccia utente 93 4.2.5 Compatibilità con Java 94 Conclusioni 95 Appendice A 96 A.1 Istallazione di SuperWaba su PC Desktop (Windows 98 e superiori) 96 A.2 Installazione di SuperWaba sul palmare (Compaq ipaq 3970) 97 A.3 L applicazione 98 A.4 Compilazione e generazione degli eseguibili 99 A.5 Esecuzione 100 Appendice B 102 B.1 Istallazione di Ewe su PC Desktop (Windows version) 102 B.2 Installazione di Ewe sul palmare (Compaq ipaq 3970) 103 B.3 L applicazione 103 B.4 Compilazione e generazione degli eseguibili 104 B.5 Esecuzione 106 Bibliografia 107 vi
Introduzione Scopo del seguente lavoro di tesi è il confronto tra differenti macchine virtuali, destinate ai cosiddetti small connected devices, cioè ai piccoli dispositivi dotati di proprietà di connettività. L attenzione è focalizzata in particolare sui palmari con sistema operativo basato su WindowsCE. Al fine di conseguire l obiettivo si valuteranno le diverse macchine virtuali mediante la definizione di un modello di qualità [Pressman]. La qualità si caratterizza attraverso un insieme finito e definito di attributi, quindi un modello di qualità è composto da attributi, ciascuno considerato con un suo peso, aventi la finalità di rappresentare la qualità posseduta dal prodotto software considerato. Nel definire il modello consideriamo il fatto che i palmari attuali hanno raggiunto un evoluzione tale, da avvalersi dell appellativo di piccoli dispositivi principalmente in termini relativi, cioè se rapportati agli odierni computer desktop. Per cui il numero di applicazioni client-based realizzate per tali dispositivi è cresciuto enormemente. In tabella 1 è mostrato l insieme di attributi scelto per la caratterizzazione del modello proposto e, per ciascun attributo, l insieme delle entità che, a loro volta, caratterizzano gli attributi. Attributo Efficienza Interoperabiltà Usabilità Portabilità Entità Multithreading; Chiamate a metodi; Overhead; Operazioni di Input-Output su file e su rete; Compatibilità con Java Ciclo di sviluppo, Interfaccia grafica, Classi supportate Disponibilità su differenti piattaforme hardware-software. Tabella 1 Modello di qualità per la valutazione delle macchine virtuali. Definito il modello, è possibile introdurre le metriche software. Esse rappresentano lo strumento attraverso il quale è possibile misurare le entità che caratterizzano gli attributi del modello considerato. Le metriche definite, sono sia qualitative sia quantitative. Esse sono descritte nella tabella 2. 1
Metrica qualitativa 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]. 2
Cenni preliminari Considerato il recente e quanto mai crescente interesse riguardo l uso di Java su piccoli connected devices può sorprendere pensare che le origini di Java derivino dal progetto e lo sviluppo di un limitato dispositivo wireless di nome *7 [HaOCon]. Quest ultimo è stato realizzato dalla Sun alle metà degli anni 90. Il sistema operativo di tale macchina, denominato Dubbed, ha contribuito alla formalizzazione di base del linguaggio Java. Quindi impiantare Java sui piccoli device può considerarsi, seppur modestamente, una sorta d onorificenza nei riguardi delle origini di Java. Cominciamo ad esaminare le limitazioni che caratterizzano i piccoli dispositivi poiché tali si traducono in altrettante sfide per l utilizzo di Java in tale ambito. L attenzione è rivolta a quei dispositivi mobili, quali telefoni cellulari e PDA ( Personal Digital Assistent ), caratterizzati da consistenti limitazioni in termini di funzionalità e risorse se confrontati ai desktop computer. Come accennato il linguaggio Java era stato inizialmente concepito come tecnologia di interconnessione per piccoli dispositivi, ma col tempo si è sviluppato fino a supportare programmi per computer desktop e applicazioni mission critical server based. Di conseguenza, al progetto iniziale, sono state aggiunte un numero considerevole di API (Application Program Interface), incrementando significativamente le funzionalità offerte da Java. E facile intuire che le numerose API messe a disposizione da Java non possono essere integrate in quei dispositivi caratterizzati dai vincoli di cui sopra. Nel 1999 alla JavaOne Conference fu presentata KVM (Kilobyte Virtual Machine) per il Palm OS, successivamente con l arrivo di J2ME, Java è ritornato ad essere destinato ai piccoli dispositivi. Ci si può porre la questione se Java abbia la caratteristica di essere suitable per i piccoli dispositivi. Ebbene il recente sviluppo di Java come vero e proprio linguaggio di programmazione accompagnato dallo sviluppo del mercato dei piccoli device risponde a tale interrogativo in maniera inequivocabilmente affermativa, ma molte caratteristiche del linguaggio e le API devono essere adattate per rispondere ai requisiti di tali piccoli dispositivi. 3
Gli aspetti che maggiormente sono da tenersi in considerazione riguardano le seguenti aree chiave: capacità di elaborazione in termini di CPU e memoria; alimentazione; connettività; interfaccia utente. Analizziamo con ordine ciascuna delle aree summenzionate. Capacità di elaborazione La computing capability è in diretta correlazione con il modo in cui un dispositivo elabora le informazioni per l utilizzatore finale. Essa è da ritenersi un attributo composto le cui parti fondamentali sono: la velocità della CPU, la memoria totale, la capacità delle unità di memorizzazione di massa e gli altri fattori concernenti l hardware. Purtroppo la capacità di elaborazione varia notevolmente nell ambito dei piccoli dispositivi e l unico denominatore comune è il fatto di essere molto limitati se confrontati con i desktop computer. La limitata natura dei piccoli dispositivi vincola pesantemente il Java Environment, data la vastità delle librerie standard di Java è impossibile infatti pensare di portare interamente le API standard su di un piccolo dispositivo. Pertanto impiantare API che abbiano la caratteristica di essere usabili, in un piccolo dispositivo, necessita di un oculato adattamento, d altra parte la limitazione nelle API porta ad una limitazione nella portabilità dei relativi programmi. Gli sviluppatori Java hanno infatti imparato a produrre codice indipendentemente dalla specifica piattaforma a cui una applicazione può essere destinata e questo ha incrementato, dal punto di vista dello programmatore, la gradevolezza (appeal) nei confronti dell ambiente Java. L approccio di ridimensionamento del Java Environment è tuttavia inevitabile ed influisce sull appeal dell intero ambiente poiché costringe gli sviluppatori a conoscere le nuove API, ma risulta essere l unico approccio possibile al fine di conciliare le esigenze di tutte le parti in causa. 4
Fortunatamente, come in ogni altro campo dell industria dei computer, anche per i piccoli dispositivi c è una rapida crescita della capacità di elaborazione, basti pensare che il Palm1000 presentato nel 1996 era equipaggiato con una memoria RAM di appena 128kb e che dopo circa quattro anni le versioni del PalmOS includevano una memoria RAM di 8Mb. Oggigiorno siamo ad una dimensione della memoria di 64Mb. Anche la velocità della CPU aumenta vertiginosamente con gli anni: i PalmOS del 2000 avevano un clock intorno ai 25MHz mentre attualmente si hanno handheld che lavorano anche a frequenze di 400MHz. Al miglioramento della capacità di elaborazione concorrono diversi fattori, tra i quali l integrazione dei componenti elettronici e il miglioramento delle architetture dovuto alla crescita del mercato dei piccoli dispositivi, tale crescita è stata favorita anche dal diffondersi delle tecnologie wireless network tra cui è in forte ascesa Bluetooth. Alimentazione Diversamente dai computer desktop i piccoli dispositivi hanno, per loro natura, la caratteristica di dover essere self-sufficient dal punto di vista dell alimentazione. Cioè si assume che essi possano operare senza l ausilio diretto di una fornitura di energia elettrica e sono dotati di una batteria ricaricabile che ha una limitata autonomia e che rappresenta una risorsa da ottimizzare con cura, dato che la natura mobile dei device conduce all assunzione che essi operino lungo tempo senza poter essere ricaricati. La necessità di conservazione della batteria influenza in maniera indiretta il processo di acquisizione di Java sui piccoli dispositivi: chip che lavorano a frequenza più basse richiedono meno potenza e quindi prolungano la vita della batteria e il loro uso, ciò si riflette nella necessità di avere API ottimizzate per avere tempi di risposta accettabili dal punto di vista dell utilizzatore. 5
Connettività Dato il crescente espandersi dei piccoli dispositivi, la banda delle reti wireless non è più da considerarsi limitata. Nel 2000 la maggior parte delle applicazioni wireless based potevano contare su di una banda di 9600 Kbps o anche meno, questo perché l impiego di Java era maggiormente rivolto ai telefoni cellulari, oggi siamo intorno a 10 54 Mbps. Comunque per i piccoli dispositivi che supportano Java, reti lente e inconsistenti, in termini di disponibilità, possono ostacolare funzionalità che si affidano ad un connessione a larga banda. Le applicazioni sui piccoli dispositivi wireless devono quindi portare in conto le diverse reti e le difficoltà di comunicazione che si incontrano su di una rete lenta e limitatamente affidabile. Interfaccia utente Una delle aree in cui è più difficile standardizzare, passando attraverso varie piattaforme, è l interfaccia utente. La storia di Java, del resto, ci illustra quale lento processo abbia alla fine portato ad una matura GUI ( Graphical User Interface ). I piccoli dispositivi presentano altrettante difficoltà in questa area chiave, data la molteplicità e la diversità dei metodi di input output. Si pensi ad esempio alle differenti dimensioni degli schermi di un telefonino cellulare e di un palmare o alle diverse modalità di immissione dati di questi ultimi. Per tale motivo non è consigliabile portare su di un piccolo dispositivo le API Swing o AWT integralmente, anche perché queste sono state pensate per computer aventi dimensioni degli schermi ben delineate. Sarebbe preferibile quindi pensare ad una GUI che fosse in grado di aderire alle caratteristiche look and feel dei singoli dispositivi in questione. D altra parte, in particolar modo per gli handheld, è possibile alleggerire le API del Java Environment, per esempio le API AWT, lasciando al programmatore il compito di adattare la propria applicazione alle dimensioni del device cui è destinata l applicazione stessa. 6
Capitolo 1 Le piattaforme Java per dispositivi mobili Il primo sforzo concreto, finalizzato alla realizzazione di piattaforme Java per i piccoli dispositivi, è stato compiuto dalla Sun attraverso il progetto della tecnologia J2ME (Java 2 Micro Edition) [J2ME], [HaOCon]. J2ME nasce come strumento in grado di fornire funzionalità multi-piattaforma su piccoli dispositivi orientati alla connessione. Le stesse che hanno caratterizzato l infrastruttura Java standard e che ne hanno decretato il successo. In poche parole la mission era portare Java su tali device, per cui l obiettivo principe si può identificare nella portabilità delle applicazioni. Abbiamo già discusso dell impossibilità di portare integralmente le API standard sulle svariate tipologie di dispositivi, per cui si è dovuto affrontare un attento processo di riduzione delle core API attraverso semplice soppressione e ottimizzazione. Quest ultima realizzata, però, lasciando inalterate le specifiche dei metodi (bisognava cambiare il come, non il cosa ). I dispositivi in questione non hanno tutti le stesse caratteristiche, per cui, al fine di fornire compatibilità con una platea tanto eterogenea, si è deciso di progettare l infrastruttura J2ME in maniera modulare. Ciascun modulo fornisce una serie si servizi (attraverso le API), cosicché una applicazione è in grado di essere eseguita su diverse piattaforme a patto che esse supportino gli stessi moduli dell infrastruttura. 1.1 Cenni storici J2ME fu presentata al mondo per la prima volta nel 1999 durante i lavori della JavaOne conference. Era l epoca in cui la Sun annunciò la realizzazione della prima Virtual Machine per il PalmOS: si trattava di Kilobyte Virtual Machine (KVM). Nel corso del 2000 prese corpo l intento di modularizzare l infrastruttura J2ME con l introduzione, per la prima volta, di un architettura basta su configurazioni e profili. In tal modo, partendo da una realizzazione basata su KVM, il J2ME environment è stato 7
esteso fino ad includere numerose famiglie di dispositivi. La cosa che rende profondamente diverso J2ME dai suoi predecessori, tra cui Personal Java e Embedded Java, è proprio il fatto di rendere possibile la personalizzazione di J2ME per specifici dispositivi in un modo rigorosamente standardizzato, prevenendo così il proliferare di differenti e ridondanti versioni e garantendo un elevata flessibilità. 1.2 Architettura Le specifiche di J2ME hanno imposto, fin dal concepimento, la strutturazione delle API in due livelli, in grado di fornire comunione e flessibilità. Essi sono definiti, rispettivamente, configurazioni e profili e formano, unitamente ad una Java Virtual Machine (JVM) un completo Java Runtime Environment per una determinata tipologia di dispositivi. Applicazione J2ME Applicazione J2ME Profilo Configurazione Profilo opzionale Java API specifiche Applicazione Nativa Java Virtual Machine Sistema Operativo Nativo Figura 1.1 - Architettura J2ME In figura 1.1 è mostrata la stratificazione dei livelli software di un dispositivo che supporta l ambiente J2ME: Il sistema operativo fornisce i servizi di base per accedere all hardware del dispositivo, consente l accesso alla memoria e gestisce l archiviazione delle 8
informazioni sulla memoria di massa. Inoltre esso supporta le applicazioni native; La Java virtual machine fornisce l ambiente di esecuzione necessario ad interpretare il bytecode Java e può eventualmente supportare le Java API specifiche del costruttore; Al di sopra della macchina virtuale si trovano le API appartenenti alla particolare famiglia di dispositivi e le API specifiche del singolo dispositivo, realizzate dal costruttore. Le prime sono contenute nella configurazione e nel profilo, mentre le seconde consentono di accedere alle funzionalità proprie di quel dispositivo e non della famiglia; infine troviamo l applicazione J2ME realizzata mediante l utilizzo delle API fornite ai livelli sottostanti. 1.2.1 Java Virtual Machine Come già accennato la macchina virtuale Java fornisce un ambiente di esecuzione per l esecuzione dei programmi Java. Essa si pone al disopra del sistema operativo fornendo un interprete nativo per il bytecode. Le JVM per i piccoli dispositivi hanno a disposizione solo una quantità molto limitata di memoria per svolgere il loro compito, inoltre necessitano di essere ottimizzate per fornire un accettabile livello di prestazioni, in quanto la velocità di elaborazione dei piccoli dispositivi è altrettanto ridotta quanto la memoria. I requisiti di una siffatta macchina virtuale sono definiti da un lato dalla limitata natura del dispositivo in questione e dall altro dalla definizione della particolare configurazione, la quale definisce una serie di funzionalità che la JVM deve implementare. La Kilobyte Virtual Machine, progettata per lavorare sui PalmOS, deve il suo nome alla ridotta quantità di memoria di cui necessita per essere installata su di un piccolo dispositivo. E sufficiente una quantità di memoria di 160kb e lavora su processori CISC o RISC a 16 e 32 bit. Simile alla precedente è la HVM, Hotspot Virtual Machine, la quale rappresenta una specializzazione della KVM per i processori ARM. Essa consente un cospicuo aumento di prestazioni dovuto all adattabilità della compilazione a scapito di un ridotto aumento del fabbisogno di memoria. Infine possiamo citare la CVM, C Virtual Machine, 9
progettata per supportare tutte le caratteristiche di J2SE e destinata, per tale ragione, ai dispositivi con consistenti risorse hardware. 1.2.2 Configurazioni Le configurazioni definiscono un insieme di API base che accomunano una serie di dispositivi simili dal punto di vista hardware. Tali dispositivi possono essere, in realtà, abbastanza differenti tra loro, ma sono tutti caratterizzati dall avere alcune peculiarità molto simili. Ad esempio la memoria disponibile, il tipo di processore e le network capability, possono essere le stesse malgrado i differenti fattori di forma o gli ambiti applicativi più disparati. Quindi le configurazioni hanno ragion d essere nell intento di stabilire comunione tra diverse famiglie di dispositivi equipollenti, mediante la realizzazione di un core API invariante da dispositivo a dispositivo. Poiché il livello di configurazione poggia direttamente sulla JVM, può essere necessario contemplare alcune dipendenze di basso livello, ad esempio una configurazione potrebbe richiedere operazioni floating-point che alcune JVM, tra cui KVM, non supportano. Ogni macchina virtuale coerente con una siffatta configurazione deve quindi supportare gli oggetti float e double. Quindi la configurazione oltre ad escludere API fortemente dipendenti dalla specifica piattaforma, definisce i requisiti della macchina virtuale su cui poggia. Il concetto non deve destare ambiguità: anche se configurazione e macchina virtuale sono strettamente accoppiate, esse restano ben distinte. Nonostante una configurazione sia generalmente distribuita assieme ad una macchina virtuale, la prima non è necessariamente legata alla seconda e può funzionare con qualsiasi JVM che sposa i suoi bisogni. La tabella 1.1 mostra le configurazioni correnti di J2ME. In essa è indicata la versione e il numero della Java Specification Request (JSR) definito dalla Java Community Process (JCP) [JCP]. Tecnologia Descrizione Release CLDC v. 1.1 JSR-139 Connected Limited Device Configuration, Marzo 2003 per dispositivi quali telefoni cellulari. CDC v. 1.0a JSR-36 Connected Device Configuration, fornisce un Agosto 2002 ambiente più esteso per dispositivi più complessi. Tabella 1.1 - Le principali configurazioni J2ME attualmente disponibili 10
1.2.3 Profili I profili differiscono dalle configurazioni poiché focalizzano l attenzione su specifici gruppi di dispositivi il cui denominatore comune è l adesione completa ad una data configurazione. Ad esempio il profilo MIDP (Mobile Information Device Profile), specifico per i telefoni cellulari, differisce dal profilo PDA dedicato ai primi palmari, ma entrambi poggiano sulla stessa configurazione (CLDC). Le configurazioni, quindi, forniscono le funzionalità di base, mentre i profili supportano funzionalità molto specifiche della particolare famiglia di dispositivi per cui sono stati concepiti. Con tale approccio modulare è possibile includere specificità in un programma preservando la genericità delle funzionalità di base. Ciò favorisce un processo di portabilità che, anche se non è immediato, è altamente flessibile: la migrazione di un programma da una famiglia di dispositivi ad un'altra, consente il riuso del codice prodotto usando una configurazione comune e impone la riscrittura del solo codice specifico per il dispositivo, mediante l utilizzo di un opportuno profilo. Inoltre è possibile utilizzare profili opzionali per aggiungere funzionalità non disponibili in quello standard. Ad esempio il profilo RMI aggiunge la funzionalità di Remote Method Invocation alle funzionalità di base del profilo a cui si affianca. La tabella 1.2 mostra alcuni profili correnti e quelli futuri. Tecnologia Descrizione Release MIDP v. 2.0 JSR-118 Estende la configurazione CLDC con classi Novembre abstract per le UI e per il Networking. 2002 Foundation Profile v. 1.0JSR-46 Personal Profile v. 1.0 JSR-62 RMI Profile v.1.0 JSR- 66 PDA Profile JSR-75 Game Profile JSR-134 Estende CDC, richiede almeno un profile Marzo 2001 addizionale per essere completo. Profilo per piccoli devices che sostiuisce Settembre 2002 Personal Java 1.1.x e 1.2.x. Fornisce il supporto opzionale RMI. Giugno 2002 Profilo più completo rispetto a MIPD, si poggia su CLDC ed è destinato ai PDA. Pensato per lo sviluppo di giochi sul J2ME environment Tabella 1.2 Alcuni profili disponibili e altri in corso d opera (ICDO). ICDO ICDO 11
Le informazioni presenti nelle tabelle 1.1 e 1.2, sono aggiornate al marzo 2004. Ulteriori informazioni sullo stato dei lavori e la descrizione delle specifiche, sono reperibili al sito http://www.jcp.org/. 1.3 CLDC e CDC Ci sono soltanto due configurazioni che coprono un largo range di famiglie di dispositivi. Un numero così esiguo evita confusione, ma soprattutto limita fortemente la ridondanza. La prima è la Connected Limited Device Configuration (CLDC), essa è rivolta a dispositivi piuttosto limitati, piccoli e di solito wireless, quali, ad esempio, telefoni cellulari e PDA con limitate caratteristiche hardware. La seconda configurazione è la Connected Device Configuration (CDC), che si rivolge ai dispositivi aventi risorse tali da poter essere in grado di supportare un ambiente Java quasi completo. La CDC rappresenta, quindi, una alternativa per quei dispositivi, come navigatori satellitari o PDA di ultima generazione, che hanno maggiore capacità in termini di memoria e velocità di elaborazione. I dispositivi che utilizzano la CDC hanno inoltre la caratteristica di non dover essere necessariamente limitati dal punto di vista dell alimentazione ed hanno, in genere, una larghezza di banda consistente. 1.3.1 Confronto tra le configurazioni La CDC è stata implementata mediante la realizzazione di API che formassero un insieme più ampio che include l insieme delle API della configurazione CLDC. Tale scelta favorisce la portabilità delle applicazioni CLDC-based, infatti se si intende portare un programma da CLDC a CDC, non è necessario modificare il codice dipendente dalla configurazione. CDC nasce, a sua volta, come un sottoinsieme dell intero J2SE environment, differendo da esso principalmente per l assenza di vere e proprie API client-specific (AWT). In aggiunta vi sono però classi addizionali, nel package javax.microedition, allo scopo di fornire codice specifico per i client mobili. La figura 1.2 mostra le relazioni di inclusione e di non appartenenza discusse, mediante approccio insiemistico. 12
J2SE CDC CLDC Figura 1.2 Relazione tra gli environment CLDC, CDC, J2SE: da intendersi in senso lato. CDC offre, come già detto, un ambiente Java quasi completo. Di seguito sono riportati alcuni package di J2SE 1.3 non presenti nella configurazione CDC: java.applet java.awt.* java.rmi.* java.sql javax.sound.* javax.swing.* Alcuni package non presenti nelle configurazioni sono forniti con i profili, mentre le funzionalità tipo AWT sono incapsulate in profili specifici di interfaccia. Uno degli equivoci più comuni è affermare che nella configurazione CDC sono presenti tutte e sole le funzionalità di base che si trovano in J2SE. Niente di più falso: molti package della configurazione CDC sono stati ridotti in numero di classi e in complessità di queste ultime, l environment CDC è più completo rispetto a quello offerto da CLDC, ma resta sempre ottimizzato per poter afferire ad un ambito limitato. 1.3.2 Dettagli di CLDC Le API appartenenti alla configurazione CLDC, sono state prodotte, come già accennato, mediante un processo di riduzione delle API standard di J2SE, basato sull eliminazione e sulla ottimizzazione in termini di complessità. Nessuna classe e nessun metodo sono stati aggiunti alle API base che la configurazione condivide con 13
J2SE, mentre il codice specifico, per CLDC, è stato inserito nel package javax.microedition, proprio di J2ME. CLDC ha due obiettivi supplementari, specifici per le famiglie di dispositivi cui è destinata. Infatti molti di questi dispositivi, tra cui i telefoni cellulari, sono stati a lungo limitati dalle funzionalità iniziali fornite con il device al momento della vendita, stiamo parlando dell OEM (Original Equipment Manufacturer). Un primo obiettivo è, quindi, aggiungere flessibilità ad un dispositivo, in modo da adattarlo ai nuovi bisogni dei suoi utilizzatori. Ciò rimuove i confini concernenti la staticità delle funzionalità del dispositivo ed offre un concreto sbocco al concetto di updating. Il secondo obiettivo è una diretta conseguenza del primo ed è il nascere di terze parti in grado di sviluppare applicazioni per i dispositivi che supportino la configurazione CLDC, creando di fatto un modo per accedere ad un mercato precedentemente irraggiungibile. A guidare la selezione di una configurazione, per una famiglia di dispositivi, sono le capability della stessa che prescindono da fattori, quali ad esempio, l interfaccia utente. I requisiti di base, che un dispositivo deve possedere per supportare la CLDC, sono davvero esigui se confrontati con quelli posseduti da un desktop computer, tra i principali possiamo elencare i seguenti: da un minimo di 160kb fino a giungere a 512kb di memoria totale; processori a 16 o 32 bit con un clock di almeno 16MHz; 128kb di memoria non volatile destinata a contenere la JVM e le librerie CLDC; 32kb di memoria volatile per il Java Runtime, questo include lo stack e ogni applicazione caricata a tempo di esecuzione; bassi consumi e alimentazione a batterie; connessione di rete, di solito wireless, che può essere intermittente e con vincoli di banda stringenti (anche meno di 9600bps). Il fattore chiave è la memoria: essa definisce i confini tra le famiglie di dispositivi che usano la configurazione CLDC e quelle che usano la CDC. La natura limitata della configurazione CLDC impone alcuni vincoli sia sul linguaggio Java, sia sulla macchina virtuale, su cui poggia la configurazione stessa. Esploriamo, di seguito, tali limitazioni nel dettaglio. 14
1.3.2.1 Differenze di linguaggio La sintassi del linguaggio Java è rimasta invariata, le differenze nel linguaggio riguardano principalmente la riduzione e l eliminazione delle API. Riportiamo di seguito queste ultime: o Gruppi di thread: il supporto ai thread continua ed essere fornito e anzi, risulta essere particolarmente utilizzato sui piccoli dispositivi. Ciò che è stato sottoposto ad eliminazione è il supporto ai gruppi di thread, anche perché la limitata natura del device consente di supportare generalmente solo pochi thread. o Oggetto finalization: in ogni classe in ambiente Java standard, è possibile definire un metodo finalize, il quale, un istante prima che l'oggetto venga eliminato dal garbage collector, è richiamato dalla JVM per rilasciare ogni altra risorsa allocata all oggetto oltre alla memoria (ad esempio file aperti o connessioni socket). Tale funzionalità è stata rimossa poiché complica notevolmente il processo di garbage collection. o Weak references: tali funzionalità consentono al programmatore di segnalare alla JVM che un dato oggetto può essere sottoposto a garbage collection. Anch esse sono state eliminate poiché complicano la garbage collection. o Numeri floating-point: gli oggetti floating-point, double e float, sono stati rimossi nella configurazione CLDC. Questo può sembrare strano, ma c è da osservare che, il supporto ai numeri floating-point è assente nella maggior parte dei piccoli device e che, una emulazione software, sarebbe troppo costosa. o Serialization: essa consente la conversione di un oggetto Java residente in memoria, in una successione di byte. Tale tecnica è molto utilizzata quando occorre trasferire oggetti attraverso la rete. Gli oggetti che possono essere serializzati implementano l interfaccia serializable ed includono solo oggetti che sono dichiarati come serializzabili. Nella configurazione CLDC la serializzazione non è possibile poiché necessita di API a loro volta eliminate. Conseguentemente funzionalità dipendenti dalla serializzazione, quali ad esempio la RMI, sono assenti nella CLDC. o Java Native Interface: la JNI fornisce un approccio standardizzato per accedere a librerie e applicazioni native. La richiesta di memoria, necessaria per tale funzionalità, preclude la sua implementazione nei dispositivi CLCD-based. 15
o Reflection: Le reflection API forniscono un modo molto flessibile per esaminare oggetti e interagire con essi a runtime. Esse generano meta-informazioni e consentono ad un programma di interagire dinamicamente con oggetti atempo di esecuzione. La reflection è particolarmente utile per quei programmi, tipo debugger, che hanno bisogno di esaminare a tempo di esecuzione lo stato degli oggetti in memoria. E immediato osservare che la reflection aggiunge un overhead consistente e per questo è stato sottoposta ad eliminazione. o Eccezioni ed errori: il supporto alle eccezioni e agli errori è presente nella CDLC, ma il loro numero è stato ridotto come conseguenza dell eliminazione di parte delle API. Le classi rimaste continuano a lanciare le stesse eccezioni e sotto le stesse condizioni, questo per favorire la compatibilità tra J2SE e J2ME. o AWT e Swing: tutte le API di interfaccia utente sono state rimosse nella configurazione CLDC: Graphical User Interface API, sono state progettate per specifiche famiglie di device, nei vari profili. o Collections: pur implementando le classi Hashtable, Vector, Stack ed Enumeration, la CLDC non fornisce le API per tutte le collezioni di oggetti, data la loro vastità. o Networking e I/O: la configurazione CLDC non fa nessuna assunzione riguardo la natura delle connessioni di rete, per cui molte networking API non sono incluse in tale configurazione. Al loro posto è stato introdotto un framework di connessione generica. o Sicurezza: il modello di security della J2SE è molto complesso, richiede molto spazio fisico e consistente tempo di CPU, per tale motivo le security API hanno subito una drastica riduzione. Quest ultima ha portato all impiego di un modello di sicurezza in J2ME semplificato che prende il nome di sandbox model. 1.3.2.2 Differenze nelle Virtual Machine Molti dei cambiamenti della configurazione CLDC, sono il risultato delle limitazioni imposte dal tipo di dispositivo e dalle capability dei livelli sottostanti. La macchina virtuale, di conseguenza, è stata modificata per aderire al modello semplificato. Analizziamo i cambiamenti: o Nessun class loader definito dall utente: le classi Java sono caricate a runtime mediante class-loader. La VM possiede un class-loader di default ma, in J2SE, 16
è possibile creare un loader costruito interamente in Java. Quest ultimo può essere caricato dal loader di default ed essere utilizzato per caricare le classi in modo ottimizzato. Nell environment J2ME ciò non è consentito, inoltre il classloader di default non consente il caricamento di quegli oggetti che tentano di fare l override delle API base. o Assenza di verifica dei classfile: ogni classfile Java, caricato dalla macchina virtuale, è sottoposto a verifica prima di essere utilizzato. Tale azione assicura la correttezza del bytecode e previene tentativi di caricare codice malizioso. Per diminuire l overhead conseguente, il processo di verifica è stato ottimizzato grazie all utilizzo di un preverificatore. o Nessun supporto diretto per il Java environment/application setup: la CLDC non fornisce supporto alcuno per il controllo dell installazione di nuove applicazione e per la loro esecuzione. Tale supporto è invece realizzato in un modo devicespecific dipendente, quindi, dall implementazione J2ME per il dato device. L Application Management Software (AMS) abilita l utente finale a caricare, eseguire e rimuovere applicazioni J2ME sul dispositivo su cui è installato o Preloading e prelinking: le classi possono essere prelinkate e immagazzinate su memoria non volatile per un caricamento più veloce. 17
In tabella 1.3 sono illustrati i packages facenti parte della configurazione CLDC, accompagnati da una breve descrizione. Package Funzione java.io Consente la lettura e la scrittura dei flussi di di classi: 11 I/O. Non supporta le classi BufferedStream ma interfacce: 5 eccezioni: 5 fornisce 5 implementazioni delle classi astratte InputStream e OutputStream. java.lang Fornisce classi che sono il cuore del linguaggio classi: 15 Java. Nel package sono inclusi gli oggetti interfacce: 1 eccezioni: 19 System, Thread e Runtime e la classe Math. java.util Contiene utility per la manipolazione delle classi: 7 informazioni di data e ora e supporta le Java interfacce: 1 eccezioni: 2 Collection di base. javax.microedition.io E l unico package specifico: implementa classi: 1 classi supplementari di I/O e fornisce le interfacce: 8 eccezioni: 1 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. 18
I requisiti di base, che un dispositivo deve possedere per supportare la CDC si possono riassumere, nei seguenti: Più di 2Mb di memoria totale disponibile per il Java environment; Processori a 32 bit Connessione di rete, spesso wireless, che può essere intermittente e con vincoli di banda non molto stringenti. Una Java Virtual Machine completa, che supporti tutte le funzionalità standard. Così come la CLDC è generalmente accoppiata al profilo MIDP, di cui parleremo tra breve, la CDC si accompagna ad un profilo che complementa la sua configurazione base. Tale profilo, il foundation profile, non include le GUI API che sono viceversa fornite a mezzo di profili opzionali. La configurazione CDC è distribuita assieme alla CVM (C Virtual Machine). Essa è una JVM completa, supporta tutte le funzionalità tipiche di ogni JVM standard ed è perciò profondamente diversa dalla KVM. Conseguenza dell impiego della CVM è il fatto che i vincoli sulla CDC riguardano solo il linguaggio e non la virtual machine. 1.3.3.1 Differenze di linguaggio Anche nella configurazione CDC la sintassi del linguaggio Java è rimasta invariata, le differenze di linguaggio, dovute al processo di riduzione delle API, sono, in tale configurazione, più esigue che nella CLDC. Di seguito sono riportate le principali differenze tra le due configurazioni in merito al linguaggio. Anticipiamo il fatto che molte delle limitazioni presenti in CDLC non hanno ragione di esistere in tale ambito: o Gruppi di thread: poiché i requisiti minimi dei dispositivi che supportano la configurazione CDC, sono considerevolmente più robusti, rispetto al caso dei dispositivi CLDC-based, i gruppi di thread prendono posto in tale configurazione. o Oggetto finalization: la finalization era stata rimossa dalla CLDC per via dell overhead insostenibile per i dispositivi cui la configurazione era destinata e perché complicava la garbage collection da parte della sottostante JVM. Visto che la CDC è rivolta a dispositivi più performanti e che la macchina virtuale su 19
cui poggia è conforme allo standard Java per le JVM, la configurazione CDC supporta l oggetto finalization. o Weak references: la CDC rimuove tale limitazione e anzi, supporta l intero package java.lang.ref che contiene, tra l altro, la weak reference. o Numeri floating-point: diversamente da quanto accade per la CLDC, il supporto ai numeri floating-point è fornito nella CDC. Questo grazie alle maggiori potenzialità disponibili nei dispositivi a cui è rivolta la configurazione e all impiego della CVM, la quale supporta i tipi double e float. o Serialization: la serializzazione non è stata sacrificata all interno della configurazione CDC. Tale funzionalità è, anzi, necessaria in una architettura più flessibile rispetto alla CLDC e la sua implementazione è resa possibile grazie alle caratteristiche fisiche dei dispositivi cui la configurazione CDC stessa è rivolta. o Java Native Interface: la configurazione CDC implementa la JNI, ma non solo. Essa supporta anche altre interfacce quali l interfaccia di debug (JVMDI) e la profiling interface (JVMPI). Queste tre interfacce, si basano su interfacce C e poiché la CVM del livello sottostante è scritta in C, il loro mantenimento nella configurazione è stato possibile. o Reflection: la configurazione CDC supporta le reflection API, diversamente da quanto accade nella CLDC. Tali API sono contenute nel package java.lang.reflect. o Eccezioni ed errori: in CDC sono contenuti errori ed eccezioni in numero minore rispetto al J2SE environment. Tale numero è, d altra parte, maggiore rispetto al caso CLDC, ciò è una conseguenza del maggior numero di API che trovano posto in tale configurazione. o AWT e Swing: così come accade per la CLDC, le API di interfaccia utente sono state rimosse nella configurazione CDC: il compito è delegato ai profili. Come vedremo tra breve, il Personal Profile prevede le stesse funzionalità presenti in Personal Java, tra cui l implementazione di API AWT-based. o Collections: nella configurazione CDC è presente un supporto completo alle collezioni di oggetti. o Networking e I/O: la CDC contiene un insieme di I/O API molto più espanso rispetto alla CLDC. Inoltre è implementato un sottoinsieme delle API del package java.net di J2SE. CLDC fornisce il solo package javax.microedition. 20
o Sicurezza: è presente in CDC il modello di security della J2SE, anche se, ovviamente, in forma ridotta. La CLDC, diversamente, supporta solo un modello semplificato di sicurezza. In tabella 1.4 sono illustrati i package facenti parte della configurazione CDC insieme con una breve descrizione delle funzionalità che questi offrono: Package java.io classi: 36 interfacce: 10 eccezioni: 16 java.lang classi: 30 interfacce: 3 eccezioni: 24 java.lang.ref classi: 5 interfacce: 0 eccezioni: 0 java.lang.reflect classi: 8 interfacce: 2 eccezioni: 2 java.math classi: 1 interfacce: 0 eccezioni: 0 java.net classi: 12 interfacce: 5 eccezioni: 6 java.security, java.security.cert classi: 21 interfacce: 6 eccezioni: 13 java.text, java.text.resources classi: 11 interfacce: 0 eccezioni: 1 java.util, java.util.zip classi: 44 interfacce: 11 eccezioni: 7 javax.microedition.io classi: 1 interfacce: 8 eccezioni: 1 java.util.jar, Funzione Consente la lettura e la scrittura dei flussi di di I/O. Tale package contiene molte delle classi omesse in CLDC. Fornisce classi che sono il cuore del linguaggio Java. Nel package sono inclusi gli oggetti System, Thread e Runtime. Inoltre sono incluse le classi Double e Float. Contiene i reference types tra cui weak refernces. Fornisce le API di reflection Contiene la sola classe BigInteger e i metodi per lavorare con oggetti del tipo BigInteger. Sottoinsieme dell omonimo package di J2SE. Consente connessioni http url-based e comunicazioni connectionless con datagrammi. Supporta le funzionalità di sicurezza Fornisce caratteristiche di internazionalizzazione per il supporto di lingue multiple Contiene ultilities per la manipolazione di data e ora e implementa le java collections di base. 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 21
i package di J2SE v.1.3.1, di CLDC v.1.0 e CDC v.1.0. Per ciascun package è indicato il numero di classi, di interfacce e di eccezioni: J2SE CDC CLDC Package C I E C I E C I E java.io 50 10 16 36 10 16 11 2 5 java.lang 31 3 24 30 3 24 15 1 19 java.lang.ref 5 - - 5 - - - - - java.lang.reflect 8 2 2 8 2 2 - - - java.math 2 - - 1 - - - - - java.net 21 6 8 12 5 6 - - - java.security 39 9 15 19 6 11 - - - java.security.cert 8 1 6 2-2 - - - java.text 20 2 1 11-1 - - - java.util 36 13 5 32 11 4 7 1 2 java.util.jar 7-1 6-1 - - - java.util.zip 14 1 2 6-2 - - - Javax.microedition.io - - - 1 8 1 1 8 1 Tabella 1.5 Java Environment a confronto (C - Classi; I - Interfacce; E - Eccezioni). 22
1.3.4 I Profili nel dettaglio Per disporre di un ambiente J2ME su di un particolare device, è necessario avere almeno una virtual machine, una configurazione e un profilo. Profili opzionali possono poi essere installati per offrire funzionalità aggiuntive. I profili realizzano la specificità, necessaria all ambiente, attraverso tre strade: Fornendo il supporto alle GUI Consentendo la persistenza Implementando le Abstract Networking API, della configurazione sottostante. Data la flessibilità che i profili conferiscono all architettura J2ME, vi sono molteplici progetti che sono stati portati a termine, per sposare le necessità di svariate famiglie di dispositivi, e altri in corso d opera. Di seguito riportiamo alcuni profili CLDC based, corredati da una breve descrizione: o Mobile Information Device Profile (MIDP): è il primo reso disponibile dalla Sun, esso fornisce la GUI ed altre funzionalità proprie dei dispositivi mobili, quali i telefoni cellulari. Il MIDP è anche disponibile per i palmari PalmOS. o Personal Digital Assistano Profile (PDAP): ancora in via di sviluppo, tale profilo sostituirà il MIDP sui PDA, adattandosi all hardware e alla interfaccia utente propria dei palmari. o Altre API: tra i profili opzionali per la configurazione CLDC, evidenziamo:le API relative alla riproduzione di popolari formati audio: Mobile Media API (JSR-135) ; le API per il supporto dello standard Bluetooth e le API USB (Universal Serial Bus). Elenchiamo ora alcuni profili basati sulla configurazione CDC: o Foundation Profile: forma uno strato indispensabile per molti profili CDCbased. Tale profilo è il primo ufficialmente rilasciato dalla Sun per la configurazione CDC. o Personal Bases Profile: implementa le funzionalità di base per il Personal Profile. Esso non fornisce compatibilità con l ambiente Personal Java. 23
o Personal Profile: completa il Personal Bases Profile apportando piena compatibilità con Personal Java. o Altri profili: tra quelli opzionali citiamo il profilo RMI (Remote Method Invocation), le Mobile Media API (JSR-135) e il Game Profile. Quest ultimo richiede l impiego del Foundation Profile e non è stato ancora portato a termine. 1.3.4.1 Il profilo MIDP Il Mobile Information Device Profile, è in assoluto il profilo più diffuso, essendo tra l altro orientato a dispositivi, come i telefoni cellulari, che hanno una diffusione quasi capillare nei paesi industrializzati. Le funzionalità che il MIDP apporta alla configurazione su cui poggia, la CLDC, si possono riassumere nelle seguenti: GUI di basso livello; Persistenza; Connettività di rete HTTP-based; Supporto temporale alle applicazioni; Gestione del ciclo di vita delle applicazioni (MIDlet). Le API introdotte nel profilo, basate sull implementazione delle precedenti aree chiave, completano i package della CLDC e ne formano di nuovi. I requisiti dei dispositivi che sposano il profilo MIDP sono quelli della configurazione CLDC, in aggiunta essi devono avere: Un piccolo display; Un modo per fornire input al device, ad esempio una piccola tastiera o un touch screen; Memoria non volatile sufficiente a contenere, oltre alla macchina virtuale e alla configurazione, anche il profilo. In realtà i 128k, indicati come requisito della CLDC, possono essere sufficienti allo scopo; Almeno 8k di memoria di memoria non volatile per l archiviazione dei dati delle applicazioni; 24