Tecnicamente MIDP 2.0 è il frutto del gruppo di lavoro JSR 118, che comprende circa 60 esperti tra operatori telefonici, produttori di hardware e fornitori di servizi. Le novità principali, in riferimento alla versione 1.0, sono relative a queste aree:

- un modello di sicurezza (trustet MIDlets);
- supporto per il protocollo HTTP con crittografia (HTTPS);
- gestione della rete migliorata;
- supporto migliorato alla distribuzione delle applicazioni;
- nuovi componenti per le interfacce grafiche (GUI);
- supporto per giochi;
- supporto per capacità multimediali (suono e animazioni);

La maggior parte di queste innovazioni sono riconducibili al mondo della telefonia cellulare, quindi il profilo rimane ottimizzato per dispositivi con risorse limitate, come i cellulari, anche se si tiene ovviamente conto della loro inarrestabile evoluzione tecnologica, come per esempio il supporto di capacità multimediali. Vediamo ora più in dettaglio in cosa consistono queste novità.

Networking
Probabilmente tutti si ricordano che gli applet, fino al JDK 1.1, erano confinati ad una "sandbox", cioè un ambiente di esecuzione "ristretto" e protetto, dove solo un numero limitato di API "non pericolose" erano esposte all'applet. Questo modello è poi stato esteso dal JDK 1.2, dove i nuovi applet con firma digitale potevano essere configurati per eseguire operazioni fuori della sandbox.
Più o meno lo stesso concetto è stato ripreso per i MIDlet, cioè le mini-applicazioni Java(TM) che i telefonini sono in grado di eseguire: ora anche MIDP incorpora il concetto di Protection Domain (ovviamente si è tenuto conto di esigenze di semplificazione dovute alla minor potenza dell'hardware e quindi l'implementazione è meno sofisticata di quella presente in Java 2 Standard Edtion). In pratica, ogni MIDlet, in base a caratteristiche come la presenza di una firma digitale, può essere associato a diversi insiemi di "permessi" che gli consentono di eseguire operazioni "privilegiate", sempre sotto la supervisione dell'utente, al quale viene sempre generata una notifica su cosa sta succedendo. Il possessore del cellulare, quindi, potrà confermare o negare la concessione dei permessi aggiuntivi richiesti.
Si può osservare che MIDP si sta evolvendo lungo la stessa strada che è stata percorsa, qualche anno fa, dagli Applet di J2SE e qualcuno potrà forse chiedersi se questa infrastruttura non sia eccessiva per un telefono cellulare. Il dubbio dovrebbe essere fugato se si tiene presente che negli anni a venire saranno sempre più numerosi i servizi a cui potremo accedere attraverso questo dispositivo, incluso lo scambio di informazioni riservate da proteggere (come esempio classico basta pensare alle transazioni finanziarie).
Proprio per proteggere i nostri dati in transito sulla rete, ora MIDP 2.0 richiede esplicitamente supporto per i Secure Socket Layer, incluso quindi il protocollo HTTPS. L'implementazione è prevista attraverso la classe Connector, che rappresenta in generale un canale di comunicazione remoto tra il cellulare ed il resto del mondo, con alcune estensioni per la gestione dei certificati digitali. Il supporto alla crittografia su rete è fondamentale per aprire le porte ad applicazioni di commercio elettronico.
Per quanto riguarda la distribuzione automatica delle applicazioni, MIDP 2.0 incorpora formalmente il protocollo OTA (Over The Air), che definisce gli standard per il downloading dei MIDlet da rete; precedentemente il protocollo era definito in un allegato della specifica MIDP 1.0 ma non ne faceva parte. Inoltre, MIDP 2 prevede l'implementazione di meccanismi di notifica sicura verso il server in occasione dell'installazione o della rimozione di un MIDlet.
Contrariamente a MIDP 1.0, la versione 2.0 non prevede il supporto per i cookie, dal momento che si è rilevato che molti gateway di rete cellulare non li supportano. Le nostre applicazioni, pertanto, dovranno fare uso della tecnica "URL rewriting", che consiste nell'aggiungere l'informazione che avrebbe dovuto essere contenuta nel cookie in coda ad ogni URL utilizzata della nostra applicazione (in pratica è sufficiente codificare un codice univoco che identifichi la sessione). È sicuramente una seccatura, ma fortunatamente con MIDP le applicazioni sono molto più piccole di una tipica applicazione web tradizionale (spesso anche per le applicazioni web tradizionali si preferisce non ricorrere ai cookie), e quindi ci sarà richiesto meno lavoro per codificare il rewriting delle URL. Dal lato server, questa tecnica è già supportata dai webserver compatibili con le specifiche Java 2 Enterprise Edition e quindi non dovrebbero essere richiesti interventi diretti da parte del programmatore.

