Nonostante il Macintosh si diffonda sempre di più anche fra gli sviluppatori, molti di loro avranno incontrato alcune difficoltà per l‘utilizzo di Java 6 sui computer “della Mela”. In questo articolo presentiamo una promettente soluzione open source a tali problemi.
Introduzione
Ho sempre avuto una particolare ammirazione per i computer made by Apple, sin da quando comprai il mio primo vero personal computer, grosso modo nel 1985. Mentre all’epoca dovevo lavorare con il terminale alfanumerico (essendo Windows 1.0 niente di più di un giocattolo bacato), i miei amici felici possessori dei primi Macintosh potevano già godersi un’interfaccia grafica funzionale con tanto di mouse.
Negli anni successivi le cose migliorarono per il mondo dei PC, ma il divario è rimasto sostanziale – specialmente per quanto riguarda la percentuale di tempo sprecata per questioni amministrative in funzione del tempo lavorato totale; il mio tipico benchmark sull’usabilità di un sistema operativo – in questo caso un portatile – consiste nello stampare un documento al volo su una stampante di rete di un cliente da configurare ad hoc.
Poi persi un po’ di vista il mondo Apple, un po’ perch� pensavo fosse poco adatto al mondo dello sviluppo software, un po’ per via della crisi della multinazionale che allo scoccare del secolo pareva in grande difficoltà (successivamente superata). Intorno al 2003 mi ero imposto di passare a Linux, sistema che conoscevo sin dagli esordi del 1993, ma alla resa dei conti il passaggio si dimostrò improponibile per quello che dovevo fare sul mio laptop, per cui l’anno successivo mi ero quasi arreso all’inesorabilità del sistema operativo di Redmond.
Tuttavia, nei mesi seguenti, una serie di colleghi, alcuni dei quali dell’engineering di Sun, mi convinsero che i portatili di Cupertino erano proprio quello che faceva per me. Sperimentai quindi il MacMini ed un piccolo iBook nel 2005, per poi passare al MacBook Pro l’anno successivo, caldo caldo di switch all’architettura Intel. Finalmente potevo godermi “il miglior sistema operativo per uno sviluppatore Java”! Il perfetto match tra Java e Mac OS X sembrava d’altronde testimoniato dalla grandissima quantità di portatili Apple che si potevano (e si possono tutt’ora) notare alle grandi conferenze Java, come JavaOne o JavaPolis.
A due anni di distanza, purtroppo, la realtà non è così rosea. Mac OS X rimane di gran lunga il miglior sistema operativo desktop in quanto a usabilità in generale (passa alla grande il “test della stampante”), ma non è così brillante come speravo. Però il dato più grave è che, decisamente, Mac OS X è il peggior sistema operativo per sviluppare con Java, almeno se si hanno certe esigenze.
Java e Mac OS X
Nonostante Apple abbia spesso pubblicizzato il proprio sistema operativo come “il miglior ambiente per Java” dimostrando inizialmente molta buona volontà per migliorare l’integrazione tra i due mondi, nel corso degli anni ha decisamente cambiato atteggiamento nei confronti della tecnologia di Sun. Alle origini, il JDK 1.1 e 1.2 fu portato su Mac OS 8 e 9 direttamente da Sun [7] – peraltro con risultati assai scadenti, specialmente per quanto riguarda il look and feel, punto su cui tutti gli “applisti” sono molto sensibili.
Con l’avvento del System X, Apple ha preso su di s� la responsabilità del porting (a partire dal JDK 1.3), per la verità, facendo inizialmente un eccellente lavoro. Non solo Mac OS X era l’unico sistema operativo ad essere venduto con Java già installato e configurato (Windows, si sa, ha boicottato Java sin dal 1998 e per il bundling in alcune distribuzioni di Linux è stato necessario attendere quest’anno), ma Apple sviluppò anche un’integrazione esplicita con il desktop grazie a una speciale estensione del suo concetto di “application bundle”.
In pratica, in Mac OS X un’applicazione è in realtà una cartella che può avere al suo interno una struttura di sottocartelle complessa a piacere (mentre appare comunque come singola icona, per la quale il doppio click significa “lancia l’applicazione” anzich� “apri la cartella”). Questo permette non solo di organizzarsi in tutta libertà il layout delle librerie e delle risorse private dell’applicazione, ma anche di integrare uno speciale lanciatore (chiamato JavaApplicationStub) che si preoccupa di cercare ed eseguire la macchina virtuale. Lo stub è in grado di leggere un insieme di parametri di configurazione che specificano quale versione di Java è richiesta, le opzioni sulla riga di comando come la dimensione di memoria, eccetera (tutte feature che, su Linux e Windows, necessitano di un prodotto apposito per creare un installatore e un launcher). Specifiche opzioni -Xdock:name e -Xdock:icon consentono di controllare come l’applicazione appare nel dock del sistema operativo, mentre altre estensioni del runtime permettono di implemetare i menù caratteristici di Mac OS X (che, per esempio, hanno come prima voce un menù di sistema, eccetera); ma forse il dato più importante è che il bundling di Java in una serie di posizioni predefinite (/System/Library/Frameworks/JavaVM.framework/Versions), insieme a tutte le altre caratteristiche appena descritte, permette di rilasciare la propria applicazione in tutta tranquillità senza bisogno di ridistribuire il runtime.
Alcuni problemi
Tutto idilliaco? Non proprio. Si sa che gli applisti sono molto pignoli sull’estetica (un utente medio è in grado di percepire subito, per esempio, che i bottoni non sono spaziati con il giusto numero di pixel o che non vengono rispettati alcuni standard delle Human Interaction Guidelines): il look & feel di Java su Mac OS X (Aqua) ha alcune sbavature. Trattasi tuttavia di peccato veniale, a cui oltretutto si può rimediare in modo eccellente usando Quaqua [3], un prodotto open source che, almeno per le parti completate, implementa Aqua con una precisione svizzera (come il suo autore Werner Randelshofer).
No, non è il look&feel il problema. Il vero problema è che Apple è sempre più lenta nel fornire gli aggiornamenti di Java sul proprio sistema operativo. Già all’epoca di Java 5 fu necessario attendere circa un anno, a partire dalla data di rilascio di Sun per Windows e Linux. Fino all’estate del 2006, tuttavia, c’erano molte ragioni per essere ottimisti: infatti Apple stava rilasciando le beta di Java 6 con poche settimane di ritardo rispetto a Sun, lasciando intendere di potersi presentare in orario al momento del rilascio finale. Tuttavia, la sequenza di rilasci terminò inaspettatamente nel settembre del 2006. Per mesi non ci furono più notizie; e a questo proposito va detto che una caratteristica piuttosto seccante di Apple è che non dà mai informazioni sulla pianificazione di qualsiasi suo prodotto, fatta eccezione per gli annunci ad effetto di Steve Jobs durante le famose keynotes. Chi è membro dell’Apple Developer Connection, un club a pagamento, ha qualche informazione in più che però non può rilasciare a terzi: questo, ovviamente, implica che se siete un architetto e avete qualche informazione sui piani di rilascio, non la potete utilizzare per stabilire una strategia di progetto per un cliente (a meno che non sia membro pure lui di ADC). Una politica assurda nel XXI secolo, visto che la comunità ormai è abituata ai modi di fare dell’open source, per cui non solo tutto è aperto, ma è anche annunciato “in tempo reale”; e se ci sono ritardi, sono gli inevitabili ritardi di sviluppo dovuti ad imprevisti.
In ogni caso, dopo qualche mese di silenzio, la comunità di sviluppatori iniziò a supporre che Java 6 sarebbe stato rilasciato con Leopard (alias Mac OS X 10.5), uno degli aggiornamenti più importanti del sistema operativo di Apple. La data agognata era Maggio del 2007. Con solo un paio di mesi in anticipo, Apple annunciò di aver spostato il rilascio di Leopard di qualche mese, ovviamente senza dare altre informazioni. La comunità, con preoccupazioni sempre maggiori, intuì che Java 6 sarebbe arrivato con lo stesso ritardo (che a questo punto sarebbe stato di circa 6-7 mesi rispetto alla schedulazione di Sun). Quando Leopard finalmente apparve alla fine del 2007, la “sorpresa”: niente Java 6 (e, addirittura, le beta precedenti furono ritirate dal sito). È la classica situazione in cui la gente inizia a dare segni di panico: nessuno ti dà notizie sul futuro, quindi gli ottimisti pensano che “no news is good news”, mentre i pessimisti (e i realisti) si preoccupano perch� non si sentono in grado di pianificare il proprio lavoro. A peggiorare la situazione, una famosa intervista di Steve Jobs che fece riferimento a Java come “una tecnologia da palla al piede” [8]: frase da riferirsi in realtà nel contesto dei telefonini (Jobs annunciava la mancanza di supporto Java sull’iPhone), ma che lasciava intendere un deciso peggioramento nei rapporti con Sun. Peggioramento testimoniato anche da altri piccoli episodi e con un po’ di reciprocità da parte di alcuni speaker di Sun, come Gosling in persona (che ha espresso più volte la propria frustrazione per l’atteggiamento di Apple, definita esplicitamente come “partner difficile” [5]; comicamente, sul sito di Apple compare ancora una vecchia intervista a Gosling [6], citato tra i testimonial scientifici di Mac OS X quando ancora il clima era sereno.
Per farla breve: Java 6 alla fine è stato rilasciato da Apple circa un mese fa; ma con una sgradita sorpresa: gira solo su macchine Intel (nonostante ci sia in circolazione ancora una maggioranza di macchine basate sui processori G5, non ancora obsolete) e, soprattutto, solo su processori a 64 bit. Chiunque abbia comprato un Mac entro il primo anno dall’introduzione della nuova architettura Intel si trova tagliato fuori. Vorrei sottolineare come il problema non sia esclusivamente legato alla necessità, da parte di uno sviluppatore, di dover spendere soldi prima del previsto per rinnovare il suo parco macchine: la cosa più grave è che se volete distribuire un’applicazione basata su Java 6 state riducendo il possibile target di utenti Mac ai soli possessori di hardware più giovane di due anni. Può essere un vincolo inaccettabile che rende assolutamente non competitiva la vostra applicazione in confronto ad altre realizzate con tecnologie concorrenti.
Qualcuno a questo punto si sarà chiesto: ma perch� dovrei usare Java 6? Effettivamente non si contano le flame war scoppiate su questo punto. Non è mia intenzione dilungarmi con noiose serie di feature: basti sapere che Java 6 non solo è più veloce, ma ha nuove API per una migliore integrazione con il desktop, come pure una serie di bug fix piuttosto importanti. Ma mi è capitato di leggere la mail di uno sviluppatore piuttosto contrariato che faceva presente di avere necessità di usare alcune nuove feature di Java 6 anche su un progetto di tipo server side. Io preferisco sintetizzare in questo modo: è ovvio che saltare subito all’ultima release appena uscita di una tecnologia non è un comportamento virtuoso, tuttavia qui stiamo parlando di un prodotto ormai stabile (rilasciato da più di un anno) e di un ritardo notevole (senza contare la mancanza di supporto su macchine che non possiamo ancora considerare vecchie). Si tratta di una cosa intollerabile.
Dunque? Dunque, la situazione per chi vuole fare deployment su Mac OS X può presentare problemi ad oggi non risolvibili facilmente: certo, tra 2-3 anni probabilmente il parco macchine di Apple conterà una buona percentuale di Intel 64 bit, ma nel frattempo bisogna arrangiarsi. E, ricordando che Java 7 uscirà all’inizio dell’anno prossimo, è ovvio pensare che il problema si ripeterà di nuovo.
SoyLatte: porting per Mac OS X di una JVM
Con incrementata insofferenza nei confronti di Apple, sempre più sviluppatori hanno iniziato a chiedere insistentemente un intervento di Sun; in particolare, le si è chiesto di fornire una propria versione del runtime Java anche per Mac OS X, al pari di quanto produce per Linux e Windows (oltre ovviamente a Solaris). Pare una causa persa, anche per alcune mezze dichiarazioni che hanno fatto ipotizzare l’esistenza di un accordo con Apple che lascia a quest’ultima l’esclusiva (in questi mesi Sun sta anche trattando con Apple l’apertura di iPhone a Java e personalmente credo che questo forzi Sun a tenere un atteggiamento diplomatico; va detto, per amor di cronaca, che non ci sono riferimenti ufficiali su questi dettagli e ci si può basare solo su voci e sensazioni).
Dal mio punto di vista, questa è una richiesta non completamente opportuna. La filosofia di Java, chiara sin dall’inizio, era che ciascun produttore di sistema operativo avrebbe dovuto provvedere ai propri prodotti. Dopotutto Sun si prende cura si Solaris, come pure IBM e HP in relazione ai propri ambienti operativi. Windows e Linux, prese in carico da Sun, sono due eccezioni dovute sia al boicottaggio da parte di Microsoft, che all’iniziale diffidenza della comunità Linux (fortunatamente ormai quasi del tutto superata). Ma è specialmente considerando che Java è open source dalla fine del 2006 si dovrebbe capire, secondo me, che non è a Sun che bisogna guardare: semmai alla comunità.
E la comunità si è mossa, anche se con un certo understatement. In modo del tutto imprevisto, a Novembre 2007, Landon Fuller ha annunciato [4] l’esistenza di un primo porting non prodotto da Apple di una virtual machine Java per Mac OS X. Un annuncio di portata storica. Landon ha lavorato sul porting di Java per FreeBSD (l’ambiente open più vicino al kernel di Mac OS X), dovendo in particolar modo concentrarsi su HotSpot, il traduttore dinamico di bytecode in codice nativo, che ha per sua natura una relazione molto intima con il sistema operativo sottostante. Tuttavia, a Landon sono bastate tre settimane di lavoro – almeno secondo la versione più diffusa – e l’unico punto delicato è stato l’allineamento dei dati multi-byte in memoria.
Installazione di SoyLatte
Su questo c’è veramente poco da dire: SoyLatte si può scaricare in forma binaria (sotto forma di tar compresso) [1]. Basta scompattarlo in una qualsiasi posizione del disco; personalmente preferisco metterlo in compagnia delle VM di Apple, sotto
/System/Library/Frameworks/JavaVM.framework/Versions/soylatte16-i386-1.0.2
Per usarlo, dovete far sì che la vostra applicazione lanci esplicitamente la sua virtual machine (non c’è supporto, attualmente, da parte del JavaApplicationStub).
Usare SoyLatte con Eclipse e Netbeans
A questo punto, è possibile configurare SoyLatte in modo che NetBeans ed Eclipse lo usino come piattaforma di riferimento. Questo vi permetterà di sviluppare con Java 6 anche se non potete installare la VM di Apple perch� il vostro hardware non lo permette (prima che vi entusiasmate troppo, leggete tutto l’articolo: purtroppo ci sono dei problemi aperti… e non da poco).
Sotto NetBeans, basta selezionare il menu “Tools / Java Platforms” e premere il bottone Add Platform; poi selezionate la directory dove avete espanso SoyLatte. NetBeans effettuerà la scansione delle librerie automaticamente; non vi vimane che selezionare Java 6 come piattaforma per il vostro progetto.
Con Eclipse, aprite il menù delle preferenze (quello sotto il menù di sistema) e selezionate il pannello Java / Installed JREs. Premete il tasto “Add…” e procedete come prima, selezionando la cartella di installazione di SoyLatte. Dovete selezionare “Mac OS VM” nel campo “JRE Type”, ma questo potrebbe portare a qualche problema con gli script di ant. SoyLatte andrebbe installato come “Standard VM”, però Eclipse erroneamente pensa che non ci sia questa possibilità su una macchina Mac OS X. Se “Mac OS VM” vi crea problemi, esiste una patch per Eclipse che permette l’installazione normale [2].
Ricordatevi poi di selezionale il compilatore per la compliance alla versione 6.0.
Non sono in grado di garantire che queste configurazioni possano essere usate durante il lavoro di tutti i giorni senza alcun problema (in particolare per Eclipse, poich� non ne faccio un uso estensivo da parecchio tempo), ma in rete si trova qualche resoconto incoraggiante.
Problemi aperti
Al momento di scrivere, l’ultima versione di SoyLatte è la 1.0.2, corrispondente alla 1.6.0_03. Alcuni inconvenienti correlati alla stabilità sono stati risolti velocemente e ci sono stati già alcuni resoconti di test eseguiti con successo in relazione al deployment di applicazioni server anche complesse. Per esempio, lo screenshot qui sotto è relativo a blueMarine, un’applicazione piuttosto complessa che sto sviluppando.
Tutto liscio? No, purtroppo, ci sono due problemi eclatanti:
- Il primo è di tipo legale. SoyLatte deriva dal port di FreeBSD, che a sua volta (essendo datato) non è ancora una derivazione di OpenJDK, con licenza GPL + ClassPath Exception, ma è ancora distribuito con una vecchia licenza non open di Sun, la Java Research License (JRL) che, tra l’altro, impedisce la redistribuzione di SoyLatte con una vostra applicazione. Tuttavia, Landon ha già dato ampie garanzie a proposito: grazie alla sua collaborazione con il gruppo di lavoro di OpenJDK, in tempi brevi il porting dovrebbe essere rilocato su OpenJDK, diventando così open a tutti gli effetti con la licenza GPL + CPE.
- Il secondo è un grosso problema tecnico. Essendo un porting di FreeBSD, SoyLatte utilizza X11, il noto ambiente grafico di Unix, per accedere al video. Questa cosa funziona su Mac OS X, che ha supporto per X11, ma con gravi ripercussioni sull’esperienza utente. Non solo nei dettagli minori (icone e menù non standard), ma anche nel look & feel (niente Aqua) e,- cosa ancora più grave, nei binding di tastiera; per cui, il classico cut&paste è CTRL + C / CTRL + V al posto di Mela + C / Mela + V e vi assicuro che per un utente Apple questo è un piccolo dramma (tale da vanificare il successo di qualsiasi applicazione vogliate distribuire). Insomma, per ora tutto è contro di voi se volete sfondare nel mondo del desktop Apple con un prodotto Java…
La comunità è ben conscia della gravità del secondo problema e c’è una volontà precisa di risolverlo. Tuttavia, questo richiederà un lavoro assolutamente non banale, e cioè il porting di tutti i “binding X11” in codice nativo verso “Cocoa”, che è la API grafica di Mac OS X. Purtroppo in pochi conoscono Cocoa (le tecnologie Apple sono tipicamente una nicchia) e non è facile prevedere quanto tempo sarà necessario per completare questa attività.
Fortunatamente, non bisognerà però spendere troppo tempo nei dettagli grafici: Werner Randelshofer ha rilasciato delle release di Quaqua compatibili con SoyLatte (che ho usato proprio per lo screenshot di blueMarine poco sopra). Fatta salva l’accettazione di una finestra principale in stile X11, con Quaqua quasi tutti i widget di Mac OS X già compaiono con il look and feel opportuno. D’altro canto i font non sono quelli di Mac OS X e conferiscono un aspetto un po’ “alieno” alla GUI.
Rimangono ancora dei problemi minori – ad esempio, alcuni benchmark di velocità su SoyLatte mi hanno restituito numeri inferiori alla performance di Java 6 su Windows e Linux (ovviamente a parità di hardware: il test è stato eseguito sul mio MacBook Pro in multi-boot nativo), ma questo pare abbastanza scontato: su un nuovo porting, prima ci si concentra sulla stabilità, che è già molto buona, e il tuning arriva in un secondo tempo.
La mia opinione finale è che si tratta di un prodotto in qualche modo rivoluzionario. Una volta risolti i problemi di licenza, quindi senza dover attendere troppo tempo, SoyLatte sarà già utilizzabile per deployment sul server. Per avere un porting ottimale sul desktop, con tutti gli annessi e connessi, bisognerà attendere almeno un anno, secondo me. Ma questo vuol dire che, probabilmente, a partire da Java 7 avremo finalmente un porting open e disponibile in contemporanea con le versioni per gli altri sistemi operativi. Certo, non sarebbe male se Apple dimostrasse almeno un centesimo dell’attenzione al mondo “open” che hanno altre aziende, come Sun, e contribuisse almeno in parte allo sforzo.
Riferimenti
[1] http://landonf.bikemonkey.org/static/soylatte/
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=211648
[3] http://www.randelshofer.ch/quaqua/index.html
[4] http://landonf.bikemonkey.org/code/macosx/MacOS_Java_16_Developer_Preview_1.20071120.html
[5] http://weblogs.java.net/blog/editors/archives/2008/01/congratulations_1.html
[6] http://www.apple.com/science/profiles/gosling/
[7] http://docs.info.apple.com/article.html?artnum=120209
[8] http://jdj.sys-con.com/read/345511.htm