MS SDK per Java 1.5

Descrizione

L'SDK puo' essere scaricato gratuitamente dal sito della Microsoft, e' formato da due archivi, uno contenente il kit di sviluppo e l'altro la documentazione, per un totale di piu' di 9 Mb di dati.

Nell'ultima versione disponibile in rete, la 1.5, tra le varie cose e' stato aggiunto un plug-in per Netscape che permette di usare la VM della Microsoft, la guida di riferimento dettagliata per quanto riguarda la RNI (Raw Native Interface), il CAB Sdk, ed un numero maggiore di esempi.

Uso di codice nativo

L'implementazione della RNI (Raw Native Interface) secondo le specifiche della SUN costringe alla creazione di funzioni di Stub, e, da come e' implementata, penalizza le prestazioni e costringe ad usare la macro C unhand per rilasciare la rappresentazione interna dell'oggetto.

La VM di Microsoft supera tutte queste limitazioni, permette di semplificare l'integrazione di codice nativo, e di aumentare anche le performance, infatti non e' piu' necessario implementare una funzione di stub, dato che e' la VM a generarne una al volo al momento di chiamare un metodo non java e, soprattutto, non ci si deve piu' preoccupare di rilasciare i puntatori con la macro unhand.

Per una piu' facile utilizzo dei metodi implementati in codice nativo ci viene in aiuto l'utility msjavah che, data una classe java, genera un header C (NomeClasse.h) corrispondente.

Integrazione tra Java e COM

La VM della Microsoft consente l'integrazione tra Java e il Component Object Model (COM) che e' il protocollo da cui deriva la tecnologia ActiveX e l'Object Linking and Embedding (OLE).

In questo modo e' possibile accedere a tutti componenti basati sul protocollo COM inclusi i controlli ActiveX ed usarli, in maniera assolutamente trasparente, all'interno delle proprie Applet o dei propri programmi Java.

Per utilizzare una classe COM e' necessario importarla, cioe' creare una classe Java che rappresenta la classe COM all'interno del contesto Java. Questa operazione viene effettuata automaticamente attraverso l'impiego dell'utility javatlb che estrae le informazioni della classe COM prelevandole dalla "type library" (che e' il meccanismo definito da COM per memorizzare le informazioni sul tipo comprese tutte le entita' COM presenti, le classi o le interfacce) creando la classe java corrispondente.

Il file .CLASS generato contiene uno speciale flag che indica alla VM che quella che sta trattando non e' una normale classe java ma un "wrapper" per accedere ai servizi della classe COM sottostante.

Ad esempio, supponiamo di avere una DLL chiamata prova.dll che definisce la classe CProva e l'interfaccia IProva, lanciado javatlb viene creato il package Prova che contiene il "wrapper" Java della classe e dell'interfaccia. L'unica differenza rispetto all'impiego delle normali classi Java, e' che non si puo' istanziare direttamente la classe, ma bisogna sempre usare l'interfaccia, ad esempio per usare la classe CProva bisogna utilizzare la sintassi:

import prova.*;
...
IProva testProva = (IProva)new CProva();
testProva.FaiQualcosa();
...

Riguardo a questa limitazione la documentazione dichiara che e' dovuta solamente all'utulity javatlb e non a come implementato il supporto della tecnologia COM.

Creiamo un file eseguibile

Una delle cose piu' interessanti presenti in questo SDK e' indubbiamente l'utility jexegen che permette di convertire una serie di classi in un file eseguibile Win32 in questo modo si ottiene un duplice vantaggio: da un lato si puo' distribuire un'unico file invece che una serie di classi, e, dall'altro se ne semplifica l'uso da parte di chi dovra' impiegarlo.

La sintassi e' semplicissima, supponiamo di voler creare un eseguibile dell'esempio ArcTest, presente nell'SDK ufficiale della SUN, ci spostiamo nella directory che contiene tutte le classi e digitiamo:

jexegen /MAIN:ArcTest /OUT:ArcTest.exe *.class

dove: "/MAIN:ArcTest" indica il nome della classe principale

"/OUT:ArcTest.exe" indica il nome del file di uscita (se omesso il file si creato si chiamera' jex.exe)

"\*.class" indica le classi da inglobare nell'eseguibile

A questo punto per provare basta digitare arctest per vedere il risultato.

Ovviamente nel caso si decidesse di distribuire l'applicazione dovremmo anche includere la VM della Microsoft (il file autoscompattante da allegare e' poco piu' grande di un 1Mb).

I pro (e i contro...) del compilatore JVC

La prima cosa che si fa notare del compilatore java fornito dalla Microsoft (jvc.exe) e' la sua straordinaria velocita', ad esempio la compilazione della classica applicazione "DrawTest.java" richiede appena 2 secondi contro i 22 necessari al javac fornito col JDK 1.02, e questo su un 486 a 66 Mhz con 20Mb di RAM.

Se vogliamo compilare qualcosa di piu' complesso di una piccola applicazione ci si accorge ben presto che il compilatore e' molto piu' sensibile a come il codice viene scritto, segnalandoci anche i casi di ambiguita', pero' dopo un primo periodo di frustrazione ci si rende conto ben presto che questo e' un vantaggio infatti lo jvc riesce a segnalare errori che potrebbero essere causati da distrazione, ad esempio il seguente codice:

public class Prova {
    public static void Prova() {
        System.out.println("Non sono un costruttore!!!");
    }

    public static void main(String[] args) {
        Prova p = new Prova();
        Prova.Prova();
    }
}

viene compilato senza problemi col kit di SUN e, se eseguito fa comparire la scritta "Non sono un costruttore!!!", se invece si usa il compilatore JVC ci viene immediatamente segnalato che, giustamente, un costruttore non puo' essere statico impedendoci di proseguire.

Conclusione

I vantaggi nell'utilizzare l'SDK della Microsoft sono da trovarsi nella facile integrazione della tecnologia COM (ActiveX in primis) e nella scrittura di classi in codice nativo, nella possibilita' di poter distribuire il proprio codice in maniera piu' omogenea e facile grazie all'utility jexegen e alla VM.

Personalmente apprezzo anche la rigidita' del compilatore jvc, infatti anche che se all'inizio puo' frustrare l'utilizzatore, dopo un po se ne apprezzano le qualita' perche' permette di scrivere codice piu' robusto evitando quelle ambiguita' che possono dare origine agli errori piu' strani e difficili da individuare.

In definitiva anche se il resto delle opzioni non vi importa, anche solo l'utilizzo dello JVC (o dell'utility jexegen) vi ripaghera' del tempo impiegato per scaricare l'SDK.