Java: a che punto siamo?

Dal primo speciale dedicato a Java apparso su Computer Programming (era il giugno 1996), è passato ormai diverso tempo (molte ere informatiche), e da uno speciale, siamo passati ad articoli più o meno fissi, fino ad una rubrica dedicata: questa evoluzione rispecchia fedelmente quella che è stata la crescita di Java e dell’interesse ad esso associato.
Con i vari articoli pubblicati fino ad oggi su questa rivista, si è cercato di dare un’idea sulle possibilità offerte dalle varie soluzioni tecnologiche, cercando di dare di volta in volta un esempio su come poter utilizzare tali elementi.
Dopo tutto questo tempo e dopo tutte le parole spese a mostrare i vari prodigi ma anche limitazioni del linguaggio, questo mese invece vedremo quale sia lo stato attuale del linguaggio e della tecnologia: si cercherà di fare una panoramica su quelle che sono le varie soluzioni offerte, e dove invece ancora non si dispone di strumenti sicuri.
Dare una visione obiettiva e temporalmente valida della situazione è un compito piuttosto difficile: l’evoluzione del settore infatti, è tale da rendere obsoleta ogni considerazione appena fatta.
Inoltre il continuo susseguirsi di cambiamenti nelle strategia e politiche aziendali, con relativi strascichi, aumenta il clima di incertezza.
Spero che i lettori perdoneranno certi inevitabili anacronismi presenti nell’articolo.

Molti sono gli aspetti di cui tener conto nel momento in cui si desidera fare una analisi completa del settore: per cercare di mantenere una certa logicità, utilizzeremo l’evoluzione storica del linguaggio come filo conduttore (a tal proposito può risultare molto utile [5]).
Nato ormai quasi tre anni fa, come ambiente di sviluppo di sistemi embedded, si è immediatamente evoluto verso il settore delle applicazioni per la rete. Internet in particolare, oltre ad aver mostrato di essere l’habitat naturale per la sua crescita e sviluppo, ha dato un impulso ad un progetto che era sul punto di fallire ancor prima di essere ufficialmente rilasciato.
La possibilità di eseguire un programma Java (una applet) all’interno di una pagina html, oltre ad aver scosso non poco l’allora statico mondo della IT, è stato di fatto il trmapolino di lancio per farlo conoscere a tutto il grande pubblico.
Questo è stato ed è tutt’ora solo uno degli aspetti di Java, ovvero quello del lato client: almeno all’inizio, erroneamente gli è stato attribuito un ruolo più ampio di quello che non gli spetta realmente, valutazione che ha portato ad un senso di sfiducia nella tecnologia in genere.
Solo successivamente si è diffusa la convinzione che quando si parla di client, si deve pensare ad una applicazione in grado di pilotare una serie di servizi disponibili in un qualche modo su un server remoto.
Corrispondentemente all’affermarsi di questa convinzione, abbiamo assistito alla seconda grossa evoluzione di Java, corrispondente al JDK 1.1: con l’arrivo di strumenti come RMI o JDBC si è stravolto completamente quella che, nell’immaginario collettivo, era l’idea che associava Java a programmi dentro una pagina html.
Riprendendo il concetto di client server, si è affermata la logica delle applicazioni distribuite su più strati di cui il cliente non ne rappresenta che un controllore.
La realizzazione del lato server di una struttura a più strati si è resa più semplice grazie a tecnologie come RMI o JDBC, che permettono di risolvere problemi prima insormontabili e densi di insidie: tale accoppiata in particolare, è quella che sempre più spesso viene utilizzata per visualizzare dati via web, in alternativa alla soluzione solo-aplet, che ha mostrato le sue evidenti limitazioni.
Con l’arrivo del JDK 1.2, questo scenario si è arricchito ulteriormente grazie alla possibilità di interfacciarsi con quello che attualmente è lo standard più potente e complesso d gestione di stutture distribuiti: CORBA.
Ma la versione 1.2, non ha solo portato novità in tal senso: l’introduzione dei servlet abbiamo infatti adesso la possiblità di realizzare strutture client server basate su quello che nel mondo di internet è il protocollo più diffuso, l’http. Con i servlet, è possibile infatti diffondere dati e offrire, servizi in maniera molto semplice e veloce, grazie alla capacità di estendere le funzionalità del web server semplicemente installando una classe Java, ed utilizzando le pagine html come mezzo di trasporto.
E’ stata una delle novità più importanti dell’anno appena concluso, ed ha introdotto una miriade di nuove possibilità che per certi versi hanno tolto spazio a Java stesso, a vantaggio di strumenti come html e tutti i suoi derivati.
Anche se maggiore possibilità di scelta significa maggiore potenza, tutte queste possibili alternative, possono inizialmente confondere nella scelta della migliore configurazione per per la realizzazione di un sistema distribuito interfacciato con il web (attualmente casistica piuttosto tipica).
Molto genericamente la risposta ad un interrogativo del genere, è affidarsi alla struttura più eterogenea possibile: ad esempio una applicazione a 3 strati controllata via browser da una applet potrebbe essere il cuore di tutto, mentre a lato la possibilità di utilizzare un sistema di servlet+html potrebbe fornire tutti i servizi di monitarazione remota.
E’ questo uno dei vantaggi di Java, ovvero la possibilità di scegliere in ogni momento quali moduli utilizzare senza legare in maniera indissolubile ad ogni scelta.

