MokaByte Numero 20 - Giugno 1998
		Java1.2 vs Java$
	di Ennio Grasso	CSELT Torino, 08/03/98  http://andromeda.cselt.it/users/g/grasso/index.htm

Executive Summary

Se da un lato Java, quello "ufficiale" definito da Sun e supportato da IBM, Oracle, Netscape, et al. procede per la propria strada, dall'altro si affianca un altro Java, che chiamerò Java$, di Microsoft. La strategia di M$ è evidente: ribaltare il concetto proposto da Sun secondo il quale Java non è solo un linguaggio ma anche una piattaforma e un'architettura. Una piattaforma perché grazie alla presenza della Java Virtual Machine ogni differenza hardware e di sistema operativo viene annullata. Un'architettura in quanto Java definisce un modello a componenti, Java Beans, e supporta la comunicazione distribuita con Java RMI e ora, con il JDK 1.2, anche con CORBA. Sono proprio questi elementi a disturbare il predominio di M$ con la piattaforma Wintel e l'architettura DCOM/ActiveX. Il contrattacco di M$ consiste nello sgretolare gli aspetti di piattaforma e di architettura di Java relegandolo al ruolo di semplice linguaggio di programmazione al pari di C++ e Visual Basic. Ma come attirare gli sviluppatori alla propria versione di Java invece di quella ufficiale? Come convincerli ad abbandonare lo slogan "write once run everywhere" che caratterizza lo sviluppo di applicazioni Java? Semplicemente offrendo qualcosa difficile da rifiutare: l'accesso da Java a tutte le API di Windows, la possibilità di definire oggetti COM e ActiveX in Java con la stessa facilità del Visual Basic ma con la potenza del C++.

Non mi ero mai occupato di Java$. Ultimamente ho però dato uno sguardo a questo "nuovo mondo" e devo ammettere che chi sviluppa applicazioni in ambiente Windows non può ignorare la potenza messa a disposizione da Java$. Su questo punto tornerò a parlare in seguito.

Le novità di Java 1.2

Java extensions

Il modello identifica due tipi di estensioni: downloaded e installed. Le prime sono recuperate dalla rete come le applets e sono soggette agli stessi vincoli di sicurezza di quest'ultime, le seconde sono invece installate localmente alla macchina e hanno gli stessi privilegi delle classi di sistema. Il modello è ricorsivo, nel senso che il JAR di un'estensione può a sua volta indicare una dipendenza nei confronti di una o più estensioni.

Il loading dinamico delle classi è stato modificato per supportare il modello delle estensioni. Nelle versioni precedenti il class loader della Virtual Machine cercava le classi usando la variabile di ambiente CLASSPATH. Adesso questa variabile non viene più utilizzata e il class loader adotta la seguente politica:

• prima cerca tra le classi di sistema;
• poi cerca tra le installed extensions;
• infine, se le prime due ricerche falliscono, cerca tra le downloaded extensions.

