web-dev-qa-db-fra.com

Que signifie "Impossible de trouver ou de charger la classe principale"?

Un problème courant rencontré par les nouveaux développeurs Java est que leurs programmes ne s'exécutent pas avec le message d'erreur suivant: Could not find or load main class ...

Qu'est-ce que cela signifie, qu'est-ce qui le cause et comment devriez-vous le réparer?

javaclassmain
1220
Stephen C

La syntaxe de la commande Java <class-name>

Tout d'abord, vous devez comprendre la bonne façon de lancer un programme à l'aide de la commande Java (ou javaw).

La syntaxe normale1 est-ce:

    Java [ <option> ... ] <class-name> [<argument> ...]

où <option> est une option de ligne de commande (commençant par un caractère "-"), <class-name> est un nom de classe qualifié Java et <argument> est une commande arbitraire. argument de ligne qui est passé à votre application.
1 - Il existe une deuxième syntaxe pour les fichiers JAR "exécutables" que je décrirai plus bas.

Le nom complet de la classe (FQN) est généralement écrit comme vous le feriez dans le code source Java. par exemple.

    packagename.packagename2.packagename3.ClassName

Toutefois, certaines versions de la commande Java vous permettent d'utiliser des barres obliques au lieu de points. par exemple.

    packagename/packagename2/packagename3/ClassName

qui (déroutant) ressemble à un chemin de fichier, mais n'en est pas un. Notez que le terme nom complet ​​est standard Java terminologie ... pas quelque chose que je viens de créer pour vous embrouiller :-)

Voici un exemple de ce à quoi une commande Java devrait ressembler:

    Java -Xmx100m com.acme.example.ListUsers fred joe bert