Fin’ora ci siamo concentrati sull’aspetto di Java legato al networking, che anche se ne rappresenta il più importante, non è tutto. Java è stato pensato anche come un linguaggio ed una piattaforma fortemente orientata alla multimedialità: se questo ha significato inzialmente semplicemente visualizzare immagini, riprodurre suoni o piccole animazioni (cose possibili anche utilizzando un browser con dei plug-in installati), con l’arrivo della versione 1.2 del JDK possiamo disporre adesso di una serie di funzionalità avanzate come quelle date dalle Java 2D e 3D, JavaMultimedia e simili.
Anche il settore dei device embedded, che come abbiamo detto rappresenta un po’ il punto di partenza di Java, ultimamente ha avuto un nuovo impulso: grazie alle nuove Java Card API è infatti possibile realizzare software da installare in una smart card, con la stessa semplicità con cui è possibile realizzare una applet da inserire in una pagina html.
Sulla base di queste innovazioni, gli analisti del settore affermano che in un futuro non molto lontano saremo letteralmente contornati da tali oggetti sempre più potenti nelle funzionalità e semplici nell’uso. Si ipotizza inoltre che l’elettrodomestico im maggiore crescita come diffusione e innovazione tencologica del momento, il personal computer, subirà un notevole ridimensionamento proprio a causa di tali oggetti. Quando un semplice web phone palmare (il successore dell’attuale telefono cellulare) permetterà di utilizzare internet in maniera semplice ed economica, probabilmente masse di risorse e di persone abbandoneranno la piattaforma pc troppo costosa e complessa.
Infine c’è il caso del Network Computer, che ormai nella seconda versione ha mostrato di poter essere una piattaforma stabile, potente, e soprattutto competiva con quella del PC. Attualmente Sun ha rilasciato il suo NC versione 2, ma stà lavorando alacremente in stretta collaborazione con IBM per la creazione di un modello definitivo di tale oggetto. Il sistema operativo (il famoso JavaOs) è anche esso in fase di rilascio, per cui a breve si dovrebbe poter disporre di una piattaforma ancora più stabile. Il fatto che dopo i primi insuccessi, sia Sun che IBM non abbiano abbandonato il progetto, ma anzi vi abbiano convogliato maggiori energie, dimostra che l’idea è buona e tecnicamente realizzabile. Il problema principale di oggetti come il NC, è la mancanza attuale di una struttura di rete sufficiente per poter utilizzare in maniera seria queste tecnologie. Le grosse manovre nel mondo della telefonia digitale dovrebbero pero’ eliminare questo impedimento nell’arco di pochi anni, appena in tempo per permettere la maturazione di quello che adesso sta uscendo dalla fase sperimentale.