Tra le installed extensions esiste una sotto categoria detta standard extension che rappresenta quelle estensioni definite e controllate direttamente da Sun. Tra queste possiamo citare Java Servlet (tra l'altro fornita assieme al JDK 1.2), Java Telephony (prima JTAPI), Java Management (prima JMAPI), Java 3D, Java Media Conference, Java Naming & Directory, Java Enterprise Beans, ecc.

Java Foundation Classes

Il modello precedente AWT (Abstract Windowing Toolkit), sebbene sufficiente in alcune circostanze, ha evidenziato diverse lacune quando si costruiscono interfacce grafiche sofisticate. Il pregio dell'AWT è di offrire una libreria indipendente dal sistema operativo per garantire la portabilità di applets e applicazioni Java che fanno uso di componenti grafiche. AWT ottiene questo risultato con un modello detto peer in cui ogni componente grafica (button, window, panel, scrollbar, ecc.) è una classe Java che avvolge (wrap) una corrispondente componente del sistema nativo sottostante e ne delega l'esecuzione dei metodi. Il problema del modello peer è la sua "pesantezza" per la mole di lavoro di traduzione tra le componenti AWT e le corrispondenti native: delegazione di invocazione di metodi, inoltro di eventi, mantenimento dello stato consistente tra le due componenti.

Le JFC consistono di 5 moduli:

• AWT;
• Swing;
• Java 2D;
• Drag & Drop;
• Accessibility.

Swing 

Una aspetto importante di Swing è di adottare il pattern Model-View-Controller (MVC) introdotto a suo tempo in frameworks grafici sofisticati come OpenStep e Taligent. Il pattern MVC divide ogni componente grafica in tre oggetti distinti:

• il Model che contiene stato della componente;
• il View che rappresenta l'immagine grafica della componente;
• il Controller che contiene il comportamento in risposta agli eventi (es. mouse click);

 

Metal L&F Organic L&F

 

   Windows L&F Mac L&F Motif L&F

Java 2D

Drag & Drop

Accessibility

Java Collections API

• liste, o sequenze, ordinate di elementi che possono essere inseriti e rimossi in ogni posizione;
• insiemi di elementi non replicati;
• dizionari, detti anche hash tables, che fanno corrispondere un elemento "indice" con un elemento "valore".

Le uniche due classi a supporto delle collezioni in Java 1.1 sono le classi Hashtable e Vector. Del tutto assente è però una differenziazione sull'implementazione delle collezioni. Per una collezione è importante non solo il tipo di funzionalità offerte, ma anche il modo in cui le funzionalità sono implementate. Questo aspetto non dove essere trasparente allo sviluppatore che deve avere la possibilità di scegliere l'implementazione più adatta al proprio caso come compromesso tra benefici/controindicazioni. Ad esempio, due liste, pur offrendo esattamente le stesse funzionalità, potrebbero esse implementate rispettivamente come un array e come insieme di oggetti linkati. La prima implementazione usa la memoria in modo più efficiente e permette accessi rapidi ma è penalizzante se occorre inserire e rimuovere oggetti di frequente perché richiede riallocazioni dell'array. La seconda implementazione ha vantaggi e svantaggi opposti. Se venisse fornita un'unica classe lista che maschera completamente ogni aspetto implementativo, lo sviluppatore non avrebbe la possibilità di migliorare le prestazioni dell'applicazione. Per questi motivi Java 1.2 fornisce un framework completo a supporto delle collezioni con diversi tipi di collezioni e diverse implementazioni per ogni tipo. Il nome di ogni collezione segue la convenzione <implementazione><tipo> dando origine alle seguenti classi:

implementazioni
 

tipo collezione	hash table	array	B-tree (albero bilanciato)	oggetti linkati
insieme	HashSet	ArraySet
lista		ArrayList		LinkedList
dizionario	HashMap	ArrayMap	TreeMap

 

Ad esempio, un dizionario (detto Map) ha tre implementazioni: come hash table, adatto nei casi generali; come array, utile se il dizionario è di ridotte dimensioni e garantisce prestazioni migliori su operazioni di crezione e iterazioni; come albero bilanciato, che impone un ordinamento agli elementi e offre prestazioni migliori per le operazioni di ricerca ma è più costoso per le inserzioni di elementi. Le classi Hashtable e Vector del JDK 1.1 sono ancora disponibili anche se è preferibile ora usare le equivalenti HashMap e ArrayList rispettivamente. Una caratteristica delle nuove collezioni è di non offrire metodi sincronizzati (synchronized) come invece avviene per Hashtable e Vector. Questa scelta è dettata da ragioni di efficienza visto che il codice sincronizzato è decisamente penalizzante in Java. Se comunque le collezioni possono avere accessi concorrenti il framework fornisce delle classi di avvolgenti che si occupano di accedere in modo sincronizzato i metodi di una collezione.

Vi sarebbero diverse altre cose da dire al supporto delle collezioni, ma mi limito a segnalare che il framework è estensibile e chiunque può fornire un'implementazione personalizzata per un certo tipo di collezione, ad esempio una lista implementata da una tabella SQL. Finalmente le collezioni in Java hanno lo stesso potere espressivo dell'STL in C++.

Oggetti Reference

1. 1 raggiungibile, se esiste anche un solo riferimento valido (un altro oggetto che vi riferisce);
2. 2 non raggiungibile, se non esistono riferimenti validi e l'oggetto può essere rilasciato dal garbage collector.

// obj is an object I want to control

MyClass obj = new MyClass();

WeakReference ref = new WeakReference(obj);

ReferenceQueue q = new ReferenceQueue();

ref.register(q);

...

Quando obj non ha più riferimenti validi il garbage collector inserisce il WeakReference ref nella coda q. L'applicazione può dedicare un thread separato che chiama l'operazione remove della coda. L'operazione blocca il thread fino a quando un oggetto cambia livello di raggiungibilità e diventa weak:

// this thread blocks till the weak reference is inserted in the queue

WeakReference ref = q.remove();

// do whatever you need to do with ref

...

ref.clear();

// now the garbage collector can release the object

Evoluzioni di Java Reflection, Serialization e RMI

1. 1 Una classe può indicare esplicitamente quali attributi serializzare dichiarando l'attributo:
2. public final static ObjectStreamField[] serialPersistentFields = {...};
3. che serializza gli attributi elencati nell'array serialPersisteField anziché ispezionare la classe e serializzare tutti gli attributi non static e non transiet come avviene di default.
4. 2 Le classi ObjectOutputStream.PutField e ObjectInputStrem.GetField sono due inner classes che permettono un ulteriore controllo fine sugli attributi da serializzare;
5. 3 Due nuove interfacce: Replaceable e Resolvable che permettono a un oggetto di indicare un altro oggetto come sostituto di serializzazione. Questo meccanismo viene ad esempio usato da Java RMI. Quando un oggetto che supporta l'interfaccia Remote viene passato come parametro di invocazione remota, invece di passare l'oggetto viene passata la sua stub realizzando così una semantica pass-by-reference anziché pass-by-value.

Per quanto riguarda Java RMI la novità più importante riguarda la possibilità di attivare automaticamente oggetti remoti. Nella versione 1.1 di Java RMI un client può invocare i metodi di un oggetto remoto solo se il server che esporta l'oggetto è attivo in attesa di invocazioni. Java RMI 1.2 supporta un meccanismo di attivazione simile a CORBA: l'invocazione viene dapprima dirottata su un processo demone che si fa carico di lanciare il server se questi non è attivo. Altre novità sono la possibilità di indicare il tipo di sockets da usare in una chiamata remota (es. SSL) e alcune estensioni minori all'API.

Java IDL

Evoluzioni di Java Beans

Evoluzioni di Java Security

• - quello locale alla macchina ha tutti i privilegi di accesso alle risorse;
• - quello proveniente dalla rete (applets) gira in uno spazio di esecuzione (sandbox) che limita fortemente il tipo di operazioni ammesse.

L'accesso a una risorsa viene regolato da una richiesta di "permesso" che indica sia la risorse che il tipo di azione che vuole eseguire. A seconda dei privilegi del richiedente il permesso verrà concesso o meno e l'azione potrà essere eseguita. I permessi sono specificati come sottoclassi di java.security.Permission. Un'applicazione può definire una sottoclasse di Permission per regolare accessi alle proprie risorse. Il JDK 1.2 definisce già alcune sottoclassi: FilePermission, SocketPermission, PropertyPermission, RuntimePermission. Ad esempio un'applicazione (o applet) che vuole accedere a myfile in lettura e scrittura deve creare un'istanza di FilePermission:

FilePermission perm = new FilePermission("myfile", "read, write");

se vuole aprire una connessione sulla macchina loom.cselt.it:

SocketPermission perm = new SocketPermission("loom.cselt.it", "connet");

Dopo aver creato il permesso, l'applicazione (o applet) lo inoltra all'AccessController che verifica se questa ha il diritto all'azione richiesta. In caso contrario l'AccessController solleva un'eccezione e nega la possibilità di eseguire l'operazione:

AccessController.checkPermission(perm);

Come fa l'AccessController a sapere se concedere o meno il permesso all'applicazione (o applet)? Consultando il file java.policy che contiene un elenco di questo tipo:

grant [SignedBy "signer"] [, CodeBase "URL"] {

permission perm_class ["target"] [, "action"] [, SignedBy "signer"];

permission ...

}

grant ...

Ogni entry grant concede al codice firmato da "signer" e proveniente da "URL" tutti i permessi elencati. Facciamo alcuni esempi:

grant {

permission java.io.FilePermission "myfile", "read";

}

concede a tutto il codice, indipendentemente se firmato o meno e dalla sua provenienza, l'accesso in lettura al file myfile.

grant SignedBy "Ennio", CodeBase "http://loom.cselt.it" {

permission java.io.FilePermission "/usr/ennio/-", "read,write,execute";

permission java.io.SocketPermission "*", "connect";

}

concede al codice firmato da Ennio e proveniente da http://loom.cselt.it (quindi applets) di leggere, scrivere, eseguire tutti i files nella directory /usr/ennio e sue sotto directories, e di aprire connessioni su qualunque macchina in rete.

grant SignedBy "Ennio" {

permission java.io.FilePermission "/usr/ennio/-", "read,write,execute";

permission java.io.SocketPermission "*", "connect";

}

è identico al precedente ma questa volta le permissions sono concesse al codice firmato da Ennio indipendentemente dalla sua provenienza: locale o qualunque nodo della rete.

Un'applet firmata da Ennio che voglia scrivere sul file /usr/ennio/myfile dovrà contenere il seguente frammento di codice:

FilePermission perm = new FilePermission("/usr/ennio/myfile", "write");

try {

AccessController.checkPermission(perm);

// write myfile

} catch (AccessControlException e) {

// I don't have the rights :(

}

Microsoft SDKJ 2.0

Nel frattempo osserviamo più da vicino le proprietà del SDKJ che lo distinguono dal JDK. Molte di queste proprietà sono rivolte agli sviluppatori Windows per usare Java come linguaggio alternativo a Visual Basic e C++.

Java chiama Windows

• - Java ® DLL
• - Java ® COM
• - Java ® ActiveX

Java ® DDL

• - impedenza del mapping tra i tipi di dati di questi due linguaggi,
• - problemi legati alla migrazione dei threads da un ambiente all'altro,
• - gestione della memoria (il garbage collector non può intervenire sulla parte C).

L'alternativa M$ a JNI si chiama J/Direct e ha l'obiettivo è di semplificare l'interfacciamento Java/C in ambito Windows. E bisogna ammettere che J/Direct è più immediato da usare di JNI perché non richiede la scrittura di codice C, anche se comporta una programmazione "sporca" e sicuramente non portabile. L'approccio di J/Direct è quello di introdurre nel codice Java delle direttive di compilazione all'interno di commenti. Le direttive vengono tradotte dal compilatore Java di M$ in opportune istruzioni della Virtual Machine la quale fornisce il supporto runtime per l'integrazione Java/C. Ovviamente solo il compilatore Java di M$ è in grado di riconoscere queste direttive e generare il codice di interfacciamento; le direttive sono racchiuse all'interno di commenti in modo che ogni compilatore non M$ le ignori senza sollevare errori di sintassi. Un esempio di J/Direct:

class MyClass {

/** @dll.import("USER32") */

public static native int MessageBox(int hwnd, String text, String title, int fuStyle);

...

}

La prima linea, racchiusa tra commenti, è la direttiva J/Direct. Nell'esempio la direttiva indica al compilatore che il metodo MessageBox della riga successiva corrisponde in realtà a una funzione C (con lo stesso nome) esportata dalla DLL USER32. Il metodo deve sempre avere i modificatori static e native. La Virtual Machine di M$ è in grado di effettuare automaticamente la conversione Java/C della maggior parte dei parametri di invocazione. Ad esempio un int Java corrisponde a un intero 32 bit C, un oggetto String Java corrisponde a un array di caratteri terminato da NULL, ecc. Le complicazioni sorgono quando la funzione C si aspetta:

• - dei puntatori a parametri di ritorno;
• - delle strutture C;
• - dei puntatori a funzione invocate come callback.

Parametri di ritorno

void SomeFunction(int x, *int y, int *z);

che viene invocata in C come:

int a, b;

SomeFunction(10, &a, &b);

In Java non esiste il concetto di puntatore. Per simulare l'effetto di un puntatore e avere delle variabili modificate nel chiamante è necessario passare i parametri per riferimento anziché per valore. In Java la semantica del passaggio dei parametri è definita in base al loro tipo: i tipi primitivi (int, char, ecc.) sono sempre passati per valore mentre gli oggetti sono sempre passati per riferimento. Come passare un tipo primitivo per riferimento? In Java gli arrays sono oggetti e quindi sono passati per riferimento; quindi il trucco di J/Direct consiste nell'allocare un array di dimensione [1] avente come unico elemento il tipo primitivo da passare. Ad esempio, per invocare SomeFunction da Java:

public class MyClass {

/** dll.import("MYDLL") */

public static native SomeFunction(int x, int y[], int z[]);

}

chiamata come:

int a[] = new int[1];

int b[] = new int[1];

MyClass.SomeFunction(10, a, b);

Strutture C

La soluzione di J/Direct è di introdurre una seconda direttiva per indicare che una classe Java viene usata per rappresentare una struttura C e che quindi il garbage collector non ha la facoltà di spostare in memoria le istanze della classe. La struttura C:

typedef struct {

int x;

char y;

} A_STRUCT;

corrisponde in Java:

/** @dll.struct() */

class A_STRUCT {

int x;

char y;

}

Una funzione AnotherFunction(*A_STRUCT p) della DLL MYDLL può essere invocata da Java:

public class MyClass {

/** dll.import("MYDLL") */

public static native AnotherFunction(A_STRUCT);

 

public void callit() {

A_STRUCT alfa = new A_STRUCT();

AnotherFunction(alfa);

}

}

Ma c'è ancora un problema. Molte strutture C contengono degli arrays tra i loro campi. Il compilatore C ottimizza la memoria allocando lo spazio dell'array all'interno della struttura stessa. In Java invece ogni array viene sempre allocato come oggetto separato. Anche in questo caso l'unico modo per risolvere il problema è di usare una terza direttiva per forzare l'allocazione dell'array all'interno della classe che rappresenta la struttura:

typedef struct {

int x;

float y[32];

} EMBEDDED_ARRAY;

corrisponde in Java:

/** @dll.struct() */

class EMBEDDED_ARRAY {

int x;

 

/** @dll.structmap([type=FIXEDARRAY, size=32]) */

float y[];

}

La direttiva dll.structmap specifica che l'array y[] di dimensione 32 deve essere allocato all'interno della classe. Un caso particolare sono gli array di caratteri intesi come stringhe. In questo caso si usa una variante:

typedef struct {

int x;

TCHAR y[32]; // TCHAR è un tipo di Windows

} EMBEDDED_ARRAY;

corrisponde in Java:

/** @dll.struct() */

class EMBEDDED_ARRAY {

int x;

 

/** @dll.structmap([type=TCHAR[32]]) */

String y;

}

Puntatori di funzione

import com.ms.dll.*;

public class MyCallback extends Callback {

public boolean callback(int x, int y) {

// do whatever you need to do

...

}

}

 

...

public class MyClass {

/** @dll.import("MYDLL") */

public static native YetAnotherFunction(Callback c, int p);

 

public void callit() {

YetAnotherFunction(new MyCallback(), 10);

}

}

Per finire vorrei sottolineare che il SDKJ contiene il package com.ms.win32, un insieme di classi Java che usano J/Direct per accedere alle funzionalità della WIN32 API. Il package contiene tre categorie di classi Java:

• - classi che rappresentano costanti usate dalle funzioni WIN32, come MAX_PATH, ecc.
• - classi che esportano le funzioni di una particolare DLL, come USER32, KERNEL32, ecc. I metodi di queste classi usano la direttiva dll.import;
• - classi che rappresentano strutture C passate come parametro di funzioni WIN32. Queste classi usano la direttiva dll.struct.

Java ® COM

• - usare oggetti COM all'interno di programmi Java,
• - scrivere oggetti COM in Java.

Usare oggetti COM

Le funzionalità degli oggetti COM sono descritte con un linguaggio dichiarativo IDL (Interface Definition Language) molto simile all'omonimo di CORBA. La compilazione della specifica IDL produce la type library dell'oggetto COM, l'equivalente runtime dell'IDL, che può essere consultata dinamicamente da un'applicazione per scoprire le funzionalità offerte dalle interfacce. L'informazione della type library può essere inserita direttamente nella DLL, o in un file separato con estensione TLB.

Il SDKJ contiene il tool JactiveX in grado di esaminare il contenuto di una type library e generare una classe Java avvolgente corrispondente alla classe COM e tante interfacce Java quante sono le interfacce supportate dalla classe COM. Notate che a differenza del C++ che non ha il concetto di interfaccia, in Java è possibile un mapping 1-1 dei concetti di classe e interfaccia di COM facilitando il passaggio Java « COM. La classe COM viene vista come una qualsiasi classe Java e il gioco è fatto! Ad esempio, supponiamo che la DLL server.dll abbia una type library che descrive la classe CComServer con due interfacce IComServer e IComManage:

jactivex /javatlb server.dll

produce il package server che contiene la classe CComServer e le interfacce IComServer e IComManage che possono essere importate e usate in qualunque programma Java:

import server.*;

IComServer s = (IComServer)new CComServer();

s.op1();

IComManage m = (IComManage)s;

m.op2();

Il flag javatlb serve a indicare che si vuole accedere a un oggetto COM e non un ActiveX, come vedremo in seguito. Notate come l'uso di COM si riduca a normale programmazione Java e confrontate la complessità dell'equivalente C++:

IComServer *s = NULL;

CoCreateInstance(CLSID_CComServer, NULL, CLSCTX_SERVER,

IID_IComServer, (void**)&s);

s->op1();

IComManage *m = NULL;

s->QueryInterface(IID_IComManage, (void**)&m);

m->op2();

s->Release();

m->Release();

La semplicità d'uso di COM in Java è possibile perché la Virtual Machine di M$ conosce il protocollo di COM e gestisce automaticamente le chiamate AddRef, Release e QueryInterface dell'interfaccia IUnknown che tutti gli oggetti COM supportano.

Scrivere oggetti COM in Java

• specificare le interfacce e la classe dell'oggetto COM secondo la notazione IDL;
• compilare la specifica IDL generando la type library dell'oggetto COM;
• usare JactiveX sulla type library per generare le classi e interfacce Java corrispondenti;
• implementare il comportamento dei metodi della classe COM in Java;
• registrare l'oggetto COM nel registry di Windows usando il tool Javareg.

1. Definiamo un oggetto COM con un'interfaccia IWidget e classe CWidget:

[

object,

uuid(F3588E20-F601-11cf-BC7E-00A0C913D202),

]

library WidgetLib

{

[

uuid(F3588E21-F601-11cf-BC7E-00A0C913D202),

helpstring("IWidget"),

 

]

interface IWidget : IUnknown {

HRESULT add([in] long x, [in] long y, [out,retval] long *pz);

};

 

[

uuid(A364ACF2-F5EF-11cf-BC7E-00A0C913D202),

helpstring("CWidget")

]

coclass CWidget {

[default] interface IWidget;

};

};

Non è mia intenzione entrare nei dettagli della sintassi IDL perché esula da questa nota. In particolare, l'uso di quelle strane cifre (uuid) serve per assegnare degli identificatori univoci a tutte le entità di COM, interfacce, classi, librerie, ecc.

2. Compiliamo il file IDL con il compilatore MIDL che genera la type library dell'oggetto COM nel file WidgetLib.tlb. Questi passi (1 e 2) sono comuni a qualunque sviluppo di oggetti COM indipendentemente dal linguaggio usato per implementarli. Ora entra in gioco Java.

3. Usiamo JactiveX su WidgetLib.tlb con due flags: javatlb e cj. javatlb l'abbiamo già incontrato e serve a generare la classe Java CWidget e interfaccia IWidget. Il flag cj ordina a JactiveX di generare un'ulteriore classe CWidgetImpl con questo aspetto:

public class CWidgetImpl implements IWidgetDefault,com.ms.com.NoAutoScripting {

public int add(int x, int y) {

throw new com.ms.com.ComFailException(0x80004001); //E_NOTIMPL

}

}

4. Ora implementiamo l'oggetto COM in Java. Questo può essere fatto scrivendo direttamente il comportamento dei metodi della classe CWidgetImpl, oppure definendo una sua sottoclasse:

public class MyWidget implements CWidgetImpl {

public int add(int x, int y) {

return x + y;

}

}

5. Per finire registriamo l'oggetto COM nel registry di Windows con il tool Javareg in modo che ogni applicazione possa invocarne le funzionalità:

javareg /register /class:MyWidget

/clsid:{A364ACF2-F5EF-11cf-BC7E-00A0C913D202}

Java ® ActiveX

- usare degli ActiveX in Java come se fossero dei Java Beans,

- usare dei Java Beans in Visual Basic, Internet Explorer, ecc., come se fossero degli ActiveX.

ActiveX come Java Beans

Ricordate il tool JactiveX descritto per l'integrazione Java « COM? Come il nome suggerisce, questo tool è stato pensato prima di tutto per l'integrazione Java « ActiveX, o meglio Java Beans « ActiveX. JactiveX estrae le informazioni contenute nella type library di un ActiveX e genera una classe Java conforme a Java Beans che avvolge l'ActiveX e tante interfacce Java quante sono le interfacce dell'ActiveX.

A questo punto basta includere il bean nel programma Java e invocare le sue funzionalità. L'esempio che segue usa l'ActiveX Calendar incluso il M$ Office:

jactivex calendar.ocx

produce un bean Calendar.java che può essere usato da un programma Java:

import com.ms.activex.*;

import calendar.*; // Classes from JActiveX when run on Calendar control or typelib

 

public class UseCalendar implements ActiveXControlListener {

Calendar c;

 

public UseCalendar() {

c = new Calendar();

c.addActiveXControlListener(this);

}

 

// Implementation of ActiveXControlListener interface

public void controlCreated(Object o) {

if (o instanceof Calendar) c.today();

}

}

Java Beans come ActiveX

javareg /register /control /class:MyBean /typelib:MyBean.tlb

Javareg svolge automaticamente diversi compiti:

• - sfruttando l'introspezione di Java Beans, ispeziona la classe MyBean e determina i suoi eventi, properties, metodi, e genera una type library contenente le stesse informazioni. Il flag typelib indica il nome del file della type library.
• - genera uno uuid da associare alla classe MyBean. Ogni entità nel modello di COM deve avere uno uuid. Se non si inidca a Javareg uno uuid con il flag clsid, questi ne genera automaticamente uno e lo associa alla classe del bean.
• - registra la classe MyBean nel registry di Windows. Il flag control ordina di aggiungere le informazioni necessarie per considerare la classe un ActiveX.

Per finire due parole sull'uso del tag OBJECT di IE4. Questo tag serve per includere gli ActiveX nelle pagine HTML. A differenza delle applets che hanno la vita della pagina in cui sono incluse, gli ActiveX vengono installati su disco. Accessi successivi alla stessa pagina non comportano il trasferimento dell'ActiveX già disponibile localmente. Solo se l'ActiveX viene aggiornato sul server sarà nuovamente scaricato per sostituire la vecchia versione. Questo modello potrebbe essere interessante anche per le applets, soprattutto se hanno dimensioni tali da rendere pesante il loro trasferimento. Con IE4 è sufficiente includere l'applet nella pagina HTML usando il tag OBJECT anziché APPLET per far si che l'applet sia considerata dal browser come un ActiveX e quindi salvata su disco. Non occorre nemmeno usare Javareg: ci pensa IE4 a registrare la classe nel registry.

Chiuso il capitolo più importante di Java$, passiamo a un altro aspetto controverso nella guerra Java vs Java$, le Application Founation Classes.

Application Foundation Classes

• - Le JFC estendono l'AWT, per cui possono essere usate assieme. Le AFC invece non sono compatibili con l'AWT perché introducono una gerarchia di componenti separata. È possibile usare componenti AFC in contenitori AWT e viceversa tramite delle classi che eseguono il bridge tra questi due sistemi. Ad esempio una componente UIButton di AFC può essere inclusa in un Panel AWT tramite una classe bridge AwtUIButton. Detto questo bisogna aggiungere che le AFC hanno un'architettura molto simile all'AWT e quindi la migrazione da un'applicazione basata su AWT alla stessa basata su AFC è un processo non complicato. Il SDKJ contiene il tool Awt2afc che semplifica la conversione da AWT a AFC inserendo suggerimenti e commenti nel codice AWT dove sono richiesti gli interventi. Invece, sebbene le JFC estendano la gerarchia dell'AWT, il loro modello è molto diverso perché basato sul pattern MVC. Questo significa anche che le interfacce AWT continuano a funzionare con le JFC, ma uno sviluppatore che voglia sfruttare appieno le funzionalità delle JFC deve ripensare al modo in cui progetta le interfacce grafiche. E in effetti la curva di apprendimento delle JFC è ben superiore rispetto alle AFC. Il pattern MVC è molto più potente dei tradizionali approcci ma allo stesso tempo è più complesso da padroneggiare.
• - Tutte le componenti JFC sono dei Java Beans e adottano lo stesso modello di delegazione degli eventi. L'effetto è un miglioramento delle prestazioni perché gli eventi sono inoltrati solo alle componenti che hanno espresso interesse a riceverli. Le AFC supportano il modello a eventi di Java Beans ma l'implementazione interna segue il vecchio modello dell'AWT. Il risultato è che gli eventi vengono propagati a ritroso nella catena di ereditarietà anche a quelle componenti non interessate a riceverli con un notevole degrado delle prestazioni. L'esempio che segue mostra come un evento Java Beans comporti ben 4 eventi con le AFC mentre uno solo con le JFC:

• Nel caso JFC, quando il Button viene premuto l'evento actionPerformed viene inoltrato all'ActionListener che si era registrato. Nel caso AFC la pressione del Button propaga l'evento sia verso l'alto seguendo la gerarchia con chiamate postEvent e sia a tutti i listeners, in questo caso anche il MouseListener che in realtà non era interessato all'evento actionPerformed.
• - Per quanto riguarda le possibilità di estendere e personalizzare le componenti, le JFC sono più flessibili delle AFC. Come per l'AWT, l'unico modo per estendere una componente AFC è tramite una sottoclasse che aggiunge il comportamento desiderato. Grazie al pattern MVC, con le JFC è possibile intervenire su tre fronti: sottoclassando le componenti come nel caso AFC, sostituendo il Look & Feel delle componenti grafiche (Viewer), modificando il modello dei dati di una componente (Model).

MokaByte Web - 1998 www.mokabyte.it MokaByte ricerca nuovi collaboratori. Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@infomedia.it