Nei precedenti articoli abbiamo visto come creare un applicazione Java agile, evitando il blasone delle specifiche J2EE. Dopo aver valutato (scartandola) una soluzione 2-tier molto simile a quelle fattibili in PHP, ci siamo focalizzati su una soluzione basata su Spring.

A Gioorgi.com abbiamo una sezione di ricerca e sviluppo, dove abbiamo la necessità di provare diversi tipi di ambienti in situazioni live: prova e ti riprova, abbiamo consolidato una certa esperienza in soluzioni Java Enterprise a “consumo ridotto”.

In questa serie di articoli (di cui state leggendo la seconda puntata) vediamo come ottenere un’ambiente Java leggero, LAMP-like che gira in una manciata di Megabytes…

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…