di  Giovanni Puliti

Visual J++ 6.0  Prova su strada del nuovo prodotto di sviluppo   di Microsoft per la piattaforma Java

Successore della versione 1.1 [1]  il Visual J++ 6.0 è la nuova proposta di casa Microsoft per la programmazione in ambiente Java: inserito nella suite di programmazione Visual Studio 6.0 (dove troviamo fra gli altri il Visual Basic, il Visual C++, ed il Visual FoxPro), deve questo salto nella numerazione proprio per una questione di allineamento e di omogeneità con gli altri prodotti del pacchetto.

La prima impressione che ho avuto la prima volta che ho avuto modo di utilizzarlo, è stata la notevole semplicità con cui è possibile lavorare con tale strumento: ma mentre sono rimasto molto ben impressionato da alcune feautures, purtroppo altri aspetti non mi hanno proprio convinto dell'ambiente, sopratutto a causa della visione che MS ha del mondo Java.

Vediamo perciò di analizzare punto per punto gli aspetti più importanti del VJ++ 6.0, cercando di mantenere la massima obiettività possibile.

Sicuramente la sezione dedicata all’interfaccia è quella che maggiormente ha subito le maggiori modifiche, e difatti le novità saltano subito agli occhi.

Fig 1: la finestra della gestione delle risorese. Permette di controllare la parte di codice e visuale del progetto.

Il nuovo IDE è stato completamente modificato, sia per ammodernarlo rispetto al passato (la versione 1.1 ormai aveva fatto il  suo tempo), sia per uniformare tutti i prodotti del Visual Studio allo stesso look: è infatti  nuova caratteristica del Visual Studio 6.0 il fatto che i i vari  prodotti hanno una interfaccia grafica molto simile fra loro.  E' addirittura  possibile impostare l’ambiente del Visual J++ in modo che sia del tutto identico a quello del Visual Basic 6.0 o viceversa.  Fra i vari componenti dell’interfaccia notiamo la finestra di gestione delle risorse del progetto (figura 1), la finestra di gestione  delle proprietà dei vari componenti grafici, quella degli eventi (figura 2), e l’ormai classica Toolbox (figura 3). La parte centrale come consuetudine è riservata alla programmazione testuale e visuale delle varie parti del progetto (come in VB, per passare dalla modalità visuale a quella testo, è sufficiente eseguire un doppio lcick su un componete grafico).

Fig 2: la finestra della gestione degli eventi: si può associare un evento per un certo oggetto, ad un metodo. In quesot caso Form1_click verrà associato al click sul panel per mezzo di un delegato apposito. Un doppio click sulla parte del nome del metodo porta ad aprire automaticamente  la finestra del codice.

Toolbox, componenti e AWT
 

Fig 3: la toolbox paginabile e personalizzabile.In questo caso vediamo aperta la pagina dei componenti WFC.

Particolare attenzione deve essere posta nella analisi della  toolbox e delle funzionalità ad essa legate, dato che da questo componente poi si sviluppa tutta la filosofia del prodotto. Suddivisa in pagine, essa raccoglie una serie di componenti pronti all’uso per la programmazione visuale.  Altri ambienti ormai ci hanno abituato a questi oggetti, come ad esempio il Visual Café o il JBuilder.  Per la filosofia che stà alle spalle della programmazione visuale, il tipo di oggetto che tipicamente si adatta a tale feautures è il componente, e non tanto l’oggetto (nel senso della OOP). Per questo motivo sia il Visual Cafe che il JBuilder forniscono di default sia componenti javabeans, in genere proprietari, sia il supporto per i nuovi componenti Swing,  che da questo punto di vista possono  essere visti come una rivisitazione dei predenti AWT in chiave componenti. Come molti pero’ sanno tutti gli ambienti permettono l’utilizzo anche dei componenti AWT, molto utili quando si desideri realizzare una applicazione portabile, che possa essere eseguita anche da browser  non compatibili con il JDK 1.2 (al momento tutti). Gli oggetti di AWT come molti di voi sapranno, non sono componenti JavaBeans (anche se manca poco per poterlo essere), cosa che in teoria dovrebbe impedirne l’uso visuale. Dato che questa pero’ sarebbe una grossa limitazione, e dato che i componenti principali della AWT sono noti, in genere essi vengono inseriti ugualmente nella toolbox,  simulando meccanismi come l’introspezione automatica, che permette invece l’inserimento automatico di un nuovo componente nella toolbox e l’utilizzo visuale, senza doverne conoscere le caratteristiche. Questo in parte potrebbbe spiegare  come mai ad esempio il Jbuilder permetta di agire su pochissime proprietà degli oggetti tramite la finestra delle proprietà.