Ce qui précède va entraîner la commande Java:

  1. Recherchez la version compilée de la classe com.acme.example.ListUsers.
  2. Chargez la classe.
  3. Vérifiez que la classe a une méthode main avec signature, type de retour et modificateurs donné par public static void main(String[]). (Notez que le nom de l'argument de la méthode est PAS une partie de la signature.)
  4. Appelez cette méthode en lui passant les arguments de ligne de commande ("fred", "joe", "bert") en tant que String[].

Raisons pour lesquelles Java ne trouve pas la classe

Lorsque vous recevez le message "Impossible de trouver ou de charger la classe principale ...", cela signifie que la première étape a échoué. La commande Java n'a pas pu trouver la classe. Et en effet, le "..." dans le message sera le nom de classe complet ​​que Java cherche.

Alors, pourquoi pourrait-il être incapable de trouver la classe?

Raison n ° 1 - vous avez commis une erreur avec l'argument classname

La première cause probable est que vous avez peut-être fourni un nom de classe incorrect. (Ou ... le bon nom de classe, mais sous une forme erronée.) Considérant l'exemple ci-dessus, voici une variété de mauvaises manières de spécifier la classe. Nom:

  • Exemple # 1 - un nom de classe simple:

    Java ListUser

    Lorsque la classe est déclarée dans un package tel que com.acme.example, vous devez utiliser le nom de classe complet y compris le nom du package dans la commande Java; par exemple.

    Java com.acme.example.ListUser

  • Exemple # 2 - un nom de fichier ou un chemin d'accès plutôt qu'un nom de classe:

    Java ListUser.class
Java com/acme/example/ListUser.class

  • Exemple # 3 - un nom de classe avec une casse incorrecte:

    Java com.acme.example.listuser

  • Exemple n ° 4 - une faute de frappe

    Java com.acme.example.mistuser

  • Exemple # 5 - un nom de fichier source

    Java ListUser.Java

  • Exemple # 6 - vous avez complètement oublié le nom de la classe

    Java lots of arguments

Raison n ° 2 - le chemin d'accès aux classes de l'application n'est pas spécifié correctement

La deuxième cause probable est que le nom de la classe est correct mais que la commande Java ne peut pas trouver la classe. Pour comprendre cela, vous devez comprendre le concept de "classpath". Ceci est expliqué bien par la documentation Oracle:

Donc ... si vous avez correctement spécifié le nom de la classe, la prochaine chose à vérifier est que vous avez correctement spécifié le chemin de la classe:

  1. Lisez les trois documents liés ci-dessus. (Oui ... LISEZ-LES. Il est important qu'un programmeur Java comprenne au moins les bases du fonctionnement des mécanismes de chemin de classe Java.)
  2. Examinez la ligne de commande et/ou la variable d’environnement CLASSPATH en vigueur lorsque vous exécutez la commande Java. Vérifiez que les noms de répertoire et les noms de fichier JAR sont corrects.
  3. S'il y a des noms de chemins relatifs dans le chemin d'accès aux classes, vérifiez qu'ils ont été résolus correctement ... à partir du répertoire actuel pris en compte lorsque vous exécutez la commande Java.
  4. Vérifiez que la classe (mentionnée dans le message d'erreur) peut être située sur le chemin de classe effective.
  5. Notez que la syntaxe du chemin d'accès aux classes est différente pour Windows par rapport à Linux et Mac OS. (Le séparateur de chemin de classe est ; sous Windows et : sous les autres. Si vous utilisez le mauvais séparateur pour votre plate-forme, vous n'obtiendrez pas de message d'erreur explicite. Vous obtiendrez plutôt un fichier inexistant. ou répertoire sur le chemin qui sera silencieusement ignoré.)

Raison n ° 2a - le mauvais répertoire est sur le classpath

Lorsque vous placez un répertoire sur le chemin d'accès aux classes, il correspond théoriquement à la racine de l'espace de noms qualifié. Les classes sont situées dans la structure de répertoires située sous cette racine, en mappant le nom qualifié complet sur un chemin. Ainsi, par exemple, si "/ usr/local/acme/classes" figure dans le chemin de classe, lorsque la machine virtuelle recherche une classe appelée com.acme.example.Foon, elle recherche un fichier ".class" avec ce chemin:

  /usr/local/acme/classes/com/acme/example/Foon.class

Si vous aviez placé "/ usr/local/acme/classes/com/acme/exemple" sur le chemin d'accès aux classes, la machine virtuelle Java ne pourrait pas trouver la classe.

Raison n ° 2b - le chemin du sous-répertoire ne correspond pas au FQN

Si votre classe FQN est com.acme.example.Foon, la machine virtuelle Java recherchera "Foon.class" dans le répertoire "com/acme/example":

  • Si la structure de votre répertoire ne correspond pas à la dénomination du paquet conformément au modèle ci-dessus, la machine virtuelle Java ne trouvera pas votre classe.

  • Si vous essayez renommer une classe en la déplaçant, cela échouera également ... mais l'exception stacktrace sera différente. Il est susceptible de dire quelque chose comme ceci:

    Caused by: Java.lang.NoClassDefFoundError: <path> (wrong name: <name>)

    car le FQN dans le fichier de classe ne correspond pas à ce que le chargeur de classes s'attend à trouver.

Pour donner un exemple concret, en supposant que:

  • vous voulez exécuter la classe com.acme.example.Foon,
  • le chemin complet du fichier est /usr/local/acme/classes/com/acme/example/Foon.class,
  • votre répertoire de travail actuel est /usr/local/acme/classes/com/acme/example/,

ensuite:

# wrong, FQN is needed
Java Foon

# wrong, there is no `com/acme/example` folder in the current working directory
Java com.acme.example.Foon

# wrong, similar to above
Java -classpath . com.acme.example.Foon

# fine; relative classpath set
Java -classpath ../../.. com.acme.example.Foon

# fine; absolute classpath set
Java -classpath /usr/local/acme/classes com.acme.example.Foon

Remarques:

  • L'option -classpath peut être réduite à -cp dans la plupart des versions de Java. Vérifiez les entrées manuelles respectives pour Java, javac et ainsi de suite.
  • Réfléchissez bien lorsque vous choisissez un chemin absolu ou relatif dans un chemin de classe. Rappelez-vous qu'un chemin relatif peut "se rompre" si le répertoire en cours change.

Raison n ° 2c - Dépendances manquantes dans le classpath

Le chemin de classe doit inclure toutes les autres (non-systèmes) classes dont dépend votre application. (Les classes système sont automatiquement localisées et vous devez rarement vous en préoccuper.) Pour que la classe principale soit chargée correctement, la machine virtuelle Java doit rechercher:

(Remarque: les spécifications JLS et JVM permettent à une machine virtuelle de charger des classes "paresseusement", ce qui peut avoir une incidence sur le déclenchement d'une exception de chargeur de classe.)

Raison n ° 3 - la classe a été déclarée dans le mauvais paquet

Il arrive parfois que quelqu'un mette un fichier de code source dans le mauvais dossier de son arborescence, ou omette la déclaration package. Si vous faites cela dans un IDE, le compilateur de l'EDI vous en informera immédiatement. De même, si vous utilisez un outil de construction correct Java, l'outil exécutera javac de manière à détecter le problème. Cependant, si vous construisez votre code Java à la main, vous pouvez le faire de sorte que le compilateur ne remarque pas le problème et que le fichier ".class" résultant ne se trouve pas à la place attendez-vous à ce qu'il le soit.

Vous ne trouvez toujours pas le problème?

Il y a beaucoup de choses à vérifier, et il est facile de rater quelque chose. Essayez d’ajouter l’option -Xdiag à la ligne de commande Java (en premier lieu après Java). Il produira diverses informations sur le chargement de classe, ce qui peut vous donner des indices sur le problème réel.

En outre, envisagez les problèmes éventuels liés au copier-coller de caractères invisibles ou non-ASCII à partir de sites Web, de documents, etc. Et considérons les "homoglyphes", où deux lettres ou symboles se ressemblent ... mais ne le sont pas.

La syntaxe Java -jar <jar file>

La syntaxe alternative utilisée pour les fichiers JAR "exécutables" est la suivante:

  Java [ <option> ... ] -jar <jar-file-name> [<argument> ...]

par exemple.

  Java -Xmx100m -jar /usr/local/acme-example/listuser.jar fred

Dans ce cas, le nom de la classe de point d'entrée (c'est-à-dire com.acme.example.ListUser) et le chemin d'accès aux classes sont spécifiés dans le MANIFEST du fichier JAR.

IDEs

Un Java IDE typique prend en charge l'exécution d'applications Java dans la JVM IDE ou dans une JVM enfant. Ceux-ci sont généralement ​​à l'abri de cette exception particulière, car la IDE utilise ses propres mécanismes pour construire le chemin d'accès aux classes à l'exécution, identifier la classe principale et créer la ligne de commande Java.

Cependant, il est toujours possible que cette exception se produise si vous effectuez des tâches dans le dos de l'EDI. Par exemple, si vous avez déjà configuré un programme de lancement d'applicatifs pour votre application Java dans Eclipse, puis que vous avez déplacé le fichier JAR contenant la classe "principale" vers un emplacement différent dans le système de fichiers: sans le dire à Eclipse, Eclipse lancerait involontairement la machine virtuelle Java avec un chemin d'accès aux classes incorrect.

En bref, si vous rencontrez ce problème dans un environnement de développement intégré, recherchez des éléments tels que l'état obsolète IDE, les références de projet interrompues ou les configurations de programme de lancement défaillantes.

Il est également possible qu'un IDE s'embrouille simplement. Les IDE sont des logiciels extrêmement compliqués comprenant de nombreuses parties en interaction. Bon nombre de ces composants adoptent diverses stratégies de mise en cache afin de rendre l'ensemble IDE réactif. Celles-ci peuvent parfois mal tourner et l'un des symptômes possibles est le problème lors du lancement d'applications. Si vous pensez que cela pourrait se produire, il est intéressant de redémarrer votre IDE.

Autres références

1113
Stephen C

Si votre nom de code source est HelloWorld.Java, votre code compilé sera HelloWorld.class.

Vous obtiendrez cette erreur si vous l'appelez en utilisant:

Java HelloWorld.class

Au lieu de cela, utilisez ceci:

Java HelloWorld
221
panoet

Si vos classes sont dans des packages alors vous devez cd dans le répertoire racine de votre projet et l'exécuter à l'aide du nom complet de la classe (packageName.MainClassName).

Exemple:

Mes cours sont ici:

D:\project\com\cse\

Le nom complet de ma classe principale est:

com.cse.Main

Donc, je cd retour au répertoire du projet racine:

D:\project

Puis lancez la commande Java:

Java com.cse.Main

Cette réponse sert à sauver les programmeurs débutants Java de la frustration causée par une erreur commune, je vous recommande de lire la réponse acceptée pour obtenir des informations plus détaillées sur le Java classpath.

127
tharinduwijewardane

Si vous définissez la classe principale et la méthode principale dans un package, vous devez l'exécuter sur le répertoire hiérarchique, en utilisant le nom complet de la classe (packageName.MainClassName).

Supposons qu'il existe un fichier de code source (Main.Java):

package com.test;

public class Main {

    public static void main(String[] args) {
        System.out.println("salam 2nya\n");
    }
}

Pour exécuter ce code, vous devez placer Main.Class dans le paquet tel que le répertoire ./com/test/Main.Java. Et dans le répertoire racine, utilisez Java com.test.Main.

53
M-Razavi

Lorsque le même code fonctionne sur un PC, mais qu'il montre l'erreur sur un autre, la meilleure solution que j'ai jamais trouvée consiste à compiler comme suit:

javac HelloWorld.Java
java -cp . HelloWorld
41
Enamul Hassan

Ce qui m'a aidé a été de spécifier le chemin d'accès aux classes sur la ligne de commande, par exemple:

  1. Créez un nouveau dossier, C:\temp

  2. Créez le fichier Temp.Java dans C:\temp, avec la classe suivante:

    public class Temp {
    public static void main(String args[]) {
        System.out.println(args[0]);
    }
}

  3. Ouvrez une ligne de commande dans le dossier C:\temp et écrivez la commande suivante pour compiler la classe Temp:

    javac Temp.Java

  4. Exécutez la classe Java compilée en ajoutant l'option -classpath pour indiquer à JRE où trouver la classe:

    Java -classpath C:\temp Temp Hello!
34
Celebes

Selon le message d'erreur ("Impossible de trouver ou de charger la classe principale"), il existe deux catégories de problèmes:

  1. La classe principale ne peut pas être trouvée
  2. La classe principale n'a pas pu être chargé (ce cas n'est pas décrit en détail dans la réponse acceptée)

La classe principale ne peut pas être trouvée quand il y a typo ou syntaxe incorrecte dans le nom de classe complet ou n'existe pas dans le chemin de classe fourni.

La classe principale ne peut pas être chargée quand la classe ne peut pas être initiée, la classe principale étend généralement une autre classe et cette classe n'existe pas dans le chemin de classe fourni.

Par exemple:

public class YourMain extends org.Apache.camel.spring.Main

Si chamel-spring n'est pas inclus, cette erreur sera signalée.

24
Xiao Peng - ZenUML.com

J'ai eu une telle erreur dans ce cas:

Java -cp lib.jar com.mypackage.Main

Cela fonctionne avec ; pour Windows et : pour Unix:

Java -cp lib.jar; com.mypackage.Main
16
Yamahar1sp

Parfois, la cause du problème n'a rien à voir avec la classe principale et je devais trouver cela à la dure. C’est une bibliothèque référencée que j’ai déplacée et elle m’a donné le:

Impossible de trouver ou de charger la classe principale xxx Linux

Je viens de supprimer cette référence, de l'ajouter à nouveau et cela a fonctionné à nouveau.

15
Eduardo Dennis

Utilisez cette commande:

_Java -cp . [PACKAGE.]CLASSNAME
_

Exemple: Si votre nom de classe est Hello.class créé à partir de Hello.Java, utilisez la commande ci-dessous:

_Java -cp . Hello
_

Si votre fichier Hello.Java se trouve dans le package com.demo, utilisez la commande ci-dessous.

_Java -cp . com.demo.Hello
_

Il arrive souvent que le fichier de classe soit présent dans le même dossier avec JDK 8, mais la commande Java attend un chemin de classe et, pour cette raison, nous ajoutons -cp . dossier comme référence pour classpath.

14
shaILU

Essayez - Xdiag .

La réponse de Steve C couvre bien les cas possibles, mais parfois pour déterminer si la classe ne peut pas être trouvée ou chargée pourrait ne pas être si facile. Utilisez Java -Xdiag (depuis JDK 7). Ceci affiche un Nice stacktrace qui fournit un indice sur la signification du message Could not find or load main class.

Par exemple, il peut vous indiquer d'autres classes utilisées par la classe principale qui étaient introuvables et qui ont empêché le chargement de la classe principale.

13
jan.supol

Dans cet exemple, vous avez:

Impossible de trouver ou de charger la classe principale ? Classpath

C'est parce que vous utilisez "-classpath", mais le tiret n'est pas le même que celui utilisé par Java dans l'invite de commande. J'ai eu cette question copier et coller de Notepad à cmd.

9
Nathan Williams

Dans mon cas, une erreur est apparue parce que j'avais fourni le nom du fichier source au lieu du nom de la classe.

Nous devons fournir le nom de la classe contenant la méthode principale à l'interpréteur.

7
KawaiKx

J'ai eu le même problème et finalement trouvé mon erreur :) J'ai utilisé cette commande pour la compilation et cela a fonctionné correctement.

javac -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode.Java

mais cette commande n'a pas fonctionné pour moi (impossible de trouver ou de charger la classe principale qrcode)

Java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode

Enfin, je viens d'ajouter le caractère ':' en fin de classpath et le problème résolu.

Java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar:" qrcode

)

7
Omid Mohebbi

J'ai passé un temps décent à essayer de résoudre ce problème. Je pensais que mon chemin de classe était mal défini, mais le problème était que je tapais:

Java -cp C:/Java/MyClasses C:/Java/MyClasses/utilities/myapp/Cool

au lieu de:

Java -cp C:/Java/MyClasses utilities/myapp/Cool

Je pensais que la signification de "pleinement qualifié" voulait dire inclure le nom de chemin complet au lieu du nom complet du package.

6
mathewbruens

enter image description here

Emplacement du fichier de classe: C:\test\com\company

Nom du fichier: Main.class

Nom de classe complet: com.company.Main

Commande en ligne de commande: 

Java  -classpath "C:\test" com.company.Main

Notez ici que le chemin d'accès aux classes n'inclut PAS\com\company

6
developer747

Cela pourrait vous aider si votre cas ressemble plus particulièrement au mien: en tant que débutant, j'ai également rencontré ce problème lorsque j'ai essayé de lancer un programme Java.

Je l'ai compilé comme ceci:

javac HelloWorld.Java

Et j'ai essayé de courir aussi avec la même extension:

Java Helloworld.Java

Quand j'ai enlevé le .Java et réécrit la commande comme Java HelloWorld, le programme s'est parfaitement déroulé. :)