Interfaccia utente
Il profilo MIDP ha introdotto già dalla versione 1.0 una nuova API per la creazione di interfacce grafiche, chiamata LCDUI. Dopo molte discussioni si è deciso che la classica API AWT, presente sin dall'inizio su Java Standard Edition, è troppo complessa per essere implementata su un telefono cellulare (e a maggior ragione Swing non è neanche stato preso in considerazione). Questa scelta ha provocato non poche polemiche da parte della comunità dei programmatori, anche perché in realtà esistono implementazioni di terze parti di subset di AWT perfettamente funzionanti (da citare tra tutte kAWT); tuttavia la posizione ufficiale di Sun è che esse siano troppo "pesanti" in termini di velocità ed occupazione di memoria per un dispositivo della classe dei telefoni cellulari. Inoltre, sempre secondo Sun, la grande varietà di display e la loro risoluzione molto più bassa di quella di un comune computer rendono di fatto impossibile la progettazione di singole GUI portabili ed utilizzabili su tutti gli ambienti, dal personal di casa al cellulare: e dovendo quindi riprogettare le interfacce grafiche delle applicazioni MIDP, la necessità di usare una API differente non è poi un gran problema.
Con la versione MIDP 2.0, la API LCDUI è stata estesa per quanto riguarda queste aree:

- migliore supporto per componenti customizzati;
- gestione del layout;
- miglioramenti alla grafica;

I componenti customizzati sono già supportati dalla classe Item nella specifica MIDP 1.0; tuttavia essi non possono essere usati insieme alla classe Form, che permette di costruire le varie schermate dell'applicazione utilizzando componenti standard. Questa classe fornisce un minimo di funzionalità di layout e di gestione degli eventi, ma se vogliamo utilizzare un componente standard di fatto dobbiamo rinunciarvi, progettando "a mano" tutta la schermata.
Con MIDP 2.0, fortunatamente, la classe Item può tranquillamente essere utilizzata dentro una Form, insieme ai componenti standard, permettendo la realizzazione di approcci ibridi.
Abbiamo parlato di gestione del layout: in realtà quella del MIDP 1.0 è decisamente primitiva. L'unica proprietà che possiamo specificare, di fatto, è l'ordine con cui i componenti vengono aggiunti ad una Form. Le loro dimensioni e la decisione se visualizzarli uno a fianco all'altro piuttosto che uno sotto l'altro vengono completamente delegate al runtime, che decide in base alla risoluzione disponibile sul dispositivo; inotre i componenti non sono sempre in grado di ridimensionarsi per trarre vantaggio da una risoluzione più elevata (provate ad esempio ad eseguire un'applicazione MIDP su un palmare basaso su Palm OS, e vedrete che spesso e volentieri non viene sfruttato l'intero spazio a disposizione sullo schermo).
Con MIDP 2.0 è stato finalmente introdotto un layout manager più sofisticato, pur mantenendo la richiesta portabilità multi-piattaforma (che, a causa delle basse risoluzione e dei conseguenti limitati "margini di manovra", è un problema più difficile della portabilità di una GUI realizzata con AWT). In pratica, ora i componenti vengono organizzati in righe (row), possiamo specificare per ognuno di essi le dimensioni preferite, ed essi sono in grado di ridimensionarsi all'occorrenza.

