Java 2 Micro Edition: un ritorno alle origini
Nel dicembre del 1990 nacque all'interno di Sun MicroSystem un progetto denominato "Green Project", il cui principale obiettivo consisteva nello sviluppare software per l'elettronica di vasto consumo. Questo mercato richiedeva prodotti semplici, affidabili e di basso costo. Inoltre i prodotti per l'elettronica di consumo dovevano essere il più possibile "neutrali" rispetto alla piattaforma usata: quest'ultima caratteristica dava la possibilità di produrre, su vasta scala, apparati elettronici con le più svariate CPU senza ricorrere, per ognuna di essa, ad un software dedicato. Se oggi possiamo dire che la piattaforma Intel compatibile è lo standard de-facto nel mondo dei PC, nel 1990 non esisteva un analogo standard nel mondo dei piccoli dispositivi elettronici; ed oggi la situazione non è cambiata di molto.
Il tentativo di estendere il C++ per renderlo indipendente dalla piattaforma si rivelò ben presto un fallimento, rendendo necessario lo sviluppo di un nuovo linguaggio di programmazione: nacque così Oak. Il linguaggio non riuscì però ad affermarsi nel settore dell'elettronica di consumo soprattutto per ragioni di carattere commerciale.
Agli inizi del 1994 l'attenzione dei responsabili del "Green Project" fu indirizzata verso il World Wide Web, che, nato al CERN nel 1992 e presto diffusosi in tutto il mondo, aveva aperto Internet all'interesse del grande pubblico. Con il WWW si riproponeva, seppure in modo differente, il problema dell'indipendenza dalla piattaforma, anche tenendo conto che Sun era ed è un produttore di piattaforme basate su microprocessori concorrenti rispetto al prodotto dominante di Intel. Il linguaggio Oak fu rivisto e modificato per renderlo adatto allo sviluppo di programmi che potessero essere eseguiti da un client WWW.
Nel maggio del 1995 Sun Microsystem decise la distribuzione della versione alpha di Oak. Il marchio Oak era però già utilizzato e occorreva un nuovo nome: forse con poca fantasia, fu scelto Java, che in slang americano vuol dire "tazza di caffè" (americano!), con l'evidente riferimento alla macchina distributrice di bevande calde di cui probabilmente i ricercatori di Sun facevano frequente uso.
Negli anni successivi Java ha avuto una notevole diffusione prima nel mondo client, attraverso la realizzazione di applet, e poi soprattutto nel mondo server, grazie alle tecnologie servlet ed EJB (Enterprise Java Beans), che permettevano la realizzazione di servizi WWW e sistemi di back-end. Questa grande differenziazione ha spinto Sun a creare tre diverse "edizioni" (edition) di Java, che pur rimanendo basate grossomodo su virtual machine compatibili ed un insieme di API di base, si sono differenziate a seconda del loro target. Le "edition" sono state introdotte con il rilascio di Java2, e "partizionano" piattaforme, API, e strumenti di sviluppo in tre differenti gruppi ognuno dei quali indirizzato ad un ben preciso segmento di mercato:

• Java 2 Enterprise Edition (J2EE), fornisce un insieme di API per la realizzazione di architetture solide, complete e scalabili, dirette, soprattutto, ad applicazioni server;
• Java 2 Standard Edition (J2SE), rappresenta il core del linguaggio Java ed è indirizzata allo sviluppo di applicazioni ed applet sul lato client;
• Java 2 Micro Edition (J2ME), studiata appositamente per l'embedded e per l'elettronica di consumo;
  

A distanza di sei anni dalla sua "nascita", Java si è riaffacciato, con la Micro Edition, al settore embedded per il quale era stato concepito, con la consapevolezza che la situazione di questo mercato è molto differente da allora: sicuramente molto più "matura" e preparata ad un suo utilizzo. In realtà un certo interesse verso il mercato embedded, Java lo aveva sempre dimostrato, aldilà delle sfortunate sorti del linguaggio Oak. Sun Microsystem, insieme ad alcuni suoi partner e sviluppatori indipendenti ha creato nel tempo tutta una serie di moduli e API che estendono le caratteristiche standard di Java permettendo l'utilizzo del linguaggio anche nel settore embedded (PersonalJava, JavaPhone, JavaTV, Embedded Java). Non si trattava però di un progetto ben delineato e definito, ma di un insieme di moduli, tra loro poco (o per niente) correlati, studiati per rispondere a ben determinate esigenze. J2ME, al contrario, non è indirizzata a singole piattaforme ma, in generale, al settore embedded tutto, la sua architettura e le sue specifiche sono ben delineate ed è essa stessa una versione standard di Java. Naturalmente il fatto che J2ME sia dedicata a tutto il mercato embedded non vuol certo dire che possa essere utilizzata con qualunque tipo di apparecchiatura e in qualunque contesto. La sua struttura modulare ed espandibile permette però di coprire una vasta gamma di piattaforme (apparati) embedded: dai PDA ai cellulari, dai navigatori satellitari a TV digitali con i vantaggi che il linguaggio Java può portare. Uno degli aspetti più interessanti e apprezzati di Java è sempre stato il suo alto grado di portabilità e il suo livello di astrazione dall'hardware, che J2ME mantiene ed estende ad un settore, quello dell'elettronica di consumo, davvero ricco di piattaforme differenti.

