James Gosling, padre di Java, depreca Steve Jobs

Steve Jobs con la sua ultima dichiarazione è sceso a volto scoperto nel dibattito circa la decisione di Apple di deprecare Java sui computer Mac, e la sua elegante spiegazione è stata immediatamente deprecata da James Gosling. Chi è? Semplicemente il fondatore di Java, una sorta di icona ascetica per molti sviluppatori, un uomo il cui curriculum farebbe impallidire qualsiasi sviluppatore veterano.

Come vi avevamo già segnalato, la storia è cominciata da una email di uno sviluppatore indirizzata a Steve Jobs. Nella email si chiedeva con un po’ di preoccupazione quali fossero i reali piani di Cupertino per la tecnologia di sviluppo più famosa del pianeta, e il CEO non ha perso tempo rispondendo:

Sun (ora Oracle) offre Java per tutte le piattaforme. Loro hanno un proprio calendario per gli aggiornamenti della piattaforma e questo è quasi sempre diverso dal nostro: conseguentemente il Java che noi forniamo ha sempre una versione di ritardo. Questa non deve essere la maniera corretta di andare avanti.

La risposta di James Gosling è arrivata immediatamente tramite un post sul suo blog: “It simply isn’t true” (“Semplicemente non è vero”) ha esordito. Dopo il salto vi riporto la traduzione integrale della risposta.

Semplicemente non è vero che “Sun (ora Oracle) offre Java per tutte le piattaforme”. IBM offre Java per le piattaforme IBM, HP per quelle HP, anche i sistemi Azul fanno lo stesso per la loro JVM (bisogna ammettere, queste partono tutte dal codice di Snorcle – del resto lo fa anche Apple). All’inizio, Microsoft forniva Java per Windows – ma Sun prese il controllo quando Microsoft violò il contratto e rese il codice Java scritto su Windows impossibile da eseguire su altri sistemi. Sun forniva anche la VM per Linux perché non c’era nessun altro che lo facesse. In tutti gli altri casi, i proprietari della piattaforma vollero realizzare il porting da sé in modo che potessero impegnarsi a fondo nell’impresa, e perché conoscevano la propria piattaforma meglio di chiunque altro.

Apple fece lo stesso: durante i primi giorni furono molto insistenti nello sviluppare il porting da sé. Ci misero un sacco di energie. Fecero un ottimo lavoro. Ma dopo, tirarono fuori OS X e Apple riuscì a convincere gli sviluppatori ad utilizzare il loro ambiente di sviluppo non-portabile/proprietario, la tendenza di mostro-controllore di Apple venne fuori e dedicarono sempre meno energie in Java. Non aiutò nemmeno i port iniziali che erano stati pesantemente personalizzati – molto più che di quanto gli servisse. Questo rese gli aggiornamenti alla versioni successive molto difficili, e per un po’ troppo tempo la JVM di Apple rimase indietro a tutte le altre piattaforme. Ma finalmente si diedero una regolata e il loro piano di aggiornamento di JVM fu reso più efficiente e sono andati avanti molto bene in questi anni.

Non di meno, ci furono ricorrenti discussioni su chi avrebbe dovuto caricarsi del fardello, se Sun o la community. C’erano un sacco di ostacoli. Uno era che molti siti web Apple (MobileMe, iTunes, App Store) erano applicazioni Java ed il non poter fare Garanzia di Qualità autonomamente li rendeva nervosi. Il punto divenne un po’ discutibile perché Apple aveva finito con l’utilizzare un sacco di hardware di Sun (yes!). Ma il più grande ostacolo era il loro uso di API segrete. Yes, OS X ha tonnellate di API segrete. Proprio come quelle che aveva Microsoft e che hanno contribuito ai loro problemi con l’antitrust. La grande area di utilizzo (della quale ero a conoscenza) era il rendering grafico.

Un tema particolarmente paradossale era quello del “rendering scalettato contro anti-scalettato“: il processo grafico di Apple è ben progettato: fanno antialiasing dappertutto magnificamente. Le specifiche grafiche di Java hanno delle accurate funzioni per l’utilizzo di tale effetto. Il codice che serve per ottenere questo stile di renderizzazione è semplice da scrivere. Sfortunatamente, le vecchie piattaforme Microsoft supportano solo il rendering scalettato, e alcune (molto rare) applicazioni necessitavano di artefatti di rendering quando la modalità antialias viene attivata. Queste applicazioni sono scritte male rispetto alle specifiche, e molti autori le hanno riscritte in modo da farle funzionare in entrambi i casi. Un solo sviluppatore, in particolare, ha reagito con un “fuck you” a questo problema costringendo Apple ad implementare il rendering scalettato – che loro hanno tenuto segreto perché è stata una cosa orribile con la quale fare i conti. Il “solo sviluppatore”? Oracle, ovviamente…

Avete colto l’ironia? vero?

[Via NightHacks]