Java in un Espresso, Parte I
Introduzione
Quando Java nacque nel 1995, aveva parecchie frecce al suo arco, ma anche molta incertezza. Ricordo che in università fu accolto con favore dall'ambiente accademico, per le sue spiccate doti didattiche.
Java era più semplice da insegnare del C++, e aveva una libreria di base molto ben organizzata. Era già previsto l'uso della proto-annotazione "@deprecated" perché Sun sapeva che avrebbe dovuto far evolvere l'API, e questo evidenziava la cura e l'attenzione per l'organizzazione del lavoro del project management. Ai tempi Sun puntava sulle Java Applet e sugli aspetti di sicurezza, in cui Java eccelleva. Benché la vocazione di Sun fosse enterprise, ancora le specifiche EJB erano al di là da venire.
L'osservazione dei miei colleghi più scafati, che usavano PHP e Perl er ache Java era troppo pesante (in termini di memoria consumata) e lento (essendo interpretato) per i piccoli microcomputer da 12Mb che affollavano le nostre case.
Nel 2009, quattordici anni dopo, le cose sono cambiate e ora anche i pc di casa hanno sistemi a due processori e 4GB di RAM. Java è ancora lento e pesante ?
Vediamo come sviluppare applicazioni leggere e compatte in Java...
La risposta è affermativa se è usato in ottica enterprise, con application servers, ejb ecc.
Gli EJB si sono diffusi molto meno del previsto, e benché si sia creato un mercato intorno a loro, non brillano per economicità (di sviluppo) o semplicità di comprensione.
Ma usato in modo accorto, Java offre parecchie facilitazioni, e può iniziare a competere con tool più dinamici come PHP e Perl. Tutto sta a scegliere i software giusti e un modo di programmazione "light", focalizzandosi sul risultato finale piuttosto che sulle tecnologie "cool". A tal proposito, Sun sta ricevendo qualche critica a proposito del suo modo di intendere lo sviluppo Enterprise.
Caratteristiche di una soluzione java light
Possiamo confrontare le nostre soluzioni "light" su tre fronti:
- performance (memoria, velocità di rendering della pagina, scalabilità).
- semplicità d'uso (clean&simple) design
- manutenzione ridotta
Riguardo le performance, possiamo osservare che un Tomcat 5.5 consuma appena 10-14MB "out of the box" con le sole console amministrative installate, e con la configurazione di default (che non è affatto minimale, poiché prevede da 25 a 150 thread contemporanei, il connettore AJP e la porta 8080 in http standard).
Per cui tomcat è la scelta migliore per i nostri obiettivi, ed eviteremo di installarci un facoltoso JBoss o un application server commerciale. Questo ci porta ad escludere anche la specifica J2EE "full", basata su EJB.
Se seguiamo la strada delle specifiche J2EE classiche (servlet, ejb ecc) il nostro sviluppo si farà pesante.
Possiamo considerare una soluzione a 2-tier in cui la webapp è composta da un insieme di jsp che si interfacciano in modo più o meno diretto con il database. A tal proposito esistono tag library (JSTL SQL tags) che consentono l'accesso diretto via jdbc. Queste soluzioni però portano a
- difficoltà di manutenzione (provate a fare il refactoring di una serie di jsp...)
- impossibilità di implementare facilmente meccanismi spesso richiesti quali caching o integrazioni XML-RPC
- Forte dipendenza da specifici tag library
- Unit testing quasi impossibile...
Riferimenti