[JAVA] CLASSPATH failure

[Premier]

Salve,
ho un problema con la variabile CLASSPATH. In pratica non serve a nulla, ossia il valore ivi contenuto non è analizzato dal sistema.

Io ho Windows XP HE e Java 1.6.0.

La variabile CLASSPATH vale

.;C:\Programmi\Java\jre1.6.0\lib\ext\QTJava.zip;C:\Programmi\Java\jdk1.6.0\bin;D:\Programmazione\Java\myPackages;c:\programmi\java\jdk1.6.0\bin

ma nonostante ciò quando da shell lancio

"javac ..."

mi dice che il comando non è riconosciuto come comando di sistema.
Inoltre da eclipse, quando richiamo un mio package, mi dice che il nome non è risolvibile.

Come faccio??

[PGI-Bis]

Per far riconoscere il comando javac (e tutti quelli che arrivano col JDK) la variabile da creare/modificare è PATH. CLASSPATH non si usa più e puoi rimuoverla.

PATH=.;C:\Programmi\Java\jdk1.6.0\bin

Se hai altre cose nella variabile path, aggiungi "C:\Programmi\Java\jdk1.6.0\bin" in fondo.

[andbin]

Originariamente inviato da Premier

In pratica non serve a nulla, ossia il valore ivi contenuto non è analizzato dal sistema.

Certo che serve!!!

Originariamente inviato da Premier

ma nonostante ciò quando da shell lancio

"javac ..."

mi dice che il comando non è riconosciuto come comando di sistema.

Certo! Perché per gli eseguibili c'entra la variabile PATH, non CLASSPATH (che vale solo per le directory/file jar relativi a classi Java).

Originariamente inviato da Premier

Inoltre da eclipse, quando richiamo un mio package, mi dice che il nome non è risolvibile.

Non conosco Eclipse ma molto probabilmente usa un "suo" classpath in base a come è configurato l'ambiente e/o il progetto.

[yorkeiser]

Originariamente inviato da PGI-Bis

CLASSPATH non si usa più e puoi rimuoverla.

Davvero?
Scusa, i jar e i class dove se li va a pescare adesso?

[Premier]

D'accordo allora includendo la stringa c:\programmi\java\jdk1.6.0\bin in path ho finalmente risolto il problema di javac.

Ma come risolvo quello più serio di eclipse che non mi vede le cartelle appartenenti alla CLASSPATH?

Grazie.

[PGI-Bis]

Dove li ha sempre presi a partire da Java 1.2, versione in cui fu introdotto il meccanismo di estensione standard della piattaforma Java che dichiarò obsoleta la variabile d'ambiente CLASSPATH. Roba di otto anni fa, direi.

[ps] rispondevo alla richiesta "dove li prende adesso i jar"

[PGI-Bis]

Originariamente inviato da Premier

D'accordo allora includendo la stringa c:\programmi\java\jdk1.6.0\bin in path ho finalmente risolto il problema di javac.

Ma come risolvo quello più serio di eclipse che non mi vede le cartelle appartenenti alla CLASSPATH?

Grazie.

Non so indicarti con precisione i percorsi ma Eclipse ha due "proprietà" impostabili per individuare librerie che non sono estensioni della piattaforma Java. Una dovrebbe essere globale dell'IDE e una relativa al singolo progetto. Prova a frugare nelle impostazioni dell'IDE (proprietà, configurazione o una cosa del genere) e cerca qualcosa tipo "librerie esterne" o "estensioni". Troverai una procedura guidata o un pannello che ti permetterà di specificare dove l'IDE debba cercare librerie aggiuntive. Putroppo non ho eclipse sottomano al momento e non so essere più preciso.

[Premier]

Scusa a questo punto mi sorge un dubbio:

a cosa serve la variabile CLASSPATH?

[andbin]

Originariamente inviato da Premier

a cosa serve la variabile CLASSPATH?

Tutto spiegato <qui> (per Win).

[PGI-Bis]

Ai tempi dei tempi, la variabile CLASSPATH conteneva i percorsi delle librerie (i file jar) che non appartenevano alla piattaforma standard.

Ad esempio creavi un'applicazione col suo bel jar che usava delle classi del package pippo e giovanni, contenute in due jar, Pippo.jar e Giovanni.jar, trovati su internet che non erano inclusi nella piattaforma Java.

Per far trovare alla macchina virtuale le classi contenute in Pippo.jar e Giovanni.jar dovevi o indicare esplicitamente il percorso dei file Pippo.jar e Giovanni.jar o usare un'estensione di ClassLoader ad hoc o includere il percorso della cartella che conteneva i due jar nella variabile d'ambiente CLASSPATH.

Il che era evidentemente impraticabile: nessuno può seriamente pretendere che l'utente di un'applicazione si metta a modificare una variabile d'ambiente.

La faccenda fu risolta adottando un meccanismo standard di estensione della piattaforma Java. Trovi i dettagli nella documentazione standard della piattaforma Java. La punta dell'iceberg sta nella possibilità di specificare tramite l'attributo Class-Path del file manifest di un jar il percorso delle librerie che estendono la piattaforma java e nella possibilità di caricare librerie dinamiche (dll, so) pescandole dalla directory in cui si trova il jar dell'applicazione. La faccenda è poi più articolata perchè consente di stabilire delle dipendenze tra jar diversi e versioni diverse di una stessa estensione.