Tornando al Visual J++ vediamo cosa offre da questo punto di vista: fra le varie cose sicuramente la più interessante è la presenza delle Windows Foundation Classes (WFC), un set di componenti di cui parleremo più avanti. Essi sono in tutto e per tutto componenti  (ma non JavaBeans) e possono essere utilizzati per la programmazione visuale.Oltre ad altri oggetti presenti, come quelli per la progettazione di pagine html, e oggetti COM/ActiveX, sicuramente una grossa mancanza è il supporto per i JavaBeans e per gli AWT: quest’ultimo fatto, dal punto di vista prettamente teorico è una carenza condivisibile, ma in pratica sicurmente non è una scelta giustificabile.

Anche se niente vieta di inserire nel proprio progetto gli oggetti di AWT a mano, scrivendo direttamente il codice, questa è possibilità corrisponde a tornare indietro di qualche era informatico-geologica.

Infine una ulteriore caratteristica della toolbox è la sua  personalizzabilità: con semplici operazioni di copia ed incolla, è possibile inserire oggetti, pezzi di codice,  ma  anche porzioni di interfaccia grafica. Questa è una caratteristica molto interessante, e permette ad esempio di semplificare il lavoro di gruppo, creando template da distribuire a più persone.

Grazie all'utlizzo delle Windows Foundation Classes, il Visual J++ mette a disposizione una interessantissima caratteristica, e cioé la possibilità di interagire direttamente con le DLL di sistema di Win32: questa possibilità ci permette di realizzare in maniera del tutto trasparente sia applicazioni eseguibili Windows, sia oggetti COM/ActiveX. Anche in passato la versione precedente permetteva utilizzando Java, di produrre risultati di questo tipo: il tutto pero’ era piuttosto macchinoso, e richiedeva alcuni passaggi più o meno automatici (come la compilazione di un file in linguaggio IDL per la rimappatura delle chiamate di funzione). Adesso invece, semplicemente selezionando il tipo di progetto, ci si può scordare dell'obiettivo finale e concentrarsi solo sulla fase di programmazione.L’ambiente da un lato, e le WFC dall’altro fanno tutto quello che serve per ottenere il risultato voluto.

Vediamo quindi quali sono le possibili tipologie di progetto che si possono realizzare:

• Progetto Applicazioni
• Applicazione Windows:  la classica applicazione eseguibile Win32. E’ importante notare che in questo caso l’ambiente ci aiuta nella fase finale di compilazione dedicata e di packaging del progetto, ma il programmatore deve far uso delle Windows Foundation Classes, il vero motore di questo tipo di applicazione.
• Applicazione console: la classica applicazione da linea di comando sempre per Win32.
• Creazione applicazione guidata: una specie di wizard molto utile col quale realizzare applicazioni sia data aware che normali. Rispetto al passato sono state tolte alcune opzioni del tutto inutili (come la possibilità di inserire animazioni), ed è stata migliorata  la gestione delle varie proprietà.
• Progetto di tipo Controllo:   la possibilità di accedere alle DLL di sistema, permette inoltre di creare oggetti COM e ActiveX incapsulandoli in DLL. Anche in questo caso il programmatore non deve minimamente preoccuparsi dei dettagli implementativi legati alla particolare modello: l’oggetto COM sarà una classe  Java simile a tutte le altre, tranne ovviamente che per il funzionamento. Progetti Pagine WEB
• Applet in HTML:  la modalità di programmazione alla quale siamo più abituati: non presenta particolari novità o cambiamenti rispetto allo standard solito.
• Modulo in HTML: anche se abbastanza estraneo a Java, questo tipo di progetto permette di realizzare pagine html con script integrato: il DHTML risulta essere in questo caso molto simile al codice Java che faccia uso di WFC, per cui anche in questo caso non sono necessari eccessivi sforzi di comprensione.

 

