È dall’ultima JavaOne, tenutasi a giugno, che continua a rimbalzare sul mercato tecnologico lo slogan “Java everywhere”. I destinatari maggiormente coinvolti sono gli sviluppatori, che però, più che di proclami, hanno bisogno di Api e di tool di sviluppo. Sun sta per proporne uno: Rave.
Alla JavaOne dello scorso giugno la parola d’ordine era "Java ovunque". Così è stato ribattuto un po’ in tutto il mondo: con la mediazione di Java tutto può funzionare, dal robot industriale all’elettrodomestico.
Ma se si scende sul piano del lavoro quotidiano, si incontra il mondo degli sviluppatori, cioè coloro che Java lo devono usare. E qui lo slogan si scontra subito con un muro, prevalentemente fatto di Api. Application programming interface: queste interessano agli sviluppatori, prima ancora degli slogan visionari. Seguendo questa logica, Java ovunque dovrebbe significare Api ovunque, per poterci lavorare. Ma essendo così prosaici si perderebbe buona parte del valore semantico del messaggio, che, per Java, ha sempre comunque contato, sin dagli albori (i primi anni 90), quando era un linguaggio per creare applicazioni cosiddette "embedded" da piazzare su strumenti di elettronica di consumo. Un microcode, in pratica.
Java, invece, è prevalentemente diventato un linguaggio che ha fatto di Internet la sua ragion di vita, affermando dapprima il fenomeno delle applet sul lato client e preparandosi la strada per attecchire sui server, prendendo la conformazione delle servlet e, soprattutto, della piattaforma Java 2 Enterprise Edition.
J2Ee è diventato tanto importante da fare perdere il "grip" degli sviluppatori Sun sul lato client. E lo confermano le iniziative dell’ultimo periodo (si veda il riquadro) intraprese da Sun per diffondere Java sul desktop e, in generale, sul dispositivo client, che si rifanno alla logica del "Java ovunque".
Insomma, dietro lo slogan c’è la volontà di Sun di riprendere in mano il genoma del linguaggio e di portarlo laddove era nato. Ovvero, e ci mancherebbe, non c’è solo marketing, ma anche tecnologia.
Tecnologicamente, "Java ovunque" sottende un’unica architettura, la cosiddetta soluzione end-to-end, nella quale tutti i componenti condividono le stesse funzionalità del linguaggio di base, le Api, le librerie e i tool di sviluppo. Ciò vale per la piattaforma Java lato server, costituita da J2Ee, quella lato client, fatta da J2Se (Standard edition) e J2Me (Micro edition) oltre a quella dei dispositivi embedded (J2Me e Javacard). Il vantaggio di avere una struttura comune definisce anche l’idea di fondo: gli sviluppatori possono ottimizzare la produttività perché possono portare su più strumenti quello che hanno sviluppato, scoprendo, così, nuovi spazi di mercato.
La frontiera è il mobile
E qui si viene al punto debole della catena, J2Me, dato che J2Ee e Java client sono ormai punti fermi dello sviluppo. J2Me, invece, è mobile, tanto quanto il mercato a cui fa riferimento. Ma senza questo, il modello non è completo, la piattaforma "ovunque" non è perfetta, e di conseguenza non può mantenere ciò che promette. Per gli smart phone, per esempio, il Midp (Mobile information device profile) del J2Me si limita a specificare un set di base delle Api che ogni dispositivo dovrebbe supportare, una sorta di minimo comune denominatore. Dopodiché la palla passa agli sviluppatori, i quali si trovano di fronte un mercato dei dispositivi in continua evoluzione, con sempre nuove funzionalità aggiunte ai prodotti.
Quindi nell’attuale impostazione architetturale di J2Me si fa ricorso ai package aggiuntivi di Api, che vengono sviluppati e standardizzati nel contesto del Jcp (Java community process), proprio per consentire alla comunità degli sviluppatori di scrivere applicazioni portabili per dispositivi simili per genere.
I pacchetti aggiuntivi del Midp consentono agli sviluppatori di supportare tutte le maggiori funzioni degli smart phone, dagli Sms alla connettività Bluetooth, dalla gestione dei contenuti multimediali ai Web service in stile Soap.
Troppi package aggiuntivi, però, conducono alla confusione, un po’ come succede per le patch di sistema operativo. Ergo, si sta tentando di accorpare. Il più chiaro tentativo di accorpamento è quello conosciuto come Jsr 185, Java technology for wireless industry, che definisce le relazioni e le interazioni fra i vari componenti dell’architettura J2Me, con documentazione, suite di kit di compatibilità e guide all’uso per utenti e produttori.
Affinchè il modello "Java ovunque" possa affermarsi, quindi, si stanno facendo molti sforzi per chiudere la catena dell’end-to-end sul fronte della mobilità coinvolgendo gli sviluppatori. Questi, proprio perché sono già 3 milioni al mondo, abbisognano di qualcosa che riesca a coagularne gli sforzi. Come un tool di Rad (Rapid Application Development) che sappia svolgere la stessa funzione che ha svolto Visual Studio per Microsoft.
Ci vuole un Rad
Sun lo ha presentato al recente Sun Network di San Francisco. Si tratta del progetto Rave. Scopo del tool è proprio di consentire il trasporto di applicazioni create per ambiti limitati, su una scala prettamente enterprise, nel contesto della piattaforma Orion. Si può dire, quindi, che, con Rave, Sun voglia rivolgersi agli sviluppatori aziendali che utilizzano metodologie affini al modello di sviluppo visuale.
Le anticipazioni, infatti, lo danno come un tool "totalmente" visuale, che non richiede la scrittura di nemmeno una riga di codice. Rave, inoltre, può essere collocato su un piano alternativo ad altre offerte del mercato, come possono essere quelle di Ibm (tramite Rational) e Microsoft (VisualStudio.Net), rivolte a fornire agli sviluppatori enterprise un unicum su cui basare le proprie creazioni. Rave supporta, ovviamente, tutti gli standard Java, Jdbc e ha tante Java Api per Xml, il tutto allo scopo di consentire la creazione rapida di applicazioni Web e database. Ovvero, come avere i Web service dietro l’angolo.
