 |
| Il garbage collector osserva attento l'heap di sistema |
Apparso nel 1995 col motto di «write once, run everywhere», Java s'è diffuso in diversi dispositivi, con fortune alterne: sui telefonini ha avuto un timido successo eclissato dalla corazzata Android; sui client lo usano pochi coraggiosi e gli sviluppatori che utilizzano Netbeans; le celebri Applet son morte attorno al 2001.
E su server? Beh, Apache Foundation lo usa per praticamente per tutti i suoi progetti; IBM e Oracle lo usano come base delle loro soluzioni software.
Insomma, un successo o un flop?
Dipende. Che Java sia usato è indubbio (i numeri ci sono), ma la destinazione è completamente diversa da quella prevista: nato come piattaforma per i client, Java ha successo solo nell'ambito server. Se pensate a quali sono i VERI programmi client Java, quelli che si usano seriamente, cosa troviamo?
Eclipse,
Netbeans,
Vuze e
Runescape. Programmi belli e potenti, ma troppo poco per parlare di un successo. Dal lato server, invece, cosa vediamo? Dando una sbirciatina al sito della Apache Foundation trovo:
e un'altra decina almeno di progetti open che, nel 90% dei casi è scritta in Java.
La celebre Java Virtual Machine
"Java" è il nome "ombrello" sotto cui son raccolte tre cose:
- un linguaggio
- una Virtual Machine
- il classpath (la libreria standard)
 |