6
Ramesh Pareek

Ce qui a résolu le problème dans mon cas était:

Faites un clic droit sur le projet/la classe que vous voulez exécuter, puis sur Run As-> Run Configurations. Ensuite, vous devez soit corriger votre configuration existante, soit en ajouter une nouvelle de la manière suivante:

ouvrez l'onglet Classpath, cliquez sur le bouton Advanced... puis ajoutez dossier bin de votre projet.

5
syntagma

Toutes les réponses ici sont dirigées vers les utilisateurs de Windows, semble-t-il. Pour Mac, le séparateur de chemin de classe est :, pas ;. Comme une erreur lors de la définition du chemin de classe à l'aide de ; n'est pas générée, cela peut être difficile à détecter si vous passez de Windows à Mac.

Voici la commande Mac correspondante:

Java -classpath ".:./lib/*" com.test.MyClass

Où, dans cet exemple, le package est com.test et un dossier lib doit également être inclus dans le chemin de classe.

5
blue-sky

Commencez par définir le chemin à l'aide de cette commande.

set path="paste the set path address"

Ensuite, vous devez charger le programme. Tapez "cd (nom du dossier)" dans le lecteur stocké et compilez-le. Par exemple, si mon programme est enregistré sur le lecteur D, tapez "D:", appuyez sur Entrée et tapez "cd (nom du dossier)".

