Quando parliamo di Sun e di Oracle difficilmente possiamo pensare all’eredità della prima presa in consegna dalla seconda: troppo diverse le finalità e le azioni, con l’azienda di Redwood votata a batter cassa cercando di capitalizzare il più possibile il portfolio di strumenti e proprietà intellettuali della ex casa di Santa Clara.
Una recente notizia sembra, però, accomunarle nuovamente, all’insegna di un ritorno al passato in quella che all’apparenza si prospetta come una difesa di uno dei gioielli di famiglia, il linguaggio di programmazione Java che, nel bene e nel male, tanto ha dato all’informatica e alle giovani leve.
In estrema sintesi, Oracle rivendica l’infrazione di proprietà intellettuali (brevetti e copyright) che riguardano Java da parte di Google, che per il suo Android ha realizzato una virtual machine (chiamata Dalvik) diversa da quella standard, e soprattutto che fa uso di una libreria alternativa (che fa parte di Harmony, progetto di Apache Foundation volto a realizzare una piattaforma Java open source, ma con licenza Apache appunto), già a sua volta presa di mira da Sun.
C’è da dire che Sun è stata sempre molto gelosa del suo progetto, su cui ha investito enormi risorse e che ha difeso già altre volte, dimostrando un attaccamento a dir poco viscerale, volto a fornire al mondo intero una sola, omogenea, soluzione che vi facesse capo. Da questo punto di vista possiamo affermare che la similitudine con Oracle risulta evidente, e l’eredità raccolta.
A mio avviso da qui le due strade divergono, perché troppe sono le differenze a livello di politica aziendale, come ho sottolineato all’inizio dell’articolo. Onestamente non credo nemmeno nella “difesa della patria”, ma vedo l’azione di Oracle come l’n-esimo tentativo volto a monetizzare le tante risorse made in Sun.
Ciò fermo restando che ha tutto il diritto di difendere, ed eventualmente chiedere compensi, per ciò che le appartiene. Se Google ha sbagliato (e non sarebbe nemmeno la prima volta, ormai), deve giustamente pagare, com’è toccato a Microsoft quando anche lei ha messo le mani su Java.
La situazione, infatti, è praticamente la stessa, come abbiamo già avuto modo di affrontare nei commenti di un articolo su IE9 di Raffaele Fanizzi. Anche Microsoft realizzò una virtual machine in parte diversa da quella di Sun (più aggiornata, alla versione 2 del linguaggio, mentre la MSJVM era ferma alla 1.1), in quanto mancava il supporto alle JNI, a cui la casa di Redmond aveva preferito una sua estensione chiamata J/Direct (per invocare direttamente API Win32).
Nuovamente, il vero pomo della discordia fu l’adozione di una libreria diversa da quella ufficiale. Microsoft non credeva nella Java Foundation Class, che riteneva troppo pesante, preferendo affidarsi alle consolidate (e già presenti nel sistema) Win32, facendo di Java sostanzialmente un linguaggio come tutti gli altri per la piattaforma Windows.
Si potrebbe pensare che le finalità di Microsoft e Google siano diverse. Alla prima, infatti, si potrebbe rinfacciare la classica politica di Embrace, Extend, Extinguish (EEE) con la quale ormai viene etichettata ogni sua azione. Per la seconda, che male potrebbe mai fare una virtual machine e una libreria diverse, visto che il raggio d’azione è ristretto a una porzione del mondo mobile?
In realtà non cambia poi molto: entrambe le aziende hanno personalizzato Java per le proprie esigenze, col risultato che i prodotti per essi realizzati non possono girare sulla piattaforma standard, che poi è il motivo (“write once, run everywere“) per cui Sun l’ha sempre difesa con le unghie e coi denti.
Le conseguenze di quest’arroccamento sono state che Microsoft ha abbandonato Java, realizzando .NET e C# che rappresentano, di fatto, la sua risposta e lo strumento personalizzato e al contempo flessibile che le serviva.
Google può, a questo punto, puntare sull’SDK C++ che ha rilasciato da poco per Android, e che si è affiancato all’originale Java-only, con la speranza che se ne affianchi qualcuno magari basato su Python (linguaggio di primo piano per il colosso di Mountain View) che è sicuramente più semplice e comodo da utilizzare (come abbiamo anche avuto modo di sperimentare qui su Appunti Digitali).
Con Microsoft e Google che si allontanano da Java, il futuro di questo linguaggio non sembra affatto roseo. Chiuso alle personalizzazioni che sono necessarie per far fronte alle necessità di ambiti specifici, lento nelle innovazioni (la versione 7 del linguaggio “arriverà quando sarà pronta“), e presta il fianco ai linguaggi cosiddetti “dinamici” che offrono una produttività ben più elevata.
Aggiungiamo anche il fatto che, nella ricorsa alle innovazioni, Java è finito per copiare malamente le soluzioni altrui, snaturando quello che era un linguaggio che, di fatto, nelle prime incarnazioni era semplice da leggere e facile da apprendere, caratteristiche queste che gli hanno permesso di scalzare Pascal e C nell’ambito didattico, forte anche di una ricca libreria standard.
Con queste premesse, se Oracle non troverà il modo di rilanciarlo, campando soltanto di rendita come si suol dire, le prospettive non possono che essere funeree. Ciò non vuol dire che dall’oggi al domani troveremo il suo cadavere galleggiare sul letto di un fiume, ma similmente al C rimarrà relegato sempre più in settori di nicchia, grazie alla base legacy di applicazioni (in particolare di classe enterprise) installate.
Poi, come si sa, morto un re se ne farà un altro (penso a C#, che ha tutte le carte in regola per prenderne il posto; non credo né nel C++ né tanto meno nel ben più complesso C++0x gli succederà fra qualche anno), anche se oggi assistiamo a un fiorire di nuovi linguaggi e, come dicevo prima, sempre più piede prenderanno quelli “dinamici” (con Python che raccoglie sempre più consensi; vedi Google e YouTube in particolare).