Per quanto riguarda la scelta del formato di rilascio, si hanno a disposizione molte possiblità, variando fra il  .CAB, lo zip, o il file autoestraente. Il formato jar non è supportato direttamente, ma  come molti sanno tale tipo di file è equivalente allo zip, per cui è facilmente ottenibile  con una semplice ridenominazione.

Si è detto che la vera innovazione del VJ++ rispetto al passato, è l’introduzione delle WFC, un set di componenti utilizzabili sia in maniera visuale, che direttamente da codice Java per realizzare applicazioni Win32.

Il meccanismo che permette questa specie di magia è molto semplice: infatti, pur eportando una interfaccia Java,  cosa che permette di utilizzarli all’interno di un programma come se si trattasse di oggetti come tutti gli altri, essi in realtà vanno ad interagire direttamente con le DLL di sistema per mezzo di uno strato di software detto J/Direct. In questo modo un oggetto button ad esempio non implementa direttamente le funzionalità di bottone, ma si appoggia a quanto messo a disposizione dall’oggetto bottone di sistema. Per questo si può dire che le WFC sono dei contenitori (wrapper) per le classi di sistema.

Lo strato J/Direct si incarica di tutte le operazioni di marshalling e redirezione delle chiamate da codice Java  verso Win32 e viceversa.

Questo meccanismo che potrebbe apparire inutilmente complesso, in realtà permette di mantenere una notevole separazione fra lo strato alto (l’applicazione) e ciò che sta sotto (il s.o.), in maniera concettualmente simile al sistema messo in atto dall JVM. (vedi la figura 4).

 

 

Fig 4: struttura architetturale dell Windows Foundation Classes. Si noti lo strato di J/Direct interposto fra lo strato Java e quello del sistema operativo.

 

Tale separazione permette di non vincolara la parte alta dalla particolare implementazione di ciò che sta sotto, e  se qualcosa dovesse cambiare nel sistema operativo, modificando eventulamente lo strato del J/Direct, l’applicazione continuerà a funzionare normalmente.

Inoltre, proprio perché i componenti WFC  esportano interfaccia Java, non è necessario  conoscere e seguire particolari tecniche di programmazione differenti da quelle della piattaforma Java, dato che tutto viene tradotto in maniera automatica.

Eventualmente da notare che il Delegation Model è stato sostituito con il modello dei delegati:  tale modifica non deve preoccupare, dato che in definitiva il nuovo modo di gestire gli eventi è del tutto equivalente alla gestione con il Delegation Model [2] in abbinamento con le inner classes [3].

Anche se l'argomento non è strettamente legato all'analisi del tool di sviluppo, vediamo con un esempio come poter implementare una semplice gestione degli eventi per mezzo dei delegati.

Ecco la versione JavBeans dove si utilizzano inner classes per connettere  gli event handlers.
Da notare la classe adapter anonima dichiarata nel metodo jbInit. Ognuna di queste classi implementa una interfaccia di gestione degli eventi. Questo Design Pattern  nel quale il codice relativo all'evento è separato dal suo gestore è un esempio tipico generato da tool di sviluppo basati su JavaBean, ed è esattamente quello definito da Sun.
 
 

class SimpleFrame extends DecoratedFrame {        Button buttonOK = new Button();        Button buttonCancel = new Button();            void buttonOK_actionPerformed(ActionEvent e) {          System.out.println("OK clicked");        }        void buttonCancel_actionPerformed(ActionEvent e) {          System.out.println("Cancel clicked");        }        void jbInit() throws Exception{          buttonOK.setLabel("OK");          buttonOK.addActionListener(          new ActionListener() {              public void actionPerformed(ActionEvent e){               buttonOK_actionPerformed(e);              }           });          buttonCancel.setLabel("Cancel");          buttonCancel.addActionListener(          new ActionListener(){              public void actionPerformed(ActionEvent e){               buttonCancel_actionPerformed(e);              }           });          this.add(buttonOK, BorderLayout.NORTH);          this.add(buttonCancel, BorderLayout.SOUTH);        }      }