5
arun

Si vous utilisez Maven pour construire le fichier JAR, veillez à spécifier la classe principale dans le fichier pom.xml:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-jar-plugin</artifactId>
            <configuration>
                <archive>
                    <manifest>
                        <mainClass>class name us.com.test.abc.MyMainClass</mainClass>
                    </manifest>
                </archive>
            </configuration>
        </plugin>
    </plugins>
</build>
5
Junchen Liu

Sous Windows, mettez .; à la valeur CLASSPATH au début.

Le . (point) signifie "regarder dans le répertoire en cours". C'est une solution permanente.

Aussi, vous pouvez le définir "une fois" avec set CLASSPATH=%CLASSPATH%;.. Cela durera aussi longtemps que votre fenêtre cmd est ouverte.

4
Nenad Bulatovic

C'est un cas spécifique, mais puisque je suis venu sur cette page à la recherche d'une solution et que je ne l'ai pas trouvée, je l'ajouterai ici.

Windows (testé avec 7) n'accepte pas les caractères spéciaux (tels que á) dans les noms de classe et de package. Linux le fait cependant.

Je l'ai découvert en construisant un .jar dans NetBeans et en essayant de l'exécuter en ligne de commande. Il s'est exécuté dans NetBeans mais pas en ligne de commande.

4
GuiRitter

