Ottimizzare prestazioni e compatibilità di NetBeans
NetBeans richiede circa 200 MB memoria fisica libera per il programma e i dati. Se questa è disponibile, l’ambiente di sviluppo è performante anche su macchine non recentissime. Molti utenti però si accorgono che, con progetti grandi e utilizzando più funzionalità contemporaneamente, l’IDE rallenta. Da qui la necessità di ottimizzarne le prestazioni.
Nota: questo blog spiega come velocizzare NetBeans, non come ottimizzare un generico programma Java. Certe considerazioni hanno comunque carattere generale e possono tornare utili in altri contesti.
Il file nebeans.conf
Il file netbeans.conf regola l’avvio e la configurazione di basso livello di NetBeans. Si trova nella directory etc dell’installazione NetBeans.
Su una macchina Linux, la posizione precisa potrebbe essere /opt/netbeans-5.5/etc
Su un Mac tipicamente è /Applications/NetBeans/NetBeans 6.0.1.app/Contents/Resources/Netbeas/etc
Userò questo file nelle prossime sezioni. Ogni volta che si modifica il file bisogna ricordarsi di far ripartire l’IDE.
Garbage collection
Il GC comincia a farsi notare (negativamente) quando si hanno molti file aperti nell’editor. Passando da un file all’altro, l’IDE si blocca per un secondo o anche più.
Per eliminare il problema bisogna individuare il parametro netbeans_defaul_options in netbeans.conf ed aggiungere la seguente stringa di valori:
-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled
Sul wiki di Netbeans spiegano che questa impostazione è accesa di default in NetBeans 6.0. Guardando il netbeans.conf che ho io non mi risulta che sia così ma ci potrebbero essere altre impostazioni di cui non sono a conoscenza. Comunque su Netbeans 5.5 l’impostazione che ho indicato funziona sicuramente e su NetBeans 6.0 può essere utilizzata come “cintura e bretelle”.
Aumentare la memoria
Se si includono molte librerie nel proprio progetto è necessario aumentare la memoria per permettere a NetBeans di caricare in modo efficiente dati e metadati relativi alle librerie (p.e., al fine del completamento automatico quando si scrivono invocazioni di metodi).
Di nuovo editiamo netbeans.conf e aggiungiamo -Xmx=256m per assegnare 256 MB di heap a NetBeans.
Passare a Java SE 6
L’ottimizzazione più semplice è questa: basta passare a Java SE 6 più recente per avere notevoli miglioramenti nella qualità e nella velocità dell’interfaccia grafica. E’ un notevole passo avanti rispetto a J2SE 5.0.
Fra i miglioramenti: una migliore risposta degli alberi di navigazione (progetto e file), anti-aliasing dei font migliore, pannelli di log più veloci e con minor rischio di bloccarsi quando il contenuto è grande.
Per cambiare JDK bisogna editare netbeans.conf e modificare il parametro netbeans_jdkhome impostandolo al percorso assoluto dove avete installato la JDK. Notate che eventuali impostazioni della variabile d’ambiente JAVA_HOME da shell NON ha effetti su NetBeans.
Unica nota dolente: gli utenti Mac non hanno a disposizione SE 6. Aspettiamo e speriamo che la Apple si sbrighi a fornire questo aggiornamento.
Problemi di compatibilità
Bene, abbiamo configurato NetBeans per utilizzare Java SE 6. Avviamo NetBeans, apriamo il nostro progetto preferito e (orrore!) scopriamo che non compila più.
Faccio un esempio. Una nostra classe MyResultSet implementa l’interfaccia java.sql.ResultSet. In Java SE 6 l’interfaccia ha acquisito numerosi metodi nuovi (p.e., updateNClob()) e la nostra classe, che prima non li implementava, risulta incompleta rispetto all’interfaccia.
La soluzione di istinto è quella di modificare MyResultSet e quindi di migrare da una vecchia API a quella di SE 6. Per fare questo basta aggiungere i metodi mancanti a MyResultSet e ricompilare.
Purtroppo essere sulla JDK più recente è un lusso che pochi si possono permettere. In ambito J2EE ci sono application server (tipo IBM WebSphere) che vivono su J2SE 5.0 e molte installazioni sono e rimangono su J2SE 1.4. Se avete mai avuto un errore “class file has wrong version 49.0, should be 48.0″ su un ambiente runtime sapete di cosa sto parlando.
Cosa fare quindi? La soluzione migliore è far girare NetBeans sulla versione più recente del JDK (per motivi di prestazioni come spiegato nella precedente sezione) ma compilare il nostro codice per la versione più compatibile per l’ambiente runtime in cui andrà utilizzata.
NetBeans di base compila utilizzando la stessa JDK in cui sta girando. Se NetBeans usa SE 6, anche il nostro codice sarà compilato per SE 6. Per cambiare questa impostazione bisogna andare nel menu Tools->Java Platforms. Da qui possiamo controllare ed aggiungere tutte le versioni di JDK che vogliamo. Per aggiungerne una, premere “Add platform…” e fornire il percorso alla directory di installazione del JDK desiderato.
Per effettivamente utilizzare una certa versione nel nostro progetto, bisogna andare nelle properties del progetto e quindi:
- dal tab “sources” impostare “Source/Binary Format” per quanto riguarda la compatibilità del codice sorgente e delle classi generate
- dal tab “libraries” impostare “Java platform” per quanto riguarda l’API da utilizzare.
Compilazione e compatibilità fuori da NetBeans
La gestione della piattaforma è una comodità di NetBeans. Fuori da NetBeans, bisogna arrangiarsi diversamente. Qui tornano utili i parametri di javac, il compilatore incluso nella JDK. In particolare:
- “-source release” controlla la compatibilità del linguaggio, quindi del codice che si scrive;
- “-target version” controlla la compatibilità binaria delle classi generate dal compilatore;
- “-bootclaspath bootclasspath” controlla quale API utilizzare per la compilazione. Qui vanno indicati i jar presenti in una qualunque JDK installata sul sistema ma diversa da quella a cui il comando javac appartiene.
Devo ancora guardare i dettagli di questo approccio, specialmente con script ant e maven. E’ un po’ contorto ma sicuramente utile se si vuole controllare con precisione la compatibilità in compilazione.
Post-scriptum
Ho cercato in questo blog di usare i nomi più corretti per le versioni delle JDK. Non è una cosa banale visto quante volte la Sun ha cambiato convenzione dei nomi. C’è però una utilissima pagina su Wikipedia che chiarisce bene le versioni di Java che ho utilizzato e che ringrazio.