Ecco la versione WFC che utilizza i delegati per connettere  gli event handlers.
Si noti l'instanziazione del delegato EventHandler nel metodo initForm. Quando viene chiamato il metodo invoke  di un delegato, allora   viene inovcato il metodo che è incapsulato nel delegato stesso.
 

class SimpleForm extends Form {        Button buttonOK = new Button();        Button buttonCancel = new Button();        void buttonOK_click(Object sender, Event e){          System.out.println("Clicked OK");        }        void buttonCancel_click(Object sender, Event e){          System.out.println("Clicked Cancel");        }        void initForm(){          buttonOK.setText("OK");          buttonOK.addOnClick(new EventHandler(this.buttonOK_click));          buttonCancel.setText("Cancel");          buttonCancel.addOnClick(new EventHandler(this.buttonCancel_click));          this.setNewControls(new Control[] {buttonCancel, buttonOK});        }      }

Ecco il codice per collegare l'event handler  ad un bottone in WFC
 

buttonOK.addOnClick(new EventHandler(this.buttonOK_click));

ed ecco l'equivalente secondo il delegation model per mezzo di una inner class

 

 

buttonOK.addActionListener(      new ActionListener(){          public void actionPerformed(ActionEvent e) {              buttonOK_actionPerformed(e);          }      }     );

 

La particolare visione di Java

Come molti di voi forse sapranno, Micorsoft non nutre particolare simpatia per il linguaggio Java e la tencnologia annessa. Già in passato proprio su un numero di MokaByte [4] abbiamo avuto modo di analizzare quella che  è la politica della casa produttrice di Windows. Come tutti sanno questo ha portato alla battaglia legale contro Sun, che per adesso risulta la vincitrice, e ciononostante non sembra che le cose per il momento cambino.  Tanto per fare un piccolo riassunto, ricordo che Microsoft propone una sua versione particolare della JVM (incluse le librerie del JDK), che risultano essere incompatibili con lo standard Java per due motivi. Il primo è che sono state effettuate delle modifiche ad  alcune firme di metodi di classi di sistema: questi cambiamenti, seppur minimali, risultano essere fondamentali per la non compatibilità con il codice Java standard. In pratica un programma compilato utilizzando le librerie di MS, può avere problemi se lo si vuole mandare in esecuzione su una JVM standard.

Oltre a ciò, Microsoft ha pubblicamente dichiarato che non intende supportare alcune features del JDK 1.1 come RMI, e CORBA, dato che a suo parere non le ritiene necessarie per lo sviluppo della tecnologia  Java. Inoltre non supporta l'utilizzo dei metodi nativi.

Ebbene con l'arrivo del VJ++ altre limitazioni sono state introdotte nel mondo MS-Java: al momento, parlando con uno dei progettisti Microsoft che ha partecipato al gruppo di sviluppo del VJ, il prodotto non fornisce nessun supporto per i JavaBeans, offrendo invece la possibilità di utilizzare i componenti WFC e COM/ActiveX. La motivazione ufficiale è che JavaBeans non è una tecnologia aperta, essendo essenzialmente legata al linguaggio Java, mentre se si desidera realizzare un oggetto COM si può utilizzare un qualsiasi linguaggio utilizzato dai vari tool di sviluppo come VB, VC++, Delphi ed altri.

Ovviamente la posizione di MS rispecchia un comportamento ormai tipico, che più di una volta mi sono trovato a non condividere affatto,  e per una volta lascerò ogni commento ed interpretazione al lettore.

In ogni caso quello che importa è che questo elimina una grossa fetta di possibilità applicative, anche se si considera che, pur non avendo trovato nessuna indicazione in merito, non sono riuscito ad attivare l'utilizzo diretto e visuale di componenti AWT (per non parlare dei componenti Swing).

Perché VJ++

Alla luce di quello che abbiamo analizzato fino ad adesso, vediamo di fare qualche considerazione sul prodotto, e sui reali vantaggi che un programmatore possa avere dall’adozione di questo prodotto a discapito di altri.