Vous devez vraiment faire cela à partir du dossier src. Là vous tapez la ligne de commande suivante:

[name of the package].[Class Name] [arguments]

Supposons que votre classe s'appelle CommandLine.class et que le code ressemble à ceci:

package com.tutorialspoint.Java;

    /**
     * Created by mda21185 on 15-6-2016.
     */

    public class CommandLine {
        public static void main(String args[]){
            for(int i=0; i<args.length; i++){
                System.out.println("args[" + i + "]: " + args[i]);
            }
        }
    }

Ensuite, vous devriez cd dans le dossier src et la commande à exécuter ressemblerait à ceci:

Java com.tutorialspoint.Java.CommandLine this is a command line 200 -100

Et la sortie sur la ligne de commande serait:

args[0]: this
args[1]: is
args[2]: a
args[3]: command
args[4]: line
args[5]: 200
args[6]: -100
3
mdarmanin

Parfois, dans certains compilateurs en ligne que vous avez pu essayer, vous obtiendrez cette erreur si vous n'écrivez pas public class [Classname] mais simplement class [Classname].

3
lor

Lorsque vous exécutez la Java avec l'option -cp annoncée dans Windows PowerShell, vous risquez d'obtenir une erreur ressemblant à ceci:

The term `ClassName` is not recognized as the name of a cmdlet, function, script ...

