Smemoratezze dal sottosuolo

Installare Java

Java è un linguaggio di programmazione creato da Sun, ma le sue specifiche sono aperte: ne esistono quindi implementazioni sviluppate indipendentemente, ad esempio da IBM o dal Progetto GNU. In questa mini panoramica considereremo tuttavia principalmente le release di Sun, per ridurre la (comunque presente) confusione.

J2RE, J2SE, J2EE, J2ME

La maggior parte delle persone ha al piú a che fare con il J2RE, Java Runtime Environment. Questo pacchetto contiene eseguibili e librerie sufficienti a eseguire qualsiasi applicazione Java, a patto che sia stata sviluppata su una versione di java compatibile – può infatti succedere che tra una release e l’altra nascano nuove funzionalità non presenti nelle release precedenti; la soluzione è ovviamente tenersi sempre aggiornati.

Gli sviluppatori java hanno forzatamente a che fare con J2SE, Java 2 Standard Edition, altrimenti detto J2SDK (Java 2 Software Development Kit). Questo pacchetto contiene un J2RE completo (solitamente nella sottocartella \jre), e vi aggiunge intorno librerie ed eseguibili utili allo sviluppo (per compilare, creare documentazione, creare archivi, ecc.).

Per chi poi debba sviluppare in ambito web (lato server), potrebbe essere necessario l’utilizzo di J2EE, Java 2 Enterprise Edition. Qui tuttavia Sun molla un po’ le briglie: la sua implementazione del J2EE è qualcosa di utilizzabile in produzione, ma al contempo quasi un “Proof of concept”. La cosa è comprensibile, poiché sappiamo come la rete sia la frusta del programmatore, sia a livello di complessità che a quello di sicurezza – e in questo campo la varietà è un bene.

L’implementazione di Sun del suo J2EE si chiama Application Server, ma altre implementazioni complete delle specifiche sono, per fare esempi, Geronimo e JBoss. Per chi si accontenta di un server web con supporto a java, che però non implementa per intero J2EE, c’è Tomcat.

Casomai abbiate deciso di installare il pacchetto J2EE tutto-compreso di Sun, probabilmente troverete anche J2SE nella sottocartella \jdk (e quindi troverete il J2RE nella sottocartella \jdk\jre). Potete tuttavia scaricare e installare Application Server separatamente, o non installarlo per nulla e usare una delle alternative – la scelta sta a voi.

In caso abbiate bisogno di sviluppare, o eseguire in emulazione applicazioni per cellulari e PDA, potreste avere a che fare con J2ME, Java 2 Micro Edition, la cui trattazione dettagliata si eviterà in questa sede.

Installare Java e impostare il sistema operativo (variabili d’ambiente)

L’installazione in sé dei vari pacchetti è piuttosto lineare. Scegliete quale versione è di vostro interesse (solo il runtime, il developer’s kit, application server), scegliete al limite dove posizionarla (in windows attualmente ho java in queste cartelle: C:\Java\j2eesdk-1_4_03\jdk\jre). E’ possibile che l’installazione vi aggiorni automaticamente la variabile di sistema PATH (verificate se lo faccia solo per l’utente corrente o per tutti); in caso contrario dovrete impostarla voi.

Impostarla come?

Perché le applicazioni java si avviino, è necessario che java.exe e javaw.exe siano nel path. Per far questo, bisogna modificare la variabile relativa (%PATH% in Windows, $PATH in linux e parenti) e aggiungere alla sua lista (fatta di cartelle inframezzate da un separatore, “;” in windows e “:” in linux) la cartella \jre\bin (jre è dove avete installato il vostro Java Runtime Environment). Se siete sviluppatori e avete installato J2SE, risparmiatevi la fatica e mettete invece nel path la cartella \jdk\bin, che oltre a java.exe e javaw.exe conterrà javac.exe, jar.exe e tante altre utilities interessanti. Per J2EE non sono necessarie altre modifiche del PATH.

Nota: la variabile PATH viene letta dal sistema operativo da sinistra a destra. Sarebbe a dire che se ci sono 3 cartelle, PATH=”cartella1:cartella2:cartella3″, e la prima e l’ultima contengono entrambe un eseguibile “java.exe”, sarà l’eseguibile presente nella prima cartella ad essere richiamato se proverete a lanciare java.exe da una posizione arbitraria. Tenetene conto, se installate piú JVM (Java Virtual Machine) sulla stessa macchina.

Rimane solo da modificare, o creare, la variabile CLASSPATH (%CLASSPATH% o $CLASSPATH). Mentre in release passate di Java era necessario inserire nel CLASSPATH la posizione del J2SDK, ora questa è riconosciuta automaticamente da javac; rimane però da aggiungere, se non presente nella variabile, “.”, sarebbe a dire “la cartella corrente”. Da aggiungere anche, in alcuni dei casi in cui si usano strumenti esterni come ant, la posizione del file “rt.jar”. Un possibile esempio di variabile CLASSPATH: “C:\Java\j2eesdk-1_4_03\jdk\jre\lib\rt.jar;.”.