Fino ad ora si è parlato esclusivamente del JDK e dei suoi vari componenti: anche se esso è di fatto il punto di riferimento di Java, esistono altre realtà altrettanto importanti. Una di queste è senza dubbio quella dei browser, che per importanza deve essere considerata al pari del Java Developement Kit.
Mentre all’inizio dell’era internettiana si poteva scegliere fra varie soluzioni, adesso lo scenario si è ridotto essenzialmente a due protagonisti: il Communicator di Netscape Inc. e l’Internet Explorer di Microsoft.
Entrambi disponibili nella versione 4, devono essere valutato da due punti di vista: per quanto riguarda le funzionalità legate alla normale navigazione in internet, sono entrambi due ottimi prodotti, mentre relativamente alla compatibilità con lo standard Java, presentano differenze anche notevoli.
Oltre che per una minore stabilità e non prevedibilità dei risultati, Internet Explorer, risulta essere più limitato rispetto al concorrente: per precisa volontà di Microsoft, oltre a non supportare le tecnologie RMI, CORBA e JNI, le alterazioni alla JVM (seppur piccole) non permettono di garantire la compatibilità con codice certificato 100%Pure Java.
Al contrario invece il browser di Netscape, dalla versione 4.05 in poi, è l’unico completamente compatibile con il JDK 1.1.
Naturalmente esiste anche HotJava, il quale però deve essere pensato più come un framework estendibile, che un browser vero e proprio.
Questi aspetti legati alle prestazioni e compatibilità dei vari browser sono in buona parte legate alle strategie politiche e di marketing, per cui non basterebbe un solo articolo dedicato per poterne affrontare tutti gli aspetti: questo conferma quanto quello dei browser sia diventato un campo di battaglia così’ importante.
Il motivo di questa situazione è legata al fatto che un programma di navigazione è qualcosa di molto di più di un semplice strumento con il quale muoversi fra un sito ed un altro. La scelta di supportare una determinata tecnologia piuttosto che un’altra, può decretare sia il successo dell’oggetto in se (il browser appunto), che della tecnologia sottostante (Java).
La mossa di Microsoft è stata proprio in tale direzione: il non supportare RMI e CORBA ha lo scopo da un lato per dare maggiori possibilità ai suoi standard (COM e DCOM) e dall’altro per limitare le possibilità di Java (se una cosa non si può fare con Java perché il cliente non ha il browser con RMI, allora facciamola in C/C++). Il browser attualmente potrebbe giocare lo steso ruolo di monopolio che ha giocato in passato il Dos o Windows 3.1.
Anche se complessivamente sembra che si possa godere di una certa possibilità di scelta, nel mondo dei pc WindowsXX (il vero terreno di scontro), la situazione è piuttosto complessa e delicate.
Per chi si affida infatti al Java versione MS, c’è da tener presente che in tal caso, essendo JVM è diventata parte del sistema operativo, si deve subire le scelte della casa. In alcuni casi questo fenomeno porta a sgradevoli conseguenze: ad esempio l’installazione di software di aggiornamento del sistema operativo (Services Pack) porta alla modifica di certe parti della JVM cosa che a volte causa problemi di compatibilità con il software già scritto.
Un po’ per motivi politici (la famosa battaglia legale), un po’ per ovviare al problema delle incompatibilità delle varie JVM, Sun ha rilasciato il cosiddetto Java Plugin (ex Project Activator): si tratta di un ActiveX (si avete capito bene) che inserito in una pagina html, è in grado di mandare in esecuzione una qualsiasi JVM, sulla quale poi viene eseguita l’applet inserita nella pagina.
Ad esempio si può pensare di vedere in azione una applet client RMI su un browser della terza generazione, cosa fin’ora impossibile.
Anche se può apparire la panacea di tutti i mali, presenta alcune controindicazioni, legate alla complessità di installazione: ad esempio la più evidente è che, per installare al volo il plug in, si devono in ogni caso scaricare circa 10 Mb di materiale, cosa non sempre possibile. In una intranet è comunque una strada percorribile.

