Java su iPhone: qualche riflessione


La notizia sta facendo il giro del mondo: Sun Microsystems ha annunciato che sta lavorando ad un porting della Java Virtual Machine ed in particolare ad una implementazione di Java Micro Edition per l’iPhone di Apple. L’annuncio arriva a 24 ore dal rilascio dall’SDK ufficiale, conditio sine qua non per poter intraprendere lo sviluppo di applicazioni con la benedizione di Apple.

Qualcuno ha anche ricordato che all’indomani della presentazione dell’iPhone Sun auspicò che il nuovo device fosse dotato di runtime Java. Auspicio completamente ignorato da Apple. Ora che c’è l’SDK, Mamma Sun deve farsi il runtime da sé.

Una sconfitta? Ovvero: Sun deve arrendersi al fatto che Apple snobba JME ed è costretta a farsi il runtime da sé? Direi di no. Qualche riflessione:

  • Partiamo da lontano. Gli sviluppatori JME dipendono inevitabilmente da due componenti: IDE e emulatori, che comprendono toolchain e librerie. Nella fattispecie, Netbeans e il Wireless Toolkit rappresentano la dotazione standard di ogni sviluppatore. È ormai noto che il Wireless Toolkit e, di conseguenza, il Mobility Pack di Netbeans non sono disponibili per Mac. Stessa situazione per emulatori ed SDK dei vari manufacturer. La domanda (polemica) nasce spontanea: perchè Apple avrebbe dovuto supportare JME sull’iPhone, se Sun per prima ha completamente ignorato lo sviluppo JME su Mac OS X?. Il fatto, poi, che l’SDK dell’iPhone sia disponibile solo per Mac OS X la dice lunga sull’atteggiamento di Apple che si potrebbe sintetizzare in questa frase: "nello sviluppo mobile siamo finora stati ignorati da tutti (Sun, Nokia, Motorola, Microsoft [ovvio!]… con la sola eccezione Adobe); ora che il device più desiderato è il nostro, saranno gli altri a doversi muovere verso Mac OS X". Non fa una piega. Chi di spara ferisce, di spada perisce. Occhio per occhio, dente per dente. Insomma, cercate il proverbio che più vi piace.
  • Assodato che l’iPhone è ormai protagonista del mercato dei mobile device e che, dunque, non si può né ignorare né boicottare, chi vuole portarvi la propria tecnologia deve rimboccarsi le maniche e lavorarci sopra. Va da sé che la qualità del porting dovrà essere assoluta e frutto di un lavoro meticoloso, sia per la grafica che per le funzionalità. Sull’iPhone, infatti, non si trovavo le incoerenze di molti sistemi operativi più o meno proprietari che popolano i telefoni di mezzo mondo. L’obiettivo è arduo e la posta in gioco elevata. Da qui la domanda: perchè Sun dovrebbe affidare/delegare ad altri lo sviluppo del runtime JME, rischiando magari che un lavoro di scarsa qualità ne comprometta la credibilità sull’iPhone? Guardando alla babele che esiste nel mondo JME vien proprio da chiedersi se sia stata una buona idea quella di consentire a chiunque di scrivere i runtime Java embedded o se forse non sarebbe stato meglio avere un maggiore convolgimento da parte di Sun. Il cuore ha sempre suggerito di avere un approccio aperto, la storia ha dimostrato che tutti i runtime desktop alternativi sono stati abbandonati in favore di quello Sun, che nel frattempo è stato perfezionato, migliorato, velocizzato. Nel Micro World, invece, gli sviluppatori sono costretti a scrivere una applicazione per ogni diversa famiglia di terminali (come se su desktop si dovesse scrivere una versione per ogni rilascio di CPU da parte di Intel e AMD!) e spesso il risultato non è garantito. Libreria standard ed API opzionali, infatti, mostrano comportamenti imprevedibili, rendendo impossibile realizzare applicazioni che sulla carta appaiono scontate (per le caratteristiche del device, per ciò che dichiara il manufacturer…). Ben venga, dunque, che Sun rilasci una Java Virtual Machine e un runtime Java Micro Edition ufficiali per l’iPhone e che garantisca agli sviluppatori che le applicazioni Java troveranno realizzati in questo device il paradigma "Write Once, Run Everywhere". Mi piace ricordare che il runtime Personal Java sviluppato da Sun per i primissimi iPaq era eccezionale se confrontato con i successivi Jeode o CrEme, che mostravano UI completamente incoerenti rispetto al sistema operativo sottostante. Per parecchio tempo ho preferito usare quella beta di Personal Java piuttosto che usare quegli accrocchi! Poi è arrivata IBM con J9 e le cose sono andate meglio… più o meno. Ma questa è un’altra storia!
  • Così diversi sono i gusti delle persone da una nazione all’altra, da un continente all’altro, da un livello sociale ad un altro, che è praticamente impossibile pensare di progettare e realizzare un oggetto che piace a tutti indistintamente. O, meglio, che tutti sarebbero disposti a comprare. Ecco perchè alla lunga, a mio avviso, l’approccio JME (una piattaforma per qualsiasi device) sarà vincente rispetto a soluzioni chiuse come Windows Mobile, Symbian o lo stesso Android. Quest’ultimo, infatti, non è un semplice runtime ma la somma di sistema operativo, runtime Java sui generis e libreria di componenti. Affronterà Google il porting dei due livelli superiori per l’iPhone? Lo farà per gli smartphone Symbian? Non credo. Ragionamento diverso è stato fatto da Adobe e Microsoft, ben intenzionati a far funzionare Flash e Silverlight ovunque. Allora il risultato è scontato: Android è l’ennesima nuova piattaforma su cui fare porting delle applicazioni e, come tale, un vicolo cieco. Lo stesso vale per lo sviluppo Objective-C su iPhone, ovviamente! Man mano che le piattaforme native o pseudo-native si moltiplicano diventa sempre più difficile per le piccole realtà (piccole ma vivaci e in grado di portare nuove idee) riuscire a supportarle tutte, con il risultato che intere fette di potenziali utenti vengono inesorabile tagliate via. Proviamo a contarle: Windows Mobile, PalmOS, Blackberry, Symbian (divisa in Series 60 e UIQ), iPhone, Android, OpenMoko, MOTOMAGX (di cui però si sa ancora poco della piattaforma nativa). E poi c’è Java, trasversale con parecchia fatica. Ho l’impressione che anzichè migliorare si stia peggiorando: prima tre sistemi (Windows, Symbian con l’aggiunta di Linux e/o PalmOS, il primo adolescente e il secondo agonizzante), oggi sicuramente sei.
  • L’avvento di soluzioni migliori, così mi sembrano l’iPhone e Android per aspetti diversi, sarà inevitabilmente di stimolo anche per gli altri attori di questo mercato. Ad esempio, per Nokia, impegnata più a vendere telefoni che a fare vera innovazione. Ad esempio, per il JCP, accusato da più parti di aver deluso le aspettative in termini di qualià (alla fine i manufacturer fanno come vogliono!) e di velocità (MIDP 3 sembra non arrivare mai…).