Grafica, suono e videogiochi per cellulare
Per quanto riguarda la grafica, è stato introdotto il supporto per le immagini trasparenti, ed ora è possibile manipolare anche solo parti di un'immagine (con operazioni tipiche di bit-blit, cioè di spostamento di sottoinsiemi di pixel da un buffer ad un altro). Inoltre sono state rese disponibili nuove classi per l'implementazione di giochi con animazioni bidimensionali: la classe Sprite e la classe TiledLayer. In pratica, queste due classi sono tutto ciò che ci serve per implementare PacMan in MIDP: la prima è un'immagine grafica sovrapponibile ad uno sfondo, immagine per la quale il runtime fornisce supporto per il rilevamento delle "collisioni" sia con lo sfondo che con altri sprite (immagino che questi concetti abbiano evocato piacevoli ricordi di gioventù nei lettori che hanno avuto il primo computer all'epoca del Commodore 64). La seconda invece serve per realizzare lo sfondo: essa è una griglia di celle tutte della stessa dimensione, nelle quali possiamo inserire immagini, anche animate. Questa impostazione ci consente di costruire sfondi anche estesi ben oltre lo spazio fisico del display risparmiando memoria: anzichè dover "bitmappare" tutta la superficie è sufficiente assemblare tra loro mattoni elementari. Certo, questa impostazione porterà a schemi un po' ripetitivi, come quelli dei primi videogiochi, e questo potrebbe far storcere il naso in un mondo ormai abituato ai prodigi tecnologici delle PlayStation; ma, diamine, qui stiamo parlando di telefonini!
Per completare la panoramica relativa ai giochi, è previsto anche il supporto audio, per le inevitabili musichette che dovranno accompagnare il nostro giochino. MIDP 2 richiede il supporto per la generazione di musica a "toni", ed opzionalmente prevede il rendering di suoni campionati (con qualità almeno di 8KHz di frequenza di sampling a 8 bit per campione) o di sequenze MIDI per i cellulari che includono un sintetizzatore musicale più complesso.

Monty, una macchina virtuale J2ME più veloce
Con l'avvento dei telefoni cellulari della prossima generazione, avremo a che fare con dispositivi in grado di gestire reti a 2MB al secondo e che faranno girare complesse applicazioni di e-commerce, multimediali e videogiochi. Per tutti questi motivi sarà necessario avere macchine virtuali veloci e potenti, però sempre con una grande attenzione al contenimento dei consumi, cruciale per un telefonino, ed alle limitazioni fisiche di dimensioni e peso che certamente non consentiranno l'integrazione di microprocessori potenti come quelli dei PC di punta.
Il progetto Monty consiste nelle specifiche architetturali per una nuova virtual machine per la piattaforma CLDC (Connected Limited Device Configuration), su cui si basa, tra l'altro, il profilo MIDP; in pratica Monty affiancherà, come reference implementation, l'attuale KVM. L'obiettivo è quello di ottenere, a parità di risorse hardware, una macchina virtuale 10 volte più veloce della KVM. Questo valore in realtà si riferisce a benchmark eseguiti su ambiente Intel P4 / Windows 2000, che non appare molto realistico come ambito di riferimento per J2ME; molto più significativi appaiono i benchmark eseguti su processore StrongARM, quello dell'iPaq tanto per intenderci, che ci parlano di uno speed-up pari a 7.
Le caratteristiche salienti di Monty sono: un'architettura a 32 bit, un garbage collector "preciso" (traduzione non felice di "precise", che sta ad indicare un garbage collector in grado di riconoscere con sicurezza gli oggetti da cancellare; in contrasto con i garbage collector della prima generazione di Java, che per motivi di efficienza consideravano ogni parola di 32 bit, quindi anche un int o un float, come un probabile puntatore ad un oggetto, e che quindi non erano in grado di rimuovere sempre tutta la "spazzatura"), nessuna limitazione sul numero di classi caricabili e sulla dimensione dello heap, 1MB di memoria come target (valore che oggi potrebbe sembrare eccessivo, ma non lo sarà tra qualche anno, appunto quando usciranno i telefonini di Next Generation). Inoltre, vari accorgimenti permettono a Monty di risparmiare anche il 50% della memoria necessaria per allocare un oggetto.
Infine, per ottenere la velocità che si prefigge di raggiungere, Monty include la capacità di tradurre "just in time" il bytecode Java in codice nativo, ma con approcci più parchi di memoria rispetto alle analoghe soluzioni utilizzate in ambiente Java 2 Standard Edition.