Abbiamo parlato di JDK e di browser, ma a parte questi due casi particolari di cosa è possibile disporre attualmente nel settore del software scritto in Java o per Java?
Sicuramente molto, soprattutto per quanto riguarda la prima categoria, anche se si tratta nella maggior parte dei casi di applicazioni lato server per cui agli occhi del pubblico Java può apparire come un linguaggio molto utilizzato.
Anche le grandi case hanno ormai abbracciato più o meno integralmente Java come linguaggio di base. IBM è forse la ditta che sta investendo oltre a Sun ovviamente, maggiori energie in tale direzione: oltre ad un pieno supporto per la programmazione in Java dei sui prodotti per wokgroup (Lotus Notes, eSute solo per citarne alcuni), ha pensato anche allo sviluppo di software in Java. Visual Age (attualmente forse l’unico ambiente di sviluppo in linea con la filosofia di programmazione per componenti di JavaBeans), ed il progetto S.Francisco confermano questa tendenza.
Ma IBM non è l’unica a credere in Java, e case come Imprise (Ex-Borland) con il suo JBuilder, od Oracle con le JavaCartridge per il suo ambiente, sono gli esempi più significativi di un mondo che sta letteralmente esplodendo.
In tutto questo turbinio di novità e di prodotti sempre più innovativi e Java-Oriented, si nota per la singolare politica perseguita, il caso di Microsoft.
Più o meno dichiaratamente contraria all’affermazione del linguaggio, si muove in tale settore seguendo con interesse la sua evoluzione, introducendo innovazioni che seppur valide dal punto di vista della tecnologia in se, di fatto generano confusione agli occhi del pubblico [4].
L’ottimo ambiente di sviluppo quale è il Visual J++ 6.0, è un esempio di questa tendenza. Introduce alcune innovazioni veramente interessanti, che però limitano la caratteristica principale di Java: la portabilità. Maggiore potenza e funzionalità sono offerte allo sviluppatore con la controindicazione di una maggiore dipendenza nella piattaforma Windows, semmai ce ne fosse ulteriore bisogno.
Contemporaneamente pero’ il tool di sviluppo per pagine web più utilizzato (Front Page), induce ad inserire applet all’interno di pagine html piuttosto che controlli ActiveX.
Sicuramente questa è una situazione alquanto bizzarra, che denota come il settore Java non sia solo tecnologia, ma anche un terreno dove dare spazio alla lotta per il predominio del mercato.

Riquadro: Il Java fatto in casa Microsoft

La posizione della casa leader mondiale è piuttosto particolare: in aperta battaglia con Sun, battaglia vinta da quest’ultima, si muove in due direzioni apparentemente contrastanti fra loro.
Ufficialmente ha intrapreso una sua strada indipendente dal Java ufficiale nel tentativo una volta di imporre la sua versione personalizzata. La JVM di corredo ai vari prodotti non supporta certe particolari caratteristiche come la Remote Method Invocation o CORBA, dato che Microsoft non le ritiene necessarie o utili. Sono state eseguite delle modifiche minimali che di fatto impediscono la portabilità del codice bytecode. Ma Microsoft oltre a queste operazioni volte a tamponare la corsa si Java, si è anche operata per ampliare la piattaforma Java offrendo alcune interessanti novità tecnologiche.
E’ il caso del Visual J++ 6.0 che introduce delle innovazioni veramente importanti: solo per citare alcuni elementi possiamo ricordare il modello degli eventi dei delegati, e le Windows Foundation Classes.
In particolare, queste ultime, in abbinamento con la tecnologia JDirect, permettono lo sviluppo di applicazioni eseguibili Windows ed oggetti COM/DCOM, in maniera del tutto intuitiva e semplificata utilizzando Java come linguaggio di base.
Sicuramente questa nuova possibilità è estremamente utile per tutti coloro che dopo aver speso molto tempo a studiare Java vogliono avvicinarsi a Windows senza dover dimenticare tutto quello fatto in precedenza; soprattutto è importante il fatto che non è necessario imparare i complessi meccanismi di programmazione in ambiente Windows.
In questo senso il VJ++ è un ottimo strumento di sviluppo ad oggetti, completamente visuale, e potrebbe essere considerato una specie di compromesso fra semplicità del Visual Basic, e potenza del Visual C++.
L’unico problema è la inevitabile elminazione della caratteristica principale di Java, la portabilità, limitata ai soli Windows 95/98 ed NT.
Sicuramente la scelta di Microsoft di correre una sua corsa personale nello sviluppo di Java, non risulta essere molto utile al linguaggio stesso.
Quella di Sun, che viene indicata da Microsoft come una posizione monopolistica, non è altro che lo sforzo di mantenere lo standard il più aperto possibile e compatibile con tutte le piattaforme.
Sarebbe forse auspicabile che l’enorme esperienza delle due case fosse messa al servizio di un obiettivo comune, e non utilizzare Java come strumento per raggiungere il dominio globale del mercato.