| La Scimmia Cattiva odia la JVM |
Il linguaggio e il classpath sono apprezzati e ammirati, tant'è che Android usa come piattaforma di sviluppo il linguaggio Java e il classpath reimplementato da Apache (
progetto Harmony). Ma se chiedete a uno sviluppatore cosa non gli piace di Java, egli punterà il dito contro l'odiatissima Java Virtual Machine. Nessuno ha mai avuto difficoltà a SCRIVERE un programma in Java, ma quasi tutti si son lamentati della velocità di esecuzione.
In realtà, una volta avviata, la Virtual Machine realizzata da Sun (nome in codice "
Hotspot") lavora discretamente bene, con prestazioni generalmente non distantissime a quelle C++, grazie soprattutto alla presenza del
JIT. Dai benchmark ricaviamo che i calcoli trigonometrici sono ancora molto lenti, quindi eviteremo di usare Java per applicazioni di calcolo scientifico.
Però vediamo cosa dicono i
benchmark di Jake 2, una reimplementazione in Java del motore grafico di Quake 2. Sembrerebbe che Java ne esca con le ossa meno rotte del previsto rispetto al C/C++ dal punto di vista della velocità. Davvero non male, visto e considerato che si può stimare che il codice sia almeno del 20% meno complesso (niente header files e niente puntatori).
Un altro articolo interessante è fatto da uno degli sviluppatori dell'
Irrlicht Engine: questi ha scritto un'
interessante analisi sulle differenze tra Java e C++ per vedere se poteva essere conveniente scrivere un mototre grafico per la piattaforma di Oracle. I risultati, come dice lui, danno C++ vincitore «anche se Java gli si è avvicinato»; l'autore considera anche che, ricorrendo a ottimizzazioni qui e là, si possono rovesciare i risultati a favore o a sfavore di uno o dell'altro linguaggio; inoltre (onesto e imparziale) ammette che probabilmente i calcoli sarebbero stati più favorevoli per Java se non avesse considerato il tempo di avvio della Java Virtual Machine e avesse utilizzato l'ottimizzazione
-server per fare le prove. Le sue conclusioni le trovate sul link che vi consiglio di leggere perché è scritto bene: quel che volevo mostrare è che tutto sommato, le differenze di velocità in esecuzione son sicuramente migliorate.
Alla SUN facevano i server (e si vede)
Sun Microsystems era celebre per i suoi sistemi server di cui curava tutto: il processore (
lo SPARC) era progettato da loro; il sistema operativo (
Solaris) idem; il sistema di condivisione di file in rete (
NFS) l'hanno fatto loro. Insomma, quando si trattava di server, la Sun sapeva perfettamente il fatto suo. E lato client? Non conoscete
CDE,
NeWS o il progetto
Looking Glass? Guardateli bene e forse li troverete familiari. Forse perché
- le idee di CDE sono riprese e migliorate dal desktop environment XFCE, uno dei più famosi nel panorama open-source.
- il funzionamento di base NeWS è molto simile al window manager da Mac OS X (che usa PDF anziché postscript)
- Looking Glass sicuramente ispira uno degli ultimi brevetti registrati da Apple sulle interfacce utente
Insomma, grandi idee, ma forse gestite male. Dopotutto Sun faceva i soldi con i server e l'assistenza. Nel 1993, l'anno in cui si inizia a pensare a CDE, Microsoft stava diventando il colosso che noi tutti conosciamo e Apple, anche se in cattive acque, aveva comunque un nome con cui fare i conti. Questa mentalità da "progettisti software" si riflette anche sulle interfacce utente per la piattaforma Java: se guardate la documentazione di
Java2D, vedrete che questa ha una ricchezza e una varietà di classi e di funzioni da far impallidire chiunque; se guardate come è progettata Swing vedrete che è ingegnerizzata così bene che è possibile integrare routine OpenGL come icona di un bottone (
guardate qui).
Tecnicamente si tratta di cose impressionanti, ma se lanciate un programma grafico che usi Swing noterete una lentezza imbarazzante (forse Netbeans è l'unico che si salva); se avete programmato con Swing conoscerete bene l'inferno dei suoi layout. Se poi realizzate che abbiamo dovuto aspettare il 2008 e Netbeans 6 per avere un editor delle interfacce visuale (Matisse), quando Mac OS X, Windows e QT ne hanno avuto uno fin dal loro rilascio, non vi stupirete di sapere che Swing lo usano quattro gatti.
Alla Sun, evidentemente, avevano la passione per le interfacce testuali.
Facciamo un server
Se provate a scrivere un server multithread in Java avrete una gradita sorpresa: con meno di cento righe di codice sarà pronto un echo server funzionante che gestisce eccezioni e timeout. Impegnandovi potete fare un
server IRC discreto in mezza giornata. Non dovrete preoccuparvi dei memory leak, sarà affidabile grazie al tanto bistrattato garbage collector (sapete che potete sceglierne sei a seconda delle esigenze?). Se poi il vostro hardware non regge e volete affiancarlo con un altro, non dovrete reimplementare niente: la JVM è scalabile, ossia sa bilanciare automaticamente il carico in maniera trasparente. Nel calcolo parallelo c'è il problema delle
sezioni critiche; se in C o C++ bisogna ricorrere a semafori o mutex e fare un
attentissimo debug (con più thread/processi è più difficile ricreare le condizioni di errore) in Java basta chiudere la sezione critica in una classe che abbia i metodi specificati con
synchronized e il problema è risolto.
Il Domani dell'Isola di Java
Dal 1995 di strada ne è stata fatta e di cose ne sono cambiate: il
grunge non va più e internet è
in tutte le case. La rivoluzione client promessa da Java è stata fatta prima da Flash e poi da AJAX e Sun ha pagato le sue sviste venendo assorbita da Oracle.
La piattaforma Java è ancorata ai grandi server aziendali che devono macinare migliaia di richieste su più macchine, in maniera affidabile e scalabile. Il database NoSQL Cassandra ne è l'esempio perfetto. Ci sarà sicuramente qualcuno che continuerà a far programmi client in Java, ma piattaforme alternative più comode come Python e Ruby probabilmente gli saranno sempre più preferite. Android, che pure usa il linguaggio e il classpath, sicuramente non rifiuterà in un prossimo futuro interpreti python ottimizzati e, magari dotati di JIT.
Non sono in grado di fare previsioni: molti sistemi bancari usano Java come backend e difficilmente abbandoneranno anni di sviluppo e di test in favore di qualcos'altro (un fenomeno simile c'è in ambito scientifico con il Fortran). Tutto è nelle mani di Oracle e, in parte, della comunità Java: a loro il compito di rendere l'isola un centro frequentato, un parco naturale o una riserva.
