Newsgroup: it.comp.java
Titolo: [WINDOWS]-Sulla variabile di sistema CLASSPATH e problemi Javadoc

Ciao a tutti, sono alle prime armi con java e, dopo avere un po' usato 
l'sdk 1.5 l'anno scorso, ho installato l'ultima versione poche settimane 
fa avendo degli errori "java.lang.IllegalArgumentException" lanciando 
javadoc. L'anno scorso con la versione 1.5.x javadoc non mi dava problemi.
Ho allora cercato con Google e seguendo il suggerimento di togliere " 
%CLASSPATH% " dalla lista di percorsi indicati nella variabile CLASSPATH 
del mio sistema operativo (Windows XP) riavviando (senza riavviare il PC 
javadoc continuava a dare lo stesso errore) sono riuscito a far 
compilare correttamente a javadoc la documentazione di un mio progettino 
di prova.
LA MIA DOMANDA E': cosa comporta l'aver rimosso " %CLASSPATH% " dalla 
variabile di sistema CLASSPATH? Posso andare avanti cosě o per certe 
operazioni dovrň rimetterlo (a quel punto mi tornerebbe perň il problema 
con javadoc se non trovo una soluzione alternativa)?
  ciao e grazie anticipatamente per le risposte
-- 
Google Image Labeler cumulative score: 72600

 ciao e grazie anticipatamente per le risposte
ciao
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Ma non è vero.
Io invece sono d'accordo con n.n.
-- 
Andrea Francia
http://www.andreafrancia.it/

 Io invece sono d'accordo con n.n.
Ciao
Giusto per non laciare la discussione cosi' radicale, il motivo per cui si
suggerisce non usare la classpath e' il seguente :
Una applicazione gira in una VM. Questa VM viene settata per accedere a 1 o
piu' suoi classpath. Spesso sono parecchi come nel caso delle WebApp
Se c'e' il classpath :
1. Spesso ci si dimentica l'ordine con cui si va prima al classpath della VM
e poi al quello di ambiente. ( Io ora non lo so perche' non uso la classpath
da 10 anni :) )
2. Lavorando in team il progetto non e' sharabile su un version repository
in modo completo, poiche' la variabile non e' sharabile
3. Quando si installa bisogna ricordarsi di settare il classpath
4. Quando si installa non e' detto che si hanno i privilegi per accedere
all'env
5. Quando si programma si diventa scemi a ricordarsi/capire se stiamo
accedendo al classpath di applicazione o di env
6. Se 2 o piu' applicazioni sono progettate con l' uso dell'env non possono
agire sulla stessa macchina ( legittimo dubbio dell'OP )
7. ...................... potrei andare avanti
ciauz Nicola


 suggerisce non usare la classpath e' il seguente :
Per sitentizzare il discorso di nicola9000 il problema di usare una 
variabile d'ambiente a livello di sistema come CLASSPATH è un problema 
perché è potrebbe essere condivisa da applicazione che potrebbero voler 
accedere a classi diverse.
E piu' comodo tenere un CLASSPATH diverso per ogni applicazione.
Di solito questo è inserito nello script che invoca l'eseguibile 'java' 
oppure nel file JNLP, o nel manifest del JAR.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/relazioni-molti-molti-con-jpa.html

 jar della jvm.
Mi stai dicendo che metti nel CLASSPATH tutti i jar presenti sotto 
c:\program files\Java\jre\lib ?
Se è così stai facendo un lavoro inutile, quella cosa si faceva fino al 
Java 1.1. o forse Java 1.2, prima che introdussero il BOOTCLASSPATH.
Adesso l'utente deve solo specificare i .jar delle librerie usate dal 
programma che *non* già dentro il JRE.