In tutto questo mare di soluzioni proposte cosa effettivamente è alla portata di tutti, e soprattutto cosa può essere utilizzato in maniera concreta dal programmatore o dall’utente finale?
Ovviamente una domanda del genere non ha molto senso se presa in assoluto: tutte le api, tutte le librerie, i prodotti che funzionano o che risolvono determinati problemi, rappresentano esempi di come Java possa essere utilizzato.
In pratica però solo una ristretta percentuale di tutto ciò può essere considerato “utilizzabile” concretamente. Ad esempio il JDK 1.2 introduce una mole considerevole di novità per la realizzazione di applet, ma attualmente non è disponibile nessun browser che supporta tale versione.
Da quello che ho potuto osservare esistono tre tipologie di utilizzatori di Java, e questa classificazione rispecchia anche quello che è la situazione reale di Java.

Dopo tutto ciò probabilmente il lettore che non ha seguito l’evolversi graduale della situazione, ma ha di colpo scoperto un nuovo mondo, si troverà sicuramente spaesato, in preda ad una strana sensazione di nausea, con il dubbio di quale direzione intraprendere.
In realtà la situazione è meno caotica di quanto si possa immaginare: riprendendo in considerazione l’esempio delle tre categorie di utenti, come si è visto, ciò che è realmente utilizzabile è solo una parte di tutto quello che il mercato mette a disposizione.
Attualmente l’evoluzione è ancora piuttosto rallentata sia dalla mancanza di infrastrutture (vedi browser e connessioni veloci), sia perché il mercato non è ancora totalmente pronto a recepire il mare di novità in arrivo, sia perché infine Java ha attualmente delle limitazioni intrinseche che lo fanno guardare con sospetto da molti.
I due punti deboli di Java sono ancora quello della lentezza, e della decompilazione. Il primo aspetto lo si può considerare di minore importanza, dato che le evoluzioni del software (introduzioni di tecniche di esecuzione ottimizzate e JIT sempre più efficienti) e dell’hardware, unitamente ad una migliore utilizzazione delle risorse distribuite (con conseguente riduzione di tempi morti e colli di bottiglia), porteranno ad una drastica riduzione del gap rispetto ad applicazioni native.
Per quanto riguarda invece il problema della decompilazione, al momento non sembra esserci soluzione, a parte l’offuscamento del bytecode. Per sdrammatizzare il problema Sun afferma che il poter decompilare, e quindi copiare l’idea, non implica che si possa riprodurre la mente che ha prodotto tale idea. Oltre ad essere piuttosto pittoresca, questa posizione lascia intendere che dovremo attendere ancora un bel po’ per poter avere codice compilato a prova di pirata.
Molto probabilmente questo è il periodo in cui Java sta vivendo la sua consacrazione ufficiale come tecnologia vincente, ma sarà solo con il 2000 che Java si integrerà completamente nella realtà di tutti i giorni.
Java, almeno giurano gli analisti, contribuirà ad fare entrare definitivamente nella vita di tutti i giorni l’informatica, scienza per adesso riservata a pochi eletti.

[1] “Il JDK 1.1, le novità” di Massimo Carli - MokaByte 4 Gennaio 97.
[2] “Speciale JDK 1.2” - Dev 55 Settembre 98.
[3] “Il progetto 100% Pure Java” di Giovanni Puliti - MokaByte 8, Maggio 97.
[4] “La piattaforma Java secondo Microsoft” di Giovanni Puliti - MokaByte 13 Novembre 97.
[5] “C’era una volta Java” di Roberto Palumbo – Mokabyte 23, Ottobre 98

		MokaByte Numero 28 - marzo 1999

		Java, a che punto siamo?
	di Giovanni Puliti	Una panoramica dello stato attuale della tecnologia Java


	In collaborazione con Computer Programming



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