Se avete fatto tutto bene, ora dovreste avere un’installazione di java funzionante!

Usare Ant

Ant, tra gli strumenti di aiuto per lo sviluppo, è forse uno dei più divertenti. Per chi si diverte con queste cose, ovvio. Esso permette di automatizzare facilmente operazioni come la sincronizzazione di file, la compilazione di sorgenti, la creazione di archivi .jar, di documentazione javadoc, e molte altre cose. Vedere il manuale per maggiori dettagli.

Essendo io mediamente pigro, e sommamente pigro per le operazioni ripetitive, ho creato due buildfile ant per eseguire in modalità batch le seguenti operazioni:

1. ottenere i sorgenti del progetto dal workspace di eclipse e copiarli in una cartella di destinazione (C:\Progetti\NomeProgetto\NomeProgettoSource)
2. compilare i sorgenti in una seconda cartella (C:\Progetti\NomeProgetto\NomeProgettoBuild)
3. creare un .jar e tutto ciò che andrà messo in produzione in una terza cartella (C:\Progetti\NomeProgetto\NomeProgetto)
4. creare la javadoc in una quarta cartella (C:\Progetti\NomeProgetto\NomeProgettoDoc)

Il primo buildfile è per applicazioni Java generiche, mentre il secondo è per servlet (e con qualche modifica anche generiche applicazioni J2EE).

Perchè i buildfile funzionino, devono esistere i file esterni indicati nei tag “loadfile”. Il buildfile ant viene eseguito all’interno della cartella del progetto, e pertanto dovrebbe essere lì presente, ma una buona idea è crearsi un file .bat che come prima cosa copi il buildfile da un posto specifico (ad esempio dalla cartella padre), in modo che tutti i progetti possano sempre beneficiare di ogni eventuale nuova modifica fatta.

Uno schema è più utile di tante parole. Ecco la possibile struttura di un mio computer windows configurato per lo sviluppo (soprattutto in java), grazie al quale potete capire con un colpo d’occhio quali modifiche potrebbero essere necessarie nei buildfile (rilevanti soprattutto le risorse contrassegnate come INPUT, ma potrebbe interessarvi anche l’OUTPUT):

[C:]

• [Java]
  • [eclipse] (cartella di installazione di eclipse)
  • [eclipse-progetti] (cartella contenente i progetti di eclipse)
    • [NomeProgettoJava] (cartella di un generico progetto Java – INPUT)
      • [lib] (librerie del progetto – opzionale – LIB)
    • [NomeProgettoJavaServlet] (cartella di un progetto Java Servlet – INPUT)
      • [src] (cartella contenente i sorgenti)
      • [WebContent] (root del context)
      • • [WEB-INF]
        • • [lib] (cartella contenente le librerie della web application – LIB)
  • [Tomcat 5.5] (cartella di installazione di Tomcat – LIB)
• [Progetti]
  • [NomeProgetto] (cartella di un generico progetto Java)
    • [NomeProgettoJava] (cartella contenente tutto il necessario per la messa in produzione – OUTPUT)
    • [NomeProgettoJavaBuild] (cartella contenente tutti i file .class derivanti dalla compilazione – OUTPUT)
    • [NomeProgettoJavaDoc] (cartella contenente la documentazione – OUTPUT)
    • [NomeProgettoJavaSource] (cartella contenente i sorgenti .java – OUTPUT)
    • ant_build.bat (batch che copia il buildfile dalla cartella superiore ed esegue ant)
    • ant_name_of_project.txt (contiene NomeProgettoJava)
    • javadoc_overview.htm (l’overview del javadoc – opzionale – INPUT)
  • [NomeProgettoServlet] (cartella di un progetto Java Servlet)
    • [NomeProgettoJavaServlet] (cartella contenente tutto il necessario per la messa in produzione – OUTPUT)
    • [NomeProgettoJavaServletBuild] (cartella contenente tutti i file .class derivanti dalla compilazione – OUTPUT)
    • [NomeProgettoJavaServletDoc] (cartella contenente la documentazione – OUTPUT)
    • [NomeProgettoJavaServletSource] (cartella contenente i sorgenti .java – OUTPUT)
    • ant_build_j2ee.bat (batch che copia il buildfile dalla cartella superiore ed esegue ant)
    • ant_name_of_project.txt (contiene NomeProgettoJavaServlet)
    • javadoc_overview.htm (l’overview del javadoc – opzionale – INPUT)
  • ant_build_generic.xml (buildfile per progetti java generici)
  • ant_build_j2ee.xml (buildfile per progetti J2EE)
  • ant_path_j2ee_libs.txt (contiene il path in cui si trova l’implementazione di J2EE usata)
  • ant_path_java_sources_root.txt (contiene il path della radice sotto la quale si trovano i progetti java – ad esempio workspace di Eclipse)

NOTA: non linkate direttamente i file, ma tutta questa pagina. Non è per far dispetto, ma se ne creassi versioni successive potrebbero venire caricate in una cartella, e quindi a una URL, diversa. Sto considerando se cambiare o meno questo comportamento di WordPress.
(continua…)