Visual J#: lo scacco

Microsoft è uscita, di recente, pesantemente sconfitta in un confronto legale con Sun Microsystems.
L’oggetto del contendere era formato, in massima parte, da due temi fondamentali: l’integrazione un po’ troppo stretta tra i sistemi operativi Microsoft e le Java Virtual Machine che di volta in volta sono state incluse in essi e il tentativo, da parte di Microsoft, di plasmare la piattaforma Java per adattarla meglio ai propri sistemi operativi; con l’obiettivo di far rientrare quelle fette di mercato che si erano spostate verso Java per le sue caratteristiche indubbiamente interessanti.

Al termine del confronto, Microsoft è stata condannata a versare una cospicua somma a Sun Microsystems; cosa, naturalmente, poco incisiva. Soprattutto, è stata vincolata strettamente dal punto di vista tecnico a non oltrepassare certi limiti nei confronti del concorrente.

I paletti che sono stati fissati sono, in particolare, il divieto di migliorare le prestazioni della Java Virtual Machine di Microsoft, il divieto di modificare il nome, il numero di versione o il bytecode di ciò che può essere prodotto su licenza Sun e, soprattutto, il divieto di commercializzare prodotti basati su licenza Sun ed in particolare su versioni più recenti della versione 1.1.4 del Jdk. Quest’ultimo divieto, pertanto, impedisce a Microsoft di produrre una nuova versione dell’ambiente di sviluppo Visual J++ a meno di non limitarlo alla suddetta versione del Jdk, cosa che lo renderebbe non commercializzabile.

Da una parte, quindi, Microsoft non può più produrre ambienti di sviluppo basati su Java, dall’altra sta per uscire sul mercato con Visual Studio.Net, prodotto che si preannuncia molto interessante soprattutto per la nuova architettura DotNet che lascia intravedere ottime prospettive anche dal punto di vista della distribuzione dei servizi e dell’utilizzo di nuove tecnologie come SOAP ed i Web Services.

Uno dei punti di forza di Visual Studio.Net è l’idea, in verità non troppo originale, di appoggiarsi ad una macchina virtuale per ottenere un livello di astrazione che permetta l’esecuzione di codice intermedio, pseudo-compilato, su qualsiasi piattaforma hardware e software per la quale esista una macchina virtuale dedicata.

L’altro punto di forza è la possibilità di generare questo codice intermedio utilizzando un compilatore che, virtualmente, possa tradurre qualsiasi linguaggio di programmazione in un linguaggio intermedio utilizzabile all’interno della macchina virtuale.
I dettagli sull’architettura DotNet sono reperibili in un mio articolo di qualche mese or sono a questo indirizzo.

La stessa Microsoft fornisce, all’interno dello stesso ambiente di sviluppo Visual Studio.Net, il supporto ad una serie di linguaggi di programmazione che differiscono tra loro soltanto per la sintassi, si va da Visual Basic.Net fino al nuovissimo C#. La compilazione di sorgenti prodotti utilizzando questi linguaggi produce sempre lo stesso codice intermedio, quasi senza nessuna differenza a livello di codice pseudo-compilato.

A causa delle specifiche di compilazione totalmente pubbliche, sono nati come funghi moltissimi compilatori che traducono in codice intermedio per la piattaforma.Net i linguaggi più disparati, si va dallo Smalltalk al Cobol al Pascal, la stessa Microsoft ne garantisce una ventina.
Nulla vieta pertanto la produzione di un ambiente di sviluppo che utilizzi la sintassi del linguaggio Java per produrre codice IL, ecco nascere quindi Visual J#.

Visual J# non è un ambiente di sviluppo per Java, nel senso che non produce codice che possa essere eseguito all’interno di una Java Virtual Machine, utilizza invece un linguaggio la cui sintassi è identica in tutto e per tutto a quella di Java, ma per eseguire il codice è necessario utilizzare la macchina virtuale propria della piattaforma.Net, cioè il CLR.

Quello che accade, quindi, a partire dallo stesso codice Java, è questo:

Questo naturalmente è vero per tutti i sorgenti java che possono essere compilati utilizzando il JDK 1.1.4.

Il porting delle vecchie applicazioni scritte utilizzando Visual J++ 6.0 è, a prima vista, garantito da una serie di tool e dalla presenza nel nuovo ambiente di sviluppo degli adeguati namespaces.
A ben guardare, inoltre, ci si accorgerà che Visual J# non è una semplice rivisitazione della versione precedente Visual J++, ma si tratta di un ambiente interamente nuovo che funziona utilizzando le librerie interne di DotNet, le uniche aderenze con la versione precedente dell’ambiente di sviluppo sono le somiglianze, ed in alcuni casi la coincidenza, dei nomi delle librerie e dei namespaces di riferimento. Si tratta insomma di un nuovo prodotto, davvero molto simile al nuovissimo Visual C#, che rende possibile il porting delle applicazioni Java sulla piattaforma DotNet senza dover cambiare una riga di codice.

Unica limitazione, se vogliamo trovarne una a tutti i costi, è l’impossibilità di generare applet. Questo è ovvio in quanto un’applet deve essere eseguita all’interno della JVM, tendenzialmente di un browser, ma il codice di Visual J#, come detto, non può girare su nessuna JVM.

Siamo di fronte, pertanto ad un doppio scacco di Microsoft nei confronti di Sun. Da una parte l’aver aperto la porta agli sviluppatori Java per effettuare il porting delle loro applicazioni su piattaforma DotNet a costi tendenti allo zero, dall’altra alla mancanza all’interno del nuovissimo Windows XP, di una Java Virtual Machine.

Dal punti di vista del marketing la lotta si fa sempre più dura, ma se questo serve a produrre ambienti di sviluppo di qualità come questo nuovo oggetto Microsoft sembra essere, allora ben venga la competizione commerciale.