Si è visto come la questione della compatibilità del VJ++ con la piattaforma JVM non abbia una sola interpretazione,  quindi vediamo in pratica come risolvere questo punto.

Nel caso in cui si debba realizzare un prodotto totalmente portabile, ovvero 100% Pure Java, sicuramente la scelta del VJ++ non è la migliore, ed anche se niente vieta di utilizzarlo proprio con questo scopo, le possibili alternative possono facilitare di non poco  il lavoro.

Se invece si deve realizzare una applicazione Java che debba essere eseguita all’interno della piattaforma Win32, allora sicuramente il prodotto di Microsoft  offre innegabilit vantaggi. Si potrebbe obiettare che in questo caso non sia necessario per forza utilizzare Java, ed infatti molto probabilmente è vero: in certi casi pero’ in contesti multistrato (dove ad esempio il lato back sia realizzato in Java), l’utilizzo di Java per la realizzazione di ogni  coponente porta innumerevoli vantaggi, sia in termini di semplicità, di sicurezza, e di potenza.

Inoltre, il VJ++ offre un ulteriore vantaggio rispetto a un altro tool per Java: si pensi infatti a quello sviluppatore che abbia investito la maggior parte del suo tempo a studiare, e seguire nella sua evoluzione il mondo Java (linguaggio, tecniche di programmazione, piattaforme), e che debba più o meno all’improvviso, magari per un periodo limitato, realizzare una applicazione Windows 95/NT. Sicuramente tale programmatore avrà nella maggior parte dei casi, grosse difficoltà ad adattarsi ad un settore molto differente e incompatibile con quelle che sono le sue reali conoscenze.

Il poter quindi utilizzare Java, (sia il linguaggio, ma sopratutto il modo di lavorare), offre una valida alternativa al dover passare a strumenti com il VB, VC o Delphi, troppo lontani da Java.

Sicuramente credo che questo sia l’aspetto più importante fra  tutte le novità introdotte con il prodotto.

Oltre a queste due considerazioni, personalmente mi sono fatto una idea, che molto probabilmente verrà criticata da molti, ma che non è poi così insensata: attualmente il prodotto più utilizzato per lo sviluppo di applicazioni Windows è il Visual Basic. Questo ambiente è sicuramente un ottimo prodotto, sintesi ben bilanciata di semplicità di lavoro e potenza realizzativa. Quello  che spesso a volte è stato imputato a questo ambiente è la mancanza di un reale modello ad oggetti con la possibilità di utilizzare i componenti, di personalizzarli o creali ex-novo.

Ebbene, anche se il VJ è ancora lontano dalla popolarità del VB e dalle sue possibilità,  posso dire che già adesso offre da  un lato la semplicità tipica del suo collega, associata contemporaneamente alla possibilità di utilizzare un completo modello di programmazione ad oggetti.

Per adesso la prima piazza del Visual Basic non credo possa temere niente, ma tecnicamente non manca niente al VJ per competere ad armi pari.

Conclusioni

In definitiva il VJ++ 6.0 rappresenta un ottimo prodotto, per lo svilippatore  Java: sicuramente la mancanza di utilizzare JavaBeans ed AWT sono una carenza piuttosto pesante per poterlo considerare un degno concorrente di prodotti più completi come il VCafè  o  JBuilder. Piuttosto considererei il prodotto come una alternativa estremamente specializzata per la piattaforma Win32: per chi sicuramente debba rimanere in tale ambito, consiglio di passare a tale tool. Attenzione in ogni caso ai possibili problemi di portabilità che si possono incontrare utilizzando tale prodotto.

Bibliografia

[1] "Test Visual J++ 1.1" di Giovanni Puliti  in MokaByte Aprile  1997

[2] "Il delegation model" di Daniela Ruggeri    in MokaByte Febbraio 1998

[3] "Le inner classes" di Daniela Ruggeri  in MokaByte Ottobre 1997

[4] "La piattaforma Java secondo Microsoft" di Giovanni Puliti   in  Mokabyte Novembre 1997

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