Introduzione a J2ME
Prima di entrare nell'universo J2ME è bene riassumere le piatteforme Java
attualmente disponibili:
-
Standard
Edition (J2SE), ideata per funzionare sui desktop e workstation.
-
Enterprise
Edition (J2EE), ideata per applicazioni enterprise sui server.
-
Micro
Edition (J2ME), ideata per dispositivi con caratteristiche e capacitá di
elaborazione limitate.
Java
2 Micro Edition(J2ME), è l'edizione della piattaforma Java 2 designata per
apparecchi consumer ed embebbed, come
cellulari, PDA, decoder TV (set top box) e tutta una serie di altri
dispositivi portatili e senza fili.
Con l'avvento di una versione "lite" di Java, si ha a
disposizione tutta la potenza del linguaggio Java e un ambiente di runtime
che fornisce una piattaforma sicura e portabile.
Per supportare una vasta gamma di prodotti Sun ha
introdotto il concetto di Configurazione.
La Configurazione è strettamente legata alla Java
Virtual Machine e definisce una piattaforma Java per un'ampia gamma di
prodotti. I campi di applicazione della Configurazione sono la memoria, lo
schermo, la connettività di rete e la potenza di calcolo del
dispositivo.
Le Configurazioni attualmente disponibili
sono:
Connected
Device Configuration - CDC
(Configurazione
di dispositivo connesso)
-
512 kbytes (minimo) di memoria per l'esecuzione di
Java.
-
256 kbytes (minimo) per l'allocazione di memoria al
momento dell'esecuzione.
-
Connettività di rete, possibilmente persistente e a
banda larga.
Connected,
Limited Device Configuration - CLDC
(Configurazione
di dispositivo limitato e connesso)
-
128 kbytes di memoria per l'esecuzione di Java.
-
32 kbytes di memoria per l'allocazione di memoria
al momento dell'esecuzione.
-
Interfaccia utente limitata.
-
Alimentazione elettrica ridotta.
-
Connettività di rete, a banda stretta e ad accesso
intermittente.
Per
introdurre una maggiore flessibilità rispetto ai cambiamenti tecnologici, Sun
ha introdotto il concetto di Profilo.
Il
Profilo è un'estensione della Configurazione, fornisce le librerie per un
particolare dispositivo.
Un'esempio di profilo è MIDP (Mobile Information Device Profile), che
definisce un set di API per i componenti della user interface, per gli input,
per la memoria persistente, per gli eventi, per le attività di rete,
considerando le capacità limitate di schermo e memoria.
Come si può notare dall'immagine sopra, per CDC la Java Virtual Machine è la
stessa della piattaforma J2SE, per CLDC si ha la K Virtual Machine. Questa
macchina virtuale progettata per gestire le caratteristiche dei dispositivi a
risorse limitate.
La KVM ha le seguenti caratteristiche:
-
Necessita di soli 40-80 kbyte di memoria.
-
Sono richiesti solo 20-40 kbyte di memoria dinamica.
-
Può essere eseguita su microprocessori a 16 bit con un clock di soli 25 Mz.
Configurazione di dispositivi limitati e connessi (CLDC)
I contenuti di questo articolo e dei prossimi (speriamo di aver tempo)
riguardano la programmazione per CLDC 1.0 e MIDP 1.0.
Come già indicato precedentemente CLDC è un gruppo di API che si rivolgono a
dispositivi con capacità di calcolo, memoria e schermo limitati (cellulari e
cercapersone).
Gli unici requisiti hardware per CLDC riguardano la memoria e sono i seguenti:
Dal
lato software CLDC ha dei requisiti minimi. Il sistema
operativo o il kernel deve poter gestire l'hardware. Il sistema
operativo deve fornire almeno un'entità di schedulazione per
eseguire la Java Virtual Machine.
Le
specifiche CLDC riguarderano le seguenti aree:
-
Il
linguaggio Java e le caratteristiche della virtual machine.
-
Le
librerie basi di Java (java.lang.*, java.util.*).
-
Input
/ output.
-
Networking.
-
Security.
-
Internationalization.
Invece
le specifiche potrebbero non riguardare le seguenti caratteristiche:
-
La
gestione del ciclio di vita dell'applicazione (installazione dell'applicazione,
l'avvio e la rimozione).
-
Le
funzionalità dell'user-interface.
-
La
gestione degli eventi.
-
L'iterazione
tra l'utente e l'applicazione.
Queste
caratteristiche possono essere trattate dai profili implementati al di sopra
del CLDC.
Differenze
tra i linguaggi Java.
Floating-point
La
differenza principale tra le specifiche del linguaggio Java e le
specifiche CLDC è che la KVM non supporta i calcoli in virgola mobile. Il
supporto della virgola mobile è stato rimosso perchè la maggior parte dei
dispositivi che rientrano nelle specifiche CLDC non hanno l'hardware per
il supporto della virgola mobile e poichè il costo del supporto della
virgola mobile via software è stato considerato troppo alto.
Finalization
Le
librerie CLDC non includono il metodo Object.finalize(), e
quindi una Virtual Machine che supporta CLDC non supporterà
la finalizzazioine di instanze di classi.
Error
handling limitations
Una
JVM che supporta CLDC dovrebbe in generale supportare la gestione delle
eccezioni. Tuttavua, l'insieme degli errori inclusi in CLDC è limitato e
conseguentemente la capacità di gestione degli errori è
ristretta. Ciò è a causa di due motivi:
-
Nei
sistemi embedded, spesso il recupero da condizioni di errore è fortemente
specifico del dispositivo. Mentre alcuni tipi di apparecchi potrebbero tentare
di rispristinare il sistema gestendo l'errore, altri risolveranno effettuando
un reset del sistema.
-
Implementare
l'intera gestione degli errori presente nella piattaforma J2SE
richiederebbe un prezzo elevato in termini di carico del sistema.
Differenze
tra le JVM.
Floating
point support
Una
JVM che che supporta CLDC non ha il supporto per i calcoli in virgola mobille.
Tale
supporto è stato rimosso perchè la maggior parte dei dispositivi che rientrano
nella definizione di CLDC non hanno hardware dedicato e il costo per un
supporto software sarebbe troppo elevato.
Java Native Interface (JNI)
Una JVM che che supporta CLDC non implementa Java Native Interface (JNI).
Questo per due motivi:
-
Il modello di sicurezza limitato fornito da CLDC suppone che il set
di funzioni native devono essere chiuse.
-
La completa implementazione di JNI è stata considerata troppo costosa dato i
vincoli limitati di memoria previsti per i dispositivi che si attengono a CLDC.
User-defined class loaders
Una JVM che supporta CLDC dovrebbe avere un caricatore di classi incluso
che non può essere escluso, sostituito o riconfigurato dall'utente. L'attuale
implementazione del caricatore di classi cosi come ogni altro tipo di
condizione di errore che accadono durante il caricamento delle classe sono
dipendenti dall'implementazione.
Reflection
CLDC non dispone della Reflection, cioè della caratteristiche che permette ad
un programma Java di ottenere informazioni sul numero e sul contenuto delle
classi, oggetti, motodi, campi, threads e altre strutture dentro la Virtual
Machine.
Thread groups and daemon threads
LA JVM implementa il multithreading, ma non supporta i gruppi di thread.
Le operazioni sui thread come l'avvio o l'arresto possono essere
applicate solo agli oggetti thread trattati individualmente. Per simulare
questa attività si può ricorrere a collezioni e fornendo metodi per
l'avvio e l'arresto di tutti gli oggetti della collezione.
Finalization
Le librerie CLDC non includono la finalizzazione.
Weak references
CLDC non dispone i weak references.
Errors
Come detto precedentemente la gestione degli errori di una JVM è limitata.
Sicurezza.
L'ambiente
J2SE o J2EE fornisce il concetto di gestione della sicurezza. Il
gestore della sicurezza è chiamato ogni volta che una parte
dell'applicazione Java o il runtime ha bisogno di accedere ad una risorsa
protetta. Purtroppo, il modello di sicurezza di J2SE è troppo oneroso in
termini di risorse per essere incluso in un dispositivo CLDC che ha
capacità limitate.
Una
JVM che supporta CLDC fornisce una semplice modello di sicurezza
denominato "sandbox". In pratica un applicazione Java deve girare in un
ambiente chiuso nel quale l'applicazione può solamente accedere alle
API che sono state definite nella Configurazione, Profilo o classi
supportate dal device. I profili J2ME potrebbero tuttavia fornire
addizionali soluzioni di sicurezza.
Verifica
dei file di classe.
Come
per una J2SE virtual machine standard, anche una JVM che supporta CLDC deve
essere capace di rifiutare un invalido file di classe. La verifica
dell'integrità del file nella piattaforma J2SE non è ideale per limitati
devices. La verifica in J2SE necessità di almeno 50 kB e circa 30-100
kB di RAM a runtime mentre l'implementazione per KVM richiede
10 kilobytes e meno di 100 bytes di RAM in esecuzione.
La
verifica dei file di classe si compone di due parti:
-
Pre-verification
(off-device), avviene generalmente fuori dal dispositivo, per esempio
sul server dove l'applicazione viene scaricata o sulla macchina dove viene
sviluppata. La pre-verification inserisce attributi speciali nei
normali file di classe. Ciò permette che la verifica sia effettuata
efficientemente a tempo di esecuzione. I file di classe precedentemente
processati, contenente attributi extra, sono apprositivamente il 5% più
grandi degli originali.
-
In-device
verification , è effettuata all'interno del dispositivo che
contiene la virtual machine e controlla tutte le istruzioni contenute
all'interno dei file di classe scartando il file in caso di errore.
Classi
CLDC.
La
maggior parte delle librerie incluse in CLDC è un sottoinsieme della
piattaforma J2SE per assicurare la compatibilità ascendente e la
portabilità delle applicazioni.
Le
librerie CLDC presentate in questa nella specifica CLDC possono essere divise
in due categorie:
-
quelle
classi che sono un sottoinsieme delle librerie standard di J2SE,
-
quelle
classi che sono specificghe di CLDC (ma che possono essere mappate su
J2SE).
System
classes
Data
type classes
-
java.lang.Boolean
-
java.lang.Byte
-
java.lang.Short
-
java.lang.Integer
-
java.lang.Long
-
java.lang.Character
Collection
classes
-
java.util.Vector
-
java.util.Stack
-
java.util.Hashtable
-
java.util.Enumeration (interface)
Input/output classes
-
java.io.InputStream
-
java.io.OutputStream
-
java.io.ByteArrayInputStream
-
java.io.ByteArrayOutputStream
-
java.io.DataInput (interface)
-
java.io.DataOutput (interface)
-
java.io.DataInputStream
-
java.io.DataOutputStream
-
java.io.Reader
-
java.io.Writer
-
java.io.InputStreamReader
-
java.io.OutputStreamWriter
-
java.io.PrintStream
Calendar and time classes
-
java.util.Calendar
-
java.util.Date
-
java.util.TimeZone
Additional utility classes
-
java.util.Random
-
java.lang.Math
Exception classes
-
java.lang.Exception
-
java.lang.ClassNotFoundException
-
java.lang.IllegalAccessException
-
java.lang.InstantiationException
-
java.lang.InterruptedException
-
java.lang.RuntimeException
-
java.lang.ArithmeticException
-
java.lang.ArrayStoreException
-
java.lang.ClassCastException
-
java.lang.IllegalArgumentException
-
java.lang.IllegalThreadStateException
-
java.lang.NumberFormatException
-
java.lang.IllegalMonitorStateException
-
java.lang.IndexOutOfBoundsException
-
java.lang.ArrayIndexOutOfBoundsException
-
java.lang.StringIndexOutOfBoundsException
-
java.lang.NegativeArraySizeException
-
java.lang.NullPointerException
-
java.lang.SecurityException
-
java.util.EmptyStackException
-
java.util.NoSuchElementException
-
java.io.EOFException
-
java.io.IOException
-
java.io.InterruptedIOException
-
java.io.UnsupportedEncodingException
-
java.io.UTFDataFormatException
Error classes
-
java.lang.Error
-
java.lang.VirtualMachineError
-
java.lang.OutOfMemoryError
Internationalization
-
java.io.InputStreamReader
-
java.io.OutputStreamWriter
Supporto delle proprietà
CLDC non implementa la classe java.util.Properties, che è parte
di J2SE. Tuttavia, un insieme limitato di proprietà descritte sotto è
disponibile. A queste proprietà si può accedere chiamando il metodo
System.getProperty(String key).
|
Chiave |
Spiegazione |
Default |
| microedition.platform |
Il nome della piattaforma host/dispositivo |
null |
| microedition.encoding |
Il carattere predefinito di codifica |
ISO8859_1 |
| microedition.configuration |
Il nome e la versione della configurazione supportata |
CLDC-1.0 |
| microedition.profiles |
Il nome dei profili supportati |
null |
I profili potrebbero definire altre proprietà non incluse nella tabella sopra.
Classi specifiche CLDC
Le librerie J2SE e J2EE forniscono un insieme ricco di funzionalità per
la gestione dell'input e dell'output per l'accesso ai sistemi di rete e al
salvataggio delle informazioni. Il package java.io.* di J2SE contiene
approssimativamente 60 classi e interface e più di 15 exception
mentre il package java.net.* circa 20 classi e 10 exception. La
grandezza totale di queste classi ammonta a circa 200 kilobytes.
Il requisito di avere piccoli sistemi J2ME ha condotto alla
generalizzazione delle classi di rete e di I/O della
piattaforma J2SE. L'obbiettivo principale per questo nuovo sistema è di
essere un preciso sottoinsieme funzionale delle classi J2SE, che può essere
facilmente adeguato ad un hardware di basso livello o a ogni
implementazione J2SE, ma con maggiore estendibilità, flessibilità e coerenza
nel supporto di nuovi device e protocolli.
Tutte le connessioni sono create usando un singolo metodo statico nella classi
di sistema chiamato Connector. Se va a buon fine, questo metodo restituisce un
oggetto che implementa una delle generiche interfaccie di connessione.
Connector.open("<protocol>:<address>;<parameters>");
|
Protocollo |
Esempio |
| HTTP |
Connector.open( "http://www.8mobile.org" ); |
| Sockets |
Connector.open( "socket://129.144.111.222:9000" ); |
| Communication ports |
Connector.open( "comm:0;baudrate=9600" ); |
| Datagrams |
Connector.open( "datagram://129.144.111.333" ); |
| Files |
Connector.open( "file:/test.dat" ); |
Bibliografia e risorse
[1] J2ME Documentation - http://java.sun.com/j2me/docs/index.html
[2] CLDC 1.0 (JSR 30) -
http://jcp.org/aboutJava/communityprocess/final/jsr030/index.html
|