Un nuovo profilo: Gaming Profile (JSR 134)
Alla JavaOne è stato presentato un nuovo profilo per Java 2 Micro Edition. Pur non avendo niente a che fare con MIDP, ci sembra interessante citarlo anche per differenziarlo dal supporto per il gaming che è stato introdotto con MIDP 2.0.
Il Gaming Profile ha come target console per videogiochi di alto livello, cioé dispositivi con almeno 32-64MB di RAM e grafica 3D accelerata (non a caso il gruppo di esperti del JSR 134 include nomi come Sony Online). Nonostante questi dispositivi siano assimilabili a computer tradizionali, si è pensato che il profilo Java 2 Standard Edition sia comunque troppo pesante (dal momento che contiene anche API assolutamente inutili in questo ambiente), anche considerando che in questa fascia di dispositivi si tende a "spremere" l'hardware il più possibile senza spazio per sprechi di memoria o di potenza di calcolo.
Il gruppo di lavoro che lavora al Gaming Profile è il JSR 134, e l'attenzione è stata focalizzata su queste aree:

- modellazione e rendering 3D
- modellazione di oggetti fisici
- animazione a caratteri
- rendering 2D
- gestione della rete
- gestione multimedia (audio e video)
- gestione di periferiche di controllo (joystick, cloche, eccetera)

I requisiti fondamentali sono le classi base di java.lang, java.util, java.io, java.net e java.awt, con in aggiunta le API per il rendering 2D e 3D. Dal JDK 1.4 vengono presi a prestito il supporto per i timer e per la gestione fisica della memoria.
Quanto sarà importante questo profilo? È ben difficile dirlo, specialmente in un momento in cui l'attenzione è focalizzata sullo scontro in corso tra i "giganti" del settore (Sony con la PlayStation 2, Nintendo con il GameCube e Microsoft con la X-Box), tuttavia il mercato dei videogiochi, che negli USA sostiene un giro d'affari pari alla bellezza di 9,4 miliardi di dollari (più importante di quello dei film, della televisione e dei libri) sicuramente costituisce un serio interesse per Sun, anche considerando l'attuale congiuntura che vede i produttori di hardware impegnati a differenziare il più possibile il proprio mercato. Staremo quindi a vedere. La JSR 134 sarà disponibile per una public review per la fine dell'anno in corso (2002) e quindi ci attendiamo le prime implementazioni per l'anno prossimo.

Riferimenti
Le slides utilizzate nelle sessioni della JavaOne sono disponibili sul sito java.sun.com, previa registrazione (gratuita) alla Java Developer's Connection. La documentazione viene distribuita sotto forma di file PDF che hanno come nome il numero di codice a quattro cifre della sessione. Alcuni riferimenti relativi agli argomenti trattati sono:

- 2995: JSR-118 (MIDP v2.0) session 1
- 3006: JSR-118 (MIDP v2.0) session 2
- 2133: Project code-named Monty - a High Performance Java Virtual Machine for
           Small Devices
- 1243: Java Game Profile Update