In conclusione, penso che sia da apprezzare lo sforzo di Apple per realizzare l’SDK per l’iPhone (tornando indietro sui suoi passi, dunque) e l’entusiasmo di Sun nel realizzare in tempi brevi il runtime JME per questo device. Se entrambi lavoreranno bene sicuramente saranno di esempio per tutti gli altri, facendo in modo che venga voglia di emulare e superare i propri concorrenti per la qualità e non solo il fatturato.

1 pensiero su “Java su iPhone: qualche riflessione

  1. Fabrizio Giudici

    Ciao Stefano.

    Piu’ passa il tempo, piu’ sono negativo con Apple. Purtroppo oggi sono il produttore piu’ chiuso esistente sul mercato, e in questo atteggiamento battono Microsoft alla grande. Ad esempio, tra le clausole per l’uso dell’iPhone SDK c’e’:

    “An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.”

    (http://www.macrumors.com/2008/03/08/iphone-sdk-limitations-multitasking-java-emulators/)

    Ora, si suppone che in Sun l’abbiano certamente letto e magari si potrebbe ipotizzare un accordo speciale tra le due aziende, magari con la clausola che i midlet devono comunque essere registrati attraverso l’Apple Store. Tuttavia, dato il recente scambio di sgarbi tra le due aziende, qualche perplessita’ rimane. Vediamo se Sun risponde all’osservazione.

I commenti sono chiusi.