Pour que PowerShell accepte la commande, les arguments de l'option -cp doivent être entre guillemets, comme suit:

Java -cp 'someDependency.jar;.' ClassName

Cette commande devrait permettre à Java de traiter correctement les arguments du chemin d'accès aux classes.

3
Chezzwizz

J'ai également rencontré des erreurs similaires lors du test d'une connexion JDBC MongoDB Java. Je pense qu'il est bon de résumer ma solution finale en résumé afin que tout le monde puisse à l'avenir consulter directement les deux commandes et qu'il soit bon d'aller plus loin.

Supposons que vous vous trouvez dans le répertoire où se trouvent votre fichier Java et vos dépendances externes (fichiers JAR).

Compiler:

javac -cp mongo-Java-driver-3.4.1.jar JavaMongoDBConnection.Java
  • - cp - argument classpath; transmettre tous les fichiers JAR dépendants un par un
  • * .Java - Ceci est le fichier de classe Java qui contient la méthode main. sdsd

Run:

Java -cp mongo-Java-driver-3.4.1.jar: JavaMongoDBConnection
  • Veuillez observer les deux points (Unix)/comma (Windows) après la fin de tous les fichiers JAR de dépendance.
  • À la fin, observez le nom de la classe principale sans aucune extension (no .class ou .Java)
3
khichar.anil

Bon, beaucoup de réponses déjà, mais personne n’a mentionné le cas où l’autorisation de fichier peut être le coupable. Lors de l'exécution, l'utilisateur n'a pas accès au fichier jar ou à l'un des répertoires du chemin. Par exemple, considérons:

Fichier Jar dans /dir1/dir2/dir3/myjar.jar

L'utilisateur 1 à qui appartient le pot peut faire:

# Running as User1
cd /dir1/dir2/dir3/
chmod +r myjar.jar

Mais ça ne marche toujours pas:

# Running as User2
Java -cp "/dir1/dir2/dir3:/dir1/dir2/javalibs" MyProgram
Error: Could not find or load main class MyProgram