Java, il settore embedded e l'elettronica di consumo
La diffusione di palmari, pager, agende elettroniche, cellulari, smartphone, navigatori satellitari rappresenta ormai una realtà di mercato consolidata. Questi dispositivi vengono collocati in quello che viene definito mercato o settore dell'elettronica di consumo, vale a dire in tutti quegli apparati che ci circondando nella vita quotidiana: elettrodomestici, sistemi di intrattenimento domestico (apparati hi-fi, videoregistratori, televisori, TV satellitari, videogame), telefonia, ecc.. Si parla anche di mondo "embedded": non esiste una definizione precisa del termine, ma con esso si indicano sistemi elettronici a microprocessore, spesso dotati di un hardware progettato ad hoc, concepiti per una determinata applicazione. Tali sistemi possono operare in autonomia o essere, in qualche modo, legati ad altri apparati. Il significato del termine è quindi molto generico e riguarda dispositivi molto eterogenei che si differenziano per complessità dell'hardware e del software, dimensioni e naturalmente per le funzioni per le quali sono stati realizzati. L'idea di disporre di tecnologie integrate con l'ambiente che ci circonda (in inglese per l'appunto embedded) non è un fenomeno recente ma, è un processo iniziato parecchi anni orsono e interessa sempre più gli oggetti di uso comune.
Certamente questo progressivo aumento nell'uso di apparati elettronici, e in particolare di dispositivi digitali, non riguarda solo l'elettronica di consumo e l'ambito domestico, ma è un processo che coinvolge gran parte della realtà che ci circonda. L'elettronica di consumo è forse il settore dove la tecnologia e il suo reale potenziale sono più visibili e alla portata di tutti.
Dal punto di vista della programmazione questa "eterogeneità estrema" del settore embedded fa nascere l'esigenza di dover disporre di strumenti (API, tool di sviluppo, ecc.) dedicati per ogni singola piattaforma hardware. Sembra difficile quindi poter mantenere quel proverbiale "Write once, run anywhere" che da sempre accompagna il linguaggio Java. D'altronde le differenze tra un cellulare e una Web TV sono quelle che sono.....
La sistuazione però non è così critica. Non è poi un gran problema commerciale se un applicativo per cellulare, ad esempio per inviare e-mail, non gira nel microcontrollore di un videoregistratore! Può però esserlo se dello stesso applicativo occorre scriverne una versione per cellulari Nokia, una per Motorola, per Ericsson, Panasonic .........e magari più versioni per ogni marca, in modo da coprire tutta la gamma dei prodotti, con l'aumento dei costi che ne consegue. Di fronte ad un simile scenario, è evidente come un'unica soluzione Java, intesa coma una Virtual Machine e un insieme di API, non sarebbe stata una scelta ottimale: avrebbe comportato da un lato l'esclusione di tutti quei dispositivi con requisiti inferiori a quelli minimi richiesti, dall'altro non avrebbe permesso il pieno sfruttamento degli apparati più dotati.
Occorreva quindi un'architettura scalabile e modulare che permettesse di coprire il più possibile la gamma dei dispositivi del settore sfruttandone le differenti caratteristiche: J2ME appunto.

L'architettura J2ME
Queste caratteristiche di modularità e scalabilità vengono garantite in J2ME attraverso i concetti di Configurazioni e Profili:

Figura 1 - I layer dell'architettura J2ME.

• Configurazioni - definiscono le caratteristiche di base del linguaggio Java e della Virtual Machine per un insieme di dispositivi, forniscono un insieme di librerie di base comuni per più categorie di apparati (es. Cellulari, PDA, smartphone);
• Profili - si basano su una configurazione, ne estendono le funzionalità di base, fornendo API addizionali e tools di sviluppo per una particolare categoria di dispositivi (es PDA). Le applicazioni scritte per un dato profilo sono portabili ed eseguibili su qualunque dispositivo che lo supporti;
• Le configurazioni, quindi, sono dirette ad un insieme di apparati e non ad una specifica categoria, mentre i profili sono qualcosa di più "legato" al dispositivo stesso. Prendendo come riferimento l'intero settore embedded si può dire che, mentre le configurazioni eseguono un "raggruppamento" dei dispositivi in senso orizzontale, i profili lo fanno in senso verticale.

Figura 2 - Configurazioni e profili di J2ME.

Va detto che sebbene i profili siano diretti ad una particolare segmento di mercato il loro utilizzo è in realtà flessibile: un dispositivo può supportare più profili, spetta quindi al programmatore la scelta di utilizzare quello più idoneo e conveniente per la realizzazione di una data applicazione.
Talvolta infatti un profilo, seppure dedicato ad una categoria di dispositivi differente può risultare particolarmente adatto alla realizzazione di un applicativo (utilizzo "orientato all'applicazione"), quando è invece necessario utilizzare le caratteristiche proprie dei vari dispositivi è necessario ricorrere al profilo dedicato (utilizzo "orientato al dispositivo"). Occorre aggiungere che, per le loro caratteristiche intrinseche alcuni profili risultano più "device-specific" (es. PDA Profile, MID Profile) di altri (es. Foundation Profile, PersonalProfile, RMI Profile) che possiamo definire invece "application-specific".

Configurazioni
Abbiamo detto che le configurazioni raggruppano i dispositivi "orizzontalmente" cioè, stabiliscono le caratteristiche della macchina virtuale e forniscono librerie di base per un insieme di dispositivi con risorse hardware simili. Le attuali configurazioni previste da J2ME suddividono il variegato settore embedded in due grandi segmenti. In base alle caratteristiche dei vari apparati possiamo distinguere:

• dispositivi a uso esclusivamente personale, mobili, che necessitano di connessioni a reti in modo non continuo. In questa categoria rientrano i telefoni cellulari, i pager, i PDA, cioè tutti quei dispositivi caratterizzate da un'interfaccia utente molto semplice, ridotte disponibilità di memoria (tipicamente 128 Kbyte - 2 Mbyte), limitate capacità di elaborazione, basso consumo di energia e connessioni a reti di telecomunicazione di tipo wireless con modesta larghezza di banda.
• dispositivi condivisi, fissi, che necessitano di connessioni a reti in modo continuo. Tipici esempi di apparecchiature che rientrano in questa categoria sono Web TV, telefoni capaci di accedere ad Internet, ricevitori televisivi satellitari, communicator, sistemi di navigazione per auto. Tutti questi dispositivi, essendo installati in modo fisso, non risentono dei tipici problemi dei dispositivi portatili (o addirittura tascabili) come peso, dimensioni e consumi di energia e possono, quindi, contare su dotazioni di memoria anche notevoli (da 2 Mbyte a 32 MByte), processori veloci e performanti e connessioni continue a reti con ampia larghezza di banda.

Naturalmente, il confine che separa queste due categorie non è, e certamente non può essere, netto. Tuttavia questa suddivisione è importante soprattutto per tenere in considerazione alcune caratteristiche hardware fondamentali del dispositivo sul quale il software dovrà funzionare quali:

• la potenza di calcolo e la disponibilità di memoria;
• la presenza o meno di un display e le sue caratteristiche;
• le tipologie di connessione a reti di TLC;

E' proprio sulla base di questi parametri che J2ME ha implementato le sue due attuali configurazioni, ossia:

• CLDC (Connected Limited Device Configuration) - è dedicata a dispositivi con memoria minima di circa 128 Kbyte (RAM e ROM), processori (RISC/CISC) a 16-32 bit, basso consumo e funzionamento tipicamente a batteria, connessioni non continue a reti eterogenee, sovente di tipo wireless con larghezza di banda limitata (spesso uguale o inferiore a 9600 bps). La Virtual Machine prevista per questa configurazione è la KVM (Kilobyte Virtual Machine), ossia una macchina virtuale Java studiata per apparecchi con memoria totale dell'ordine dei Kbyte (il core della KVM occupa da 32 a 80 Kbyte).
• CDC (Connected Device Configuration) - è studiata per dispositivi hardware che dispongono di almeno 2 MByte totali di memoria (RAM e ROM), processori a 32 bit, di connessioni persistenti a reti TLC con ampia larghezza di banda e interfacce grafiche anche molto sofisticate. La virtual Machine utilizzata per questa configurazione è la CVM (C Virtual Machine).

La CLDC può essere considerata come una versione "alleggerita" della CDC. Abbiamo visto che le configurazioni forniscono un set minimo di librerie di base: alcune di queste costituiscono un sottoinsieme di package della Standard Edition altri, sono state realizzate appositamente per la Micro Edition (figura 3).

Figura 3 - Configurazioni J2ME e Standard Edition.

Tutto ciò è molto importante: ci dice che in realtà J2ME altro non è che Java "ridisegnato" per piattaforme "non convenzionali", con un set minimo di API ridotto e con alcune Java Extension dedicate, adatto a funzionare in apparati tra loro molto differenti e anche con risorse limitate. Questo garantisce la compatibilità "verso l'alto", con le versioni "maggiori". Il bytecode della J2ME, infatti, resta perfettamente compatibile con quello delle altre versioni (questo non avviene ad esempio con tecnologie alternative come Waba, un linguaggio di programmazione per dispositivi palmari, molto simile a Java, ma con un bytecode non compatibile. Vedi articolo MokaByte numero 33 del settembre 1999). Non solo: nonostante alcune limitazioni e differenze rispetto alla Standard Edition, dovute al target di dispositivi a cui è diretta, J2ME mantiene inalterate tutte le caratteristiche principali del linguaggio, non si tratta quindi di una versione "speciale" per dispositivi particolari ma di Java "puro".

Profili

Le funzionalità di base garantite dalle configurazioni però non bastano per realizzare un applicativo. Prendiamo ad esempio un cellulare. La configurazione dedicata è la CLDC: questa ci mette a disposizione un insieme di librerie di base che permettono di "utilizzare Java" (java.lang), di gestire gli stream di I/O (java.io), ci fornisce tutta una serie di classi di utilità (java.util) e ci da la possibilità di comunicare (javax.microedition.io).
E l'iterazione con l'utente ?....le interfacce grafiche ?.... Il salvataggio dei dati? E ancora: come si arriva all'eseguibile per cellulare partendo dal classico .java? A tutto questo è chiamato a rispondere il profilo. Esso si occupa di gestire tutte quelle problematiche più strettamente collegate al tipo di apparato, come la gestione dei dispositivi di Input/Output, il salvataggio persistente dei dati nelle memorie non volatili, la realizzazione di UI e fornisce tools di sviluppo per una determinata categoria di dispositivi (in questo caso i cellulari). I profili si suddividono in base alla configurazione per la quale sono stati realizzati. Quelli attualmente previsti (non tutti attualmente disponibili) sono:

per la configurazione CDC:

• Foundation Profile: profilo per dispositivi che richiedono una completa implementazione della Java Virtual Machine e includono quindi tutte le API della J2 Standard Edition;
• RMI Profile: questo tipo di profilo, come indicato dal nome, include un sottoinsieme di API RMI (Remote Method Invocation) della J2SE, in modo da garantire un certo grado di interoperatività con altre virtual machine sia J2ME sia J2SE;
• Personal Profile: è l'estensione dell'ambiente PersonalJava di Sun e garantisce una piena compatibilità con le applicazione sviluppate con le versioni 1.1.X e 1.2.X di PersonalJava Application Enviroment;

per configurazione CLDC:

• PDAP: il Personal Digital Assistant Profile è il profilo dedicato ai dispositivi palmari. Tali apparati devono avere almeno 512 Kbyte di memoria (RAM + ROM) e un display con risoluzione totale di almeno 20.000 pixel;
• MIDP: il MIDP (Mobile Information Device Profile) è un profilo dedicato a dispositivi wireless come telefoni cellulari, smartphone e pager;

Risulta subito evidente uno dei vantaggi derivanti dalla scalabilità e dalla modularità di J2ME: è possibile implementarne nuovi profili senza modificare le configurazioni di base esistenti con una conseguente riduzione dei tempi di sviluppo e dei costi di realizzazione.
Con questa prima puntata abbiamo definito i concetti fondamentali del mondo J2ME. Nei prossimi articoli esploreremo più in dettaglio le configurazioni ed i profili più interessanti ed illustreremo alcuni esempi di programmazione reale.

Bibliografia

• http://java.sun.com/j2me/ Sito "ufficiale" di J2ME, dal quale è possibile scaricare configurazioni e profili della J2ME con relativa documentazione. Contiene inoltre numerosi link ad altre tecnologie Java dirette al settore embedded;
• http://www.billday.com/j2me/index.html Il punto di riferimento (...o di partenza) per tutti gli sviluppatori J2ME, dove è possibile scaricare documentazione, tool di sviluppo, emulatori, nonché il codice sorgente di molte applicazioni;
• http://archives.java.sun.com/archives/kvm-interest.html Una delle migliori (e più "attive") mailing-list su J2ME dove potrete trovare molte risposte alle vostre domande;

Marco Tomà si occupa di programmazione Java dal 1998. Si è interessato a Java 2 Micro Edition sin dal primo rilascio avvenuto nel 1999, in particolare si è occupato dello sviluppo di applicazioni Java per dispositivi palmari PalmOS. E' contattabile all'indirizzo mtoma@mokabyte.it.