MokaByte Numero 17 - Marzo 1998
		Borland JBuilder Professional
	di Michele Sciabarrà

Palette degli strumenti
Quando apriamo il Jbuilder, ci troviamo di fronte ad una palette di strumenti (visibile in Figura 1) molto simile a quella di Delphi e C++ Builder. La palette, che occupa circa un terzo dello schermo, contiene i menu dell'ambiente di sviluppo, una bottoniera che riassume le funzioni principali, la barra di stato e una "tabbed toolbar" che diventa sempre più comune negli ambienti di sviluppo moderni.

Figura 1

Le linguette permettono di selezionare i componenti da inserire nelle form quando si editano visualmente le interfacce. Occorre notare subito che la toolbar è estensibile: infatti è possibile aggiungere componenti (JavaBeans per l'esattezza) presi da varie librerie, ed è anche possibile (ed abbastanza semplice) implementare in Java i propri componenti. Di default la toolbar presenta componenti presi dalla libreria di componenti JBCL di Borland in dotazione al Jbuilder, componenti e container presi della AWT standard di Java, componenti della libreria Jclass (del KL Group) inclusa col Jbuilder, ed infine alcune applet Sun standard trasformate in Bean.

Il progetto
Per sviluppare con il Jbuilder, la prima operazione da fare è creare un nuovo progetto. Tradizionalmente i programmi in Java sono soltanto una collezione di sorgenti da compilare separatamente. Ricordiamo che in Java non è nemmeno necessario collegare in un unico file i vari moduli del progetto con un linker. Infatti i moduli sono le classi, e il caricamento delle classi avviene dinamicamente: Java è famoso per la sua capacità di caricare le classi anche da fonti diverse dal disco (soprattutto dalla rete), e soltanto quando serve. Comunque è possibile raccogliere in un solo file tutte le classi di un programma generando (anche col Jbuilder stesso) un file JAR. Per sviluppare con Jbuilder comunque occorre creare un file di progetto (con estensione .jpr), che specifica quali sono i file che devono essere compilati. Il progetto serve anche per altre cose, ad esempio per salvare le impostazioni correnti dell'IDE.

Una caratteristica degna di nota è che le dipendenze tra le classi vengono calcolate automaticamente, in modo da ricompilare solo quello che serve. Si risolve così un problema che affligge altri ambienti di sviluppo, che - sebbene venga modificato un solo file di progetto - ricompilano tutti i sorgenti. La preoccupazione di Borland per questi dettagli è una chiara testimonianza del fatto che il prodotto è indirizzato al professionista, che tratta normalmente progetti di ampie dimensioni. In Figura 2 possiamo vedere la schermata che compare quando creiamo un nuovo progetto.

Figura 2

Dobbiamo specificare alcune informazioni che vengono inserite all'inizio di ogni file creato, come documentazione. A questo punto è possibile modificare alcune delle proprietà del progetto, visibili in Figura 3. Si accede alla finestra delle proprietà dalla voce di menu File|Project Properties oppure cliccando col pulsante destro del mouse sul nodo principale del progetto e selezionando Properties. È importante impostare i path, capendone a fondo la funzione, in quanto la maggior parte dei problemi che si hanno all'inizio nel compilare e mandare in esecuzione i programmi sono spesso da imputare proprio alla loro scorretta impostazione.

Figura 3

Abbiamo quindi:

Il Source Path, utilizzato per trovare i sorgenti delle classi. Questo può anche contenere un file in formato .zip dove sono archiviati i sorgenti (in tal caso, verrebbe trattato come una directory);

Il Class Path viene utilizzato per il caricamento delle classi. Occorre notare che normalmente comprende anche alcune librerie (come la jbcl.zip), senza le quali molti programmi prodotti con il Jbuilder non funzionano;

L'Output Path specifica dove vengono poste le classi compilate. Per l'esattezza ogni classe viene posta nella sottodirectory corrispondente al suo package.

Il Browser
Dopo aver creato il nuovo progetto compare una finestra (di cui possiamo vedere una schermata in Figura 5) che rappresenta l'ambiente di lavoro principale. Si tratta di un ambiente integrato che comprende editor, project manager, gui builder e web browser: è da qui che si possono svolgere quasi tutte le operazioni di sviluppo senza cambiare finestra. Per comodità chiameremo questo componente browser. Quest'ultimo è simile all'Explorer standard di Windows, ma è strutturato in tre pannelli anziché due. A destra vengono mostrati due alberi, mentre a sinistra compare il documento corrente, che può essere una pagina HTML, un codice sorgente o una form. In realtà il browser racchiude gran parte delle funzioni del Jbuilder, selezionabili utilizzando le linguette in basso e divise in due gruppi. Il primo gruppo, identificabile a sinistra, consente di selezionare tra tre diverse "viste" di navigazione nel progetto:

Figura 5

Projects. In questo caso il browser mostra in alto a sinistra i file che compongono il progetto, e in basso a sinistra le classi contenute in ognuno dei file .java.

Opened. Si ha una visualizzazione che mostra in alto soltanto i file del progetto che sono stati modificati.

Directory. È consentita la navigazione nel file system.

Creazione elementi
Dopo aver generato un nuovo progetto, dobbiamo aggiungere i vari elementi al progetto. Selezionando File|New. compare la schermata mostrata in Figura 4, che permette di creare un nuovo elemento, scegliendolo da una ampia gamma di template predefiniti.

Possiamo creare dialoghi, classi, pagine HTML, bean e così via. Selezionando questi componenti verrà aggiunto al progetto il codice del nuovo componente. È anche possibile aggiungere al progetto dei file di testo, HTML o Java già scritti, per esempio ripresi da un altro programma. In questo caso la procedura è diversa: occorre cliccare sull'icona in alto a sinistra del browser, che rappresenta una cartelletta con un "più". Una volta creati i nuovi componenti o aggiunti quelli preesistenti, è finalmente possibile editare il programma, sviluppando in maniera visuale o non visuale. In Figura 6 possiamo vedere l'editor del codice sorgente. Notiamo subito come l'uso del Jbuilder sia conveniente rispetto ad un normale editor anche solo per l'editing di codice Java in modalità non visuale. Nel pannello in basso a sinistra infatti viene costantemente visualizzato un albero che rappresenta la struttura del programma in Java in termini di classi, campi e metodi. Se si aggiunge un campo o un metodo, l'albero viene immediatamente aggiornato.

Figura 6

Chiaramente il sorgente Java viene analizzato dinamicamente, man mano che si edita. Utilizzando i due alberi di sinistra è abbastanza agevole spostarsi tra file, classi e metodi. Dopo un po' di pratica l'utilizzo di questo class browser diviene quasi irrinunciabile. La struttura orientata agli oggetti dei programmi in Java porta a lavorare apportando piccole modifiche distribuite tra molti metodi in varie classi.
Lavorando con un comune editor questo procedimento diventa molto scomodo: spesso si perde più tempo a trovare dove andare ad apportare una modifica che non a farla.
 
 

Two-way tool
Anche se il Jbuilder è innanzitutto un potente e comodo IDE, in un ambiente di sviluppo moderno viene oggi considerata irrinunciabile la programmazione visuale. Naturalmente, il Jbuilder consente l'uso effettivo delle tecniche RAD. Abbiamo già notato la tabbed toolbar della palette che serve proprio per contenere gli elementi da inserire nelle interfaccie sviluppate con il GUI builder. Prima di descrivere in pratica come si lavora, occorre spendere due parole per spiegare l'approccio alla visual programming adottata dal Jbuilder (approccio per la verità comune ad altri ambienti di sviluppo Java). La programmazione visuale è nata con il Visual Basic, dove viene gestita utilizzando due tipi di file: le form e i programmi in Basic. L'ambiente di sviluppo del Visual Basic infatti consente innanzitutto di disegnare la form, personalizzare i componenti con le property, e infine di agganciare alla form il codice Basic richiamato dagli eventi. L'editor visuale del VB edita soltanto le form, ovvero un formato di file specializzato per descrivere l'interfaccia. In Java invece le cose sono più complesse, poiché la descrizione dell'interfaccia viene fatta in Java stesso, ed è necessario quindi rintracciare all'interno del sorgente il codice che genera l'interfaccia. I primi ambienti di sviluppo inserivano all'interno dei programmi Java dei marcatori, cioè dei commenti speciali utilizzati per distinguere il codice editato visualmente da quello scritto dall'utente. Jbuilder invece è un vero two-way tool, che consente in maniera paritaria la programmazione visuale e quella non visuale. Questo significa che l'editor visuale è in sostanza un editor di codice: l'utente disegna l'interfaccia, e l'IDE provvede a generare il codice corrispondente all'interfaccia generata. Tale codice è leggibile, comprensibile e soprattutto facilmente modificabile dallo sviluppatore. Se infatti si cambia qualcosa nel codice Java che descrive l'interfaccia, ritornando al designer si vedrà il risultato della modifica che si è apportata senza dover lanciare il programma! In realtà il programmatore, anche se ha molta libertà, non può fare proprio qualunque modifica se non vuole perdere la possibilità dell'editing visuale.

Il Jbuilder infatti utilizza la struttura del programma per capire quale parte è modificabile dal designer e quale invece è di pertinenza del programmatore. Un esempio illustrerà il tutto.

Si crei un nuovo componente, per esempio un Frame. Jbuilder genererà il codice necessario e nel browser comparirà una nuova classe, in questo caso Frame1. Dopo aver cliccato sulla linguetta source, si veda il sorgente. Esaminando quest'ultimo si può notare, tra le altre cose, la generazione di un metodo che può sembrare ridondante: jbInit. Esso viene richiamato dal costruttore, e inizialmente fa poco: imposta soltanto un layout manager, l'XyLayout. L'utilizzo del metodo jbInit è invece fondamentale per il Jbuilder, perché gli consente di identificare il codice Java che descrive l'interfaccia. Si torni alla modalità di design, e si aggiunga un bottone al frame, selezionandolo dalla toolbar. Tornando al source si noterà un nuovo campo, button1. Inoltre è stato modificato il metodo jbInit che imposta le proprietà del Button. Il perno della visual programming del Jbuilder è tutto qui. Per ogni nuovo componente di interfaccia aggiunto ad una classe, viene aggiunto un nuovo campo, e viene modificato il metodo jbInit per impostare le caratteristiche del nuovo componente. Il Jbuilder mantiene l'aspetto dell'interfaccia che il programmatore sta disegnando memorizzandolo nel codice. In pratica il Jbuilder comprende il Java, e aiuta il programmatore a disegnare l'interfaccia producendo il codice necessario per realizzare quello che il programmatore ha disegnato. Il programmatore può anche andare a modificare il codice generato dal Jbuilder. Per esempio si può modificare l'etichetta del bottone, cambiando la linea button1.setLabel("button") in button1.setLabel("Click me!"). Tornando alla visualizzazione grafica notiamo che anche nell'editor grafico si vede l'etichetta modificata!

Il Jbuilder ha analizzato il codice e ha rigenerato l'aspetto dell'interfaccia nell'editor così come vuole il programmatore. Come ho già detto, le modifiche possono essere fatte senza problemi, ma non tutte. Per esempio non è possibile cambiare il nome del metodo jbInit. In tal caso infatti il Jbuilder non troverebbe più la descrizione dell'interfaccia. Se si cambia nome a jbInit, passando alla visualizzazione design si vedrà una interfaccia vuota. In realtà compilando il codice e mandandolo in esecuzione, si otterrà effettivamente un frame contenente un bottone. Il Jbuilder, però, non sarà più in grado di modificare visualmente quel codice a meno di non rimediare la modifica fatta al metodo jbInit.
 
 

Visual Programming
Esaminiamo ora in maggior dettaglio che cosa consente di fare l'ambiente di sviluppo. In Figura 7 possiamo notare una schermata del designer in azione. A sinistra, in modalità design, viene comunque visualizzato un albero che rappresenta la struttura della GUI (non la struttura della classe). Per spostarsi tra i vari componenti di una GUI, è più comodo usare tale albero che non andare a cliccare direttamente su un componente, specie quando ci sono dei componenti invisibili.

Figura 7

Ogni qualvolta si passa alla modalità di design viene anche visualizzato l'inspector delle proprietà, mostrato in Figura 8. La procedura da seguire quindi è quella di creare un nuovo contenitore, inserendovi dei componenti presi dalla palette. Ognuno di questi elementi può essere personalizzato agendo sulle proprietà mostrate nell'inspector. Abbiamo visto come creare un nuovo oggetto significa aggiungere un nuovo campo alla classe; modificare le proprietà significa in pratica editare il metodo jbInit. Rimane la parte forse più importante, la gestione di eventi. L'inspector consente di generare il codice di gestione eventi, semplicemente selezionando l'evento che si vuol gestire. Nel JDK 1.1 ogni componente è una sorgente di eventi, e ogni componente deve registrare una classe target, da richiamare quando l'evento stesso viene catturato. La sua gestione, tuttavia, viene effettuata da un metodo della classe stessa.

Figura 8

Nell'esempio, se Frame1 contiene button1, la gestione dell'evento di click sul bottone verrà svolta dal metodo Frame1.button1_actionPerformed, generato automaticamente dal Jbuilder. Tuttavia per ottenere questo risultato, per motivi tecnici che non interessa approfondire qui, viene anche generata automaticamente una classe adattatore Frame1_button1_actionAdapter, e il necessario codice di registrazione dell'adapter presso il bottone.
 
 

I Wizard
Il Jbuilder, per rendere comodo il lavoro al programmatore, offre una nutrita serie di Wizard che svolgono in automatico alcune delle operazioni di programmazione più comuni. Si ha infatti:
 

Implements Interface: selezionando una interfaccia, la classe corrente viene editata, aggiungendovi le dichiarazioni e i metodi per l'interfaccia da implementare.

Interaction Wizard: permette di generare automaticamente il codice per le interazioni più comuni tra elementi; l'azione da svolgere viene selezionata da una lista.

Override Methods: genera lo scheletro di codice necessario quando si devono ridefinire (override) alcuni dei metodi ereditati da una classe

Resource String: genera le classi risorsa per l'internazionalizzazione di una applicazione, effettuando anche le sostituzioni necessarie per riferirsi alle risors

Wrap Applet: genera il codice necessario per trasformare una applet in un bean.

Deployment Wizard: costruisce un file jar che contiene tutte le classi di un progetto, consentendo la distribuzione di un programma in Java come un singolo file.

Conclusioni
Il Jbuilder non è, a mio avviso, il prodotto più facile da usare tra i vari ambienti di sviluppo per Java 1.1 che stanno uscendo in questo periodo. Quando ho presentato il prodotto in un corso insieme ad altri, qualche programmatore lo ha trovato un po' ostico e difficile da capire. D'altra parte alcuni programmatori esperti che già conoscono il linguaggio Java e le sue caratteristiche lo trovano efficiente e comodo. In realtà Jbuilder consente, per chi è già pratico di Java, una grande produttività, che in fondo è ciò che ci si aspetta da un ambiente di sviluppo. Non banali ornamenti, dunque, ma un agile ambiente di sviluppo che supporta pienamente la programmazione visuale, senza essere però inutilmente visuale (come altri ambienti) quando non serve.
 
 

Bibliografia
[1] James Gosling "The Java Programming Language", Addison-Wesley 1996.
[2] Philip Heller et al. "Java 1.1 Developer's Handbook" SYBEX 1997.
 
 

Michele Sciabarrà è consulente informatico e scrittore tecnico, specializzato in sistemi e applicazioni Internet ed Intranet.  Si occupa di consulenza, amministrazione e sviluppo software per ambienti di rete e siti Web.

 
 
 

	MokaByte rivista web su Java MokaByte ricerca nuovi collaboratori Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it