En effet, l'utilisateur en cours d'exécution (User2) n'a pas accès à dir1, dir2, javalibs ou dir3. Cela peut rendre fou quelqu'un lorsque l'utilisateur1 peut voir les fichiers et y accéder, mais l'erreur persiste pour l'utilisateur2

3
biocyberman

Dans mon cas, j'ai eu l'erreur parce que j'avais mélangé les noms de paquet majuscules et minuscules sur un système Windows 7. Changer les noms de paquet en minuscules a résolu le problème. Notez également que dans ce scénario, aucune erreur ne s'est produite lors de la compilation du fichier .Java dans un fichier .class; il ne fonctionnerait tout simplement pas à partir du même répertoire (sous-sous-sous-).

2
Howard007

En Java, lorsque vous exécutez parfois la machine virtuelle Java à partir de la ligne de commande à l'aide de l'exécutable Java et tentez de démarrer un programme à partir d'un fichier de classe avec un public principal (PSVM), vous risquez de rencontrer l'erreur ci-dessous. même si le paramètre classpath de la machine virtuelle Java est précis et que le fichier de classe est présent sur le classpath:

Error: main class not found or loaded

Cela se produit si le fichier de classe avec PSVM n'a pas pu être chargé. Une des raisons possibles est que la classe peut implémenter une interface ou étendre une autre classe qui n’est pas sur le chemin de classe. Normalement, si une classe ne se trouve pas dans le chemin de classe, l'erreur renvoyée indique le contraire. Toutefois, si la classe utilisée est étendue ou implémentée, Java ne peut pas charger la classe elle-même.

Référence: https://www.computingnotes.net/Java/error-main-class-not-found-or-loaded/

2
Anandaraja Ravi

J'ai été incapable de résoudre ce problème avec les solutions énoncées ici (bien que la réponse indiquée ait sans doute clarifié mes concepts). J'ai fait face à ce problème deux fois et chaque fois j'ai essayé différentes solutions (dans l'IDE Eclipse).

  • Tout d'abord, j'ai rencontré plusieurs méthodes main dans différentes classes de mon projet. J'ai donc supprimé la méthode main des classes suivantes.
  • Deuxièmement, j'ai essayé la solution suivante:
    1. Faites un clic droit sur le répertoire principal de mon projet.
    2. Dirigez-vous vers la source puis nettoyez et respectez les paramètres par défaut et cliquez sur Terminer. Après quelques tâches en arrière-plan, vous serez dirigé vers votre répertoire de projet principal.
    3. Après cela, je ferme mon projet, le rouvre, et boum, j'ai finalement résolu mon problème.
2
Anus Kaleem

J'ai eu un étrange.

Erreur: impossible de trouver ou de charger la classe principale mypackage.App

Il s'est avéré que j'avais une configuration pom (parent) dans le fichier pom.xml de mon projet (le fichier pom.xml de mon projet pointait vers un fichier pom.xml parent) et que le chemin relatif était désactivé/incorrect.

Vous trouverez ci-dessous une partie du fichier pom.xml de mon projet.

<parent>
    <groupId>myGroupId</groupId>
    <artifactId>pom-parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <relativePath>../badPathHere/pom.xml</relativePath>
</parent>

Une fois que j'ai résolu pom relativePath, l'erreur a disparu.

Allez comprendre.

2
granadaCoder

J'ai eu cette erreur après avoir fait mvn Eclipse:eclipse Cela a un peu gâché mon fichier .classpath.

J'ai dû changer les lignes dans .classpath de

<classpathentry kind="src" path="src/main/Java" including="**/*.Java"/>
<classpathentry kind="src" path="src/main/resources" excluding="**/*.Java"/>

à

<classpathentry kind="src" path="src/main/Java" output="target/classes" />
<classpathentry kind="src" path="src/main/resources" excluding="**"  output="target/classes" />
2
Jaanus

