Discussion :

[TigreDeau]

Bonjour,

Tout d'abord, je précise que j'ai lu la résolution de ce même problème sur le forum mais cela n'a pas résolu mon cas ... (et ce problème énerve un peu ).

Je pense avoir tout vérifié (mais forcément non !) et j'ai toujours ce même message d'erreur au lancement.

- les mêmes fichiers ne posent pas de problème en lançant sous Eclipse mais je veux savoir pourquoi ça bloque avec javac.

- C'est un projet assez basic (sujet assez compliqué mais petit projet de test)
- Toutes mes sources sont dans un unique répertoire
- Il y a 4 import dans le fichier comportant le main
- le .class a bien été généré.

où dois-je regarder svp ?? (oscour !)

[thelvin]

Hello,

pour commencer il aurait fallu montrer les fichiers et la commande...

D'ailleurs quand on a problème de ce genre, on commence par regarder ce que ça donne avec un seul fichier.

[TigreDeau]

Merci thelvin pour les suggestions.

Le code était simple mais j'ai réduit à un seul fichier et voici la situation :

MonProg.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class MonProg {
 
public static void main(String[] args) throws Exception {
 
        System.out.println("OK");
    }
}

- J'ouvre une fenêtre par cmd.exe et je me place dans le répertoire où se trouve MonProg.java (il n'y a que ce fichier dans le répertoire)
- Je compile par : javac MonProg.java => aucun message d'erreur et MonProg.class est généré.
- je lance l'exécution par : java MonProg => message d'erreur : Erreur : impossible de trouver ou charger la classe principale MonProg

J'utilise Java version 1.8.0_321

[thelvin]

Tu as probablement une variable CLASSPATH définie quelque part dans ton OS, ce qui empêche de lancer les programmes comme ça.

A la place, il va falloir indiquer que le classpath dans lequel trouver ta classe, c'est le répertoire en cours :

Code commande shell :

Sélectionner tout - Visualiser dans une fenêtre à part

java -classpath . MonProg

... Ou alors trouver où est définie cette variable CLASSPATH et l'effacer.

[TigreDeau]

Effectivement, j'avais un classpath qui pointait vers une librairie.
Je l'ai supprimé et maintenant cela fonctionne. Donc, déjà un grand merci !

Cela m'amène à deux questions :

1. Je ne comprends pas pourquoi ce classpath est la cause. Le classpath ne sert pas à déclarer une librairie complémentaire au programme que l'on veut exécuter ?

2. et aussi, je vais avoir besoin de librairie complémentaire qui se trouve ailleurs que le répertoire contenant (la classe contenant) le main. Le classpath ne sert pas à cela ?

[thelvin]

1. Je ne comprends pas pourquoi ce classpath est la cause. Le classpath ne sert pas à déclarer une librairie complémentaire au programme que l'on veut exécuter ?

Non. C'est pour le cas où on ne veut pas utiliser le paramètre -classpath (ou l'équivalent raccourci -cp). De manière générale, il est plus ou moins reconnu comme mauvaise idée de se servir de la variable CLASSPATH, et c'est plutôt un reliquat de l'époque où on installait du Java sans qu'il y ait de connaissance sur comment faire.

Lorsqu'on lance la commande "java" sans fournir aucun classpath, par défaut le classpath c'est le répertoire courant. Mais si on fournit un classpath par la variable CLASSPATH ou par le paramètre -classpath, alors il n'y a bien sûr pas de classpath par défaut. D'où le fait que cette variable CLASSPATH gêne le fonctionnement normal quand on fait des manipulations simples.

2. et aussi, je vais avoir besoin de librairie complémentaire qui se trouve ailleurs que le répertoire contenant (la classe contenant) le main. Le classpath ne sert pas à cela ?

Si, complètement. Il faudra indiquer dans le classpath, le répertoire vers les classes compilées, et les bibliothèques tierces que tu utilises.

Le classpath indique tous les endroits où chercher les classes dont le programme a besoin.

A noter que c'est très bien d'apprendre les fondamentaux avec la ligne de commande. Mais une fois qu'on travaille sur de vrais projets, on utilise plutôt NetBeans, Eclipse ou IntelliJ, avec Maven ou gradle en gestion de dépendances, qui s'occupent de nous dédouaner de gérer les choses de la ligne de commande (et bien d'autres.)