Parfois, il est préférable de supprimer les fichiers JAR ajoutés et de les ajouter à nouveau avec des aides de construction appropriées. Pour moi, cela a été un problème régulier, et j'ai suivi la même approche:

  1. Placez tous les fichiers JAR référencés dans un dossier, jarAddOns, et copiez-le dans un endroit sûr.
  2. Maintenant depuis Eclipse (ou depuis votre IDE), supprimez les fichiers JAR.
  3. Déplacer le dossier de projet entier de l'espace de travail vers un emplacement sûr
  4. Redémarrez Eclipse (votre IDE)
  5. Maintenant, importez votre répertoire de projet à partir de l'emplacement sécurisé.
  6. Ajoutez les fichiers JAR dans votre projet à partir du dossier jarAddOns (précédemment enregistré dans un emplacement sûr).
  7. Projet buildpath, ajouter des fichiers JAR et appliquer
  8. Maintenant, lancez le projet. Il ne devrait pas montrer l'erreur.
1
nilakantha singh deo

Si ce problème est lié à Eclipse:

Essayez d’ajouter un projet à votre chemin de classe.

voir l'image ci-dessous:

enter image description here

Cette méthode a fonctionné pour moi.

1
Tunde Pizzle

Dans le contexte du développement de IDE (Eclipse, NetBeans ou autre), vous devez configurer les propriétés de votre projet de sorte à avoir une classe principale, afin que votre IDE sache où se trouve la classe principale. être exécuté lorsque vous cliquez sur "Play".

  1. Faites un clic droit sur votre projet, puis Propriétés
  2. Aller à la catégorie Run et sélectionnez votre classe principale
  3. Frappé le Run bouton.

Enter image description here

1
cepix

Cela m'est arrivé aussi. Dans mon cas, cela ne s'est produit que lorsqu'une classe HttpServlet était présente dans le code source (Idea Intellij n'a pas donné d'erreur de compilation, le package de servlet a été importé parfaitement, mais au moment de l'exécution, il y avait ce main class erreur).

J'ai réussi à le résoudre. Je suis allé dans Fichier - Structure du projet:

enter image description here

Puis aux modules:

enter image description here

Il y avait une portée fournie près du module de servlet. Je l'ai changé pour Compiler:

enter image description here

Et ça a marché!

0
parsecer

Par défaut, Java utilise ., le répertoire de travail actuel, par défaut CLASSPATH. Cela signifie que lorsque vous tapez une commande à l'invite, par exemple. Java MyClass, la commande est interprétée comme si vous aviez tapé Java -cp . MyClass. Avez-vous vu ce point entre -cp et MyClass? (cp est l'abréviation de l'option la plus longue classpath)

Cela suffit dans la plupart des cas et les choses semblent bien fonctionner jusqu'à ce que vous essayiez d'ajouter un répertoire à votre CLASSPATH. Dans la plupart des cas, lorsque les programmeurs doivent le faire, ils exécutent simplement une commande telle que set CLASSPATH=path\to\some\dir. Cette commande crée une nouvelle variable d'environnement appelée CLASSPATH ayant la valeur path\to\some\dir ou remplace sa valeur par path\to\some\dir si CLASSPATH était déjà défini auparavant.

Lorsque cela est fait, vous disposez maintenant d'une variable d'environnement CLASSPATH et Java n'utilise plus son chemin d'accès aux classes par défaut (.) mais celui que vous avez défini. Donc, le lendemain, vous ouvrez votre éditeur, écrivez un programme Java, cd dans le répertoire où vous l'avez enregistré, compilez-le et essayez de l'exécuter avec la commande Java MyClass, et vous êtes accueilli avec une sortie Nice: Impossible de trouver ou de charger la classe principale ... (Si vos commandes fonctionnaient bien avant et vous obtenez maintenant cette sortie, alors cela pourrait être le cas pour vous).

En effet, lorsque vous exécutez la commande Java MyClass, Java, le fichier de classe nommé MyClass est recherché dans le ou les répertoires définis dans votre CLASSPATH et pas votre répertoire de travail actuel, il ne trouve donc pas votre fichier de classe et se plaint donc.

Ce que vous devez faire est d’ajouter . à votre chemin de classe, ce qui peut être fait avec la commande set CLASSPATH=%CLASSPATH%;. (remarquez le point après le point-virgule). En clair, cette commande dit "Choisissez ce qui était initialement la valeur de CLASSPATH (%CLASSPATH%), ajoutez . (;.) et affectez le résultat à CLASSPATH".

Et voila , vous pouvez à nouveau utiliser votre commande Java MyClass comme d'habitude.

0
Robert Odoch