Un problema común que experimentan los nuevos desarrolladores de Java es que sus programas no se ejecutan con el mensaje de error: Could not find or load main class ...
¿Qué significa esto, qué lo causa y cómo debe solucionarlo?
Un problema común que experimentan los nuevos desarrolladores de Java es que sus programas no se ejecutan con el mensaje de error: Could not find or load main class ...
¿Qué significa esto, qué lo causa y cómo debe solucionarlo?
Respuestas:
java <class-name>
sintaxis del comandoEn primer lugar, debe comprender la forma correcta de iniciar un programa utilizando el comando java
(o javaw
).
La sintaxis normal 1 es esta:
java [ <options> ] <class-name> [<arg> ...]
donde <option>
es una opción de línea de comando (que comienza con un carácter "-"), <class-name>
es un nombre de clase Java totalmente calificado y <arg>
es un argumento arbitrario de línea de comando que se pasa a su aplicación.
1 - Hay algunas otras sintaxis que se describen cerca del final de esta respuesta.
El nombre completo (FQN) para la clase se escribe convencionalmente como lo haría en el código fuente de Java; p.ej
packagename.packagename2.packagename3.ClassName
Sin embargo, algunas versiones del java
comando le permiten usar barras en lugar de puntos; p.ej
packagename/packagename2/packagename3/ClassName
que (confusamente) parece un nombre de ruta de archivo, pero no lo es. Tenga en cuenta que el término nombre totalmente calificado es terminología estándar de Java ... no es algo que acabo de inventar para confundirlo :-)
Aquí hay un ejemplo de cómo java
debería verse un comando:
java -Xmx100m com.acme.example.ListUsers fred joe bert
Lo anterior va a causar el java
comando haga lo siguiente:
com.acme.example.ListUsers
clase.main
método con firma , tipo de retorno y modificadores dados por public static void main(String[])
. (Tenga en cuenta que el nombre del argumento del método NO es parte de la firma).String[]
.Cuando recibe el mensaje "No se pudo encontrar o cargar la clase principal ...", eso significa que el primer paso ha fallado. El java
comando no pudo encontrar la clase. Y de hecho, el "..." en el mensaje será el nombre de clase completo que java
está buscando.
Entonces, ¿por qué podría ser incapaz de encontrar la clase?
La primera causa probable es que puede haber proporcionado el nombre de clase incorrecto. (O ... el nombre de clase correcto, pero en forma incorrecta.) Considerando el ejemplo anterior, aquí hay una variedad de formas incorrectas de especificar el nombre de clase:
Ejemplo # 1 - un nombre de clase simple:
java ListUser
Cuando la clase se declara en un paquete como com.acme.example
, entonces debe usar el nombre de clase completo, incluido el nombre del paquete en el java
comando; p.ej
java com.acme.example.ListUser
Ejemplo # 2 - un nombre de archivo o ruta en lugar de un nombre de clase:
java ListUser.class
java com/acme/example/ListUser.class
Ejemplo # 3 - un nombre de clase con la carcasa incorrecta:
java com.acme.example.listuser
Ejemplo # 4 - un error tipográfico
java com.acme.example.mistuser
Ejemplo # 5 - un nombre de archivo fuente (excepto para Java 11 o posterior; ver más abajo)
java ListUser.java
Ejemplo # 6 - olvidaste el nombre de la clase por completo
java lots of arguments
La segunda causa probable es que el nombre de la clase es correcto, pero que el java
comando no puede encontrar la clase. Para comprender esto, debe comprender el concepto de "classpath". Esto se explica bien en la documentación de Oracle:
java
documentación del comandoEntonces ... si ha especificado el nombre de la clase correctamente, lo siguiente que debe verificar es que haya especificado la ruta de clase correctamente:
java
comando. Compruebe que los nombres de directorio y los nombres de archivo JAR son correctos.java
comando.;
en Windows y :
en los demás. Si usa el separador incorrecto para su plataforma, no recibirá un mensaje de error explícito. En su lugar, obtendrá un archivo o directorio inexistente en la ruta que se ignorará en silencio .)Cuando coloca un directorio en el classpath, teóricamente corresponde a la raíz del espacio de nombre calificado. Las clases se encuentran en la estructura de directorios debajo de esa raíz, asignando el nombre completo a un nombre de ruta . Entonces, por ejemplo, si "/ usr / local / acme / classes" está en la ruta de clase, cuando la JVM busca una clase llamada com.acme.example.Foon
, buscará un archivo ".class" con este nombre de ruta:
/usr/local/acme/classes/com/acme/example/Foon.class
Si hubiera puesto "/ usr / local / acme / classes / com / acme / example" en el classpath, entonces la JVM no podría encontrar la clase.
Si sus clases son FQN com.acme.example.Foon
, entonces la JVM buscará "Foon.class" en el directorio "com / acme / example":
Si la estructura de su directorio no coincide con el nombre del paquete según el patrón anterior, la JVM no encontrará su clase.
Si intenta cambiar el nombre de una clase moviéndola, eso también fallará ... pero la excepción stacktrace será diferente. Es probable que diga algo como esto:
Caused by: java.lang.NoClassDefFoundError: <path> (wrong name: <name>)
porque el FQN en el archivo de clase no coincide con lo que el cargador de clases espera encontrar.
Para dar un ejemplo concreto, suponiendo que:
com.acme.example.Foon
clase,/usr/local/acme/classes/com/acme/example/Foon.class
,/usr/local/acme/classes/com/acme/example/
,entonces:
# 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
Notas:
-classpath
opción se puede acortar -cp
en la mayoría de las versiones de Java. Verifique las entradas manuales respectivas para java
, javac
etc.El classpath debe incluir todas las otras clases (no del sistema) de las que depende su aplicación. (Las clases del sistema se ubican automáticamente, y rara vez necesita preocuparse por esto.) Para que la clase principal se cargue correctamente, la JVM necesita encontrar:
(Nota: las especificaciones JLS y JVM permiten cierto alcance para que una JVM cargue clases "perezosamente", y esto puede afectar cuando se produce una excepción de cargador de clases).
Ocasionalmente sucede que alguien coloca un archivo de código fuente en la carpeta incorrecta en su árbol de código fuente, o deja de lado la package
declaración. Si hace esto en un IDE, el compilador del IDE le informará sobre esto inmediatamente. Del mismo modo, si utiliza una herramienta de compilación Java decente, la herramienta se ejecutará javac
de manera que detecte el problema. Sin embargo, si crea su código Java a mano, puede hacerlo de tal manera que el compilador no note el problema y el archivo ".class" resultante no esté en el lugar que espera que esté.
Hay muchas cosas para verificar, y es fácil perderse algo. Intente agregar la -Xdiag
opción a la java
línea de comando (como lo primero después java
). Producirá varias cosas sobre la carga de clases, y esto puede ofrecerle pistas sobre cuál es el verdadero problema.
Además, tenga en cuenta los posibles problemas causados por copiar y pegar caracteres invisibles o no ASCII de sitios web, documentos, etc. Y considere "homoglifos", donde dos letras o símbolos se ven iguales ... pero no lo son.
Finalmente, aparentemente puede encontrarse con este problema si intenta iniciar desde un archivo JAR con firmas incorrectas (META-INF/*.SF)
.
java
Existen tres sintaxis alternativas para el lanzamiento de programas Java utilizando java command
.
1) La sintaxis utilizada para iniciar un archivo JAR "ejecutable" es la siguiente:
java [ <options> ] -jar <jar-file-name> [<arg> ...]
p.ej
java -Xmx100m -jar /usr/local/acme-example/listuser.jar fred
El nombre de la clase de punto de entrada (es decir com.acme.example.ListUser
) y el classpath se especifican en el MANIFEST del archivo JAR.
2) La sintaxis para iniciar una aplicación desde un módulo (Java 9 y posterior) es la siguiente:
java [ <options> ] --module <module>[/<mainclass>] [<arg> ...]
El nombre de la clase de punto de entrada está definido por el <module>
mismo o está dado por el opcional <mainclass>
.
3) A partir de Java 11, puede compilar y ejecutar un único archivo de código fuente y ejecutarlo con la siguiente sintaxis:
java [ <options> ] <sourcefile> [<arg> ...]
donde es (típicamente) un archivo con el sufijo ".java".
Para obtener más detalles, consulte la documentación oficial del java
comando para la versión de Java que está utilizando.
Un IDE Java típico tiene soporte para ejecutar aplicaciones Java en la JVM IDE o en una JVM secundaria. En general, son inmunes a esta excepción particular, porque el IDE utiliza sus propios mecanismos para construir el classpath en tiempo de ejecución, identificar la clase principal y crear la java
línea de comando.
Sin embargo, todavía es posible que ocurra esta excepción, si hace cosas detrás del IDE. Por ejemplo, si previamente configuró un Lanzador de aplicaciones para su aplicación Java en Eclipse, y luego movió el archivo JAR que contiene la clase "principal" a un lugar diferente en el sistema de archivos sin decirle a Eclipse , Eclipse lanzaría involuntariamente la JVM con una ruta de clase incorrecta.
En resumen, si tiene este problema en un IDE, verifique cosas como el estado de IDE obsoleto, referencias de proyecto rotas o configuraciones de iniciador rotas.
También es posible que un IDE simplemente se confunda. Los IDE son piezas de software enormemente complicadas que comprenden muchas partes interactivas. Muchas de estas partes adoptan varias estrategias de almacenamiento en caché para que el IDE en su conjunto responda. A veces, estos pueden salir mal, y un síntoma posible son los problemas al iniciar aplicaciones. Si sospecha que esto podría estar sucediendo, vale la pena intentar otras cosas como reiniciar su IDE, reconstruir el proyecto, etc.
java -cp ../third-party-library.jar com.my.package.MyClass
; esto no funciona, en su lugar, es necesario agregar la carpeta local a la ruta de la clase también (separada por :
, así:, java -cp ../third-party-library.jar:. com.my.package.MyClass
entonces debería funcionar
java
no dice que no encuentra una clase importada, sino la clase principal que está intentando ejecutar. Esto es engañoso, aunque estoy seguro de que hay una razón para eso. Tuve el caso donde java
sabía exactamente dónde está mi clase, sin embargo, no pudo encontrar una de las clases importadas. En lugar de decir eso, se quejó de no encontrar a mi clase principal. Realmente molesto.
Si su nombre de código fuente es HelloWorld.java, su código compilado lo será HelloWorld.class
.
Obtendrá ese error si lo llama usando:
java HelloWorld.class
En cambio, use esto:
java HelloWorld
javac TestCode.java
seguido dejava TestCode
java -classpath . HelloWorld
Si sus clases están en paquetes , debe cd
acceder al directorio raíz de su proyecto y ejecutarlo utilizando el nombre completo de la clase (packageName.MainClassName).
Ejemplo:
Mis clases están aquí:
D:\project\com\cse\
El nombre completo de mi clase principal es:
com.cse.Main
Así que cd
vuelvo al directorio raíz del proyecto:
D:\project
Luego emita el java
comando:
java com.cse.Main
Esta respuesta es para rescatar a los programadores novatos de Java de la frustración causada por un error común, le recomiendo que lea la respuesta aceptada para obtener un conocimiento más profundo sobre el classpath de Java.
Si define la clase principal y el método principal en apackage
, debe ejecutarlo sobre el directorio jerárquico, utilizando el nombre completo de la clase ( packageName.MainClassName
).
Suponga que hay un archivo de código fuente (Main.java):
package com.test;
public class Main {
public static void main(String[] args) {
System.out.println("salam 2nya\n");
}
}
Para ejecutar este código, debe colocarlo Main.Class
en el paquete como directorio ./com/test/Main.Java
. Y en el directorio raíz use java com.test.Main
.
Cuando el mismo código funciona en una PC, pero muestra el error en otra, la mejor solución que he encontrado es compilar de la siguiente manera:
javac HelloWorld.java
java -cp . HelloWorld
javac -classpath . HelloWorld.java
habría funcionado! Y esa es una mejor solución en su caso.
Lo que me ayudó fue especificar el classpath en la línea de comando, por ejemplo:
Crear una nueva carpeta, C:\temp
Cree el archivo Temp.java en C:\temp
, con la siguiente clase en él:
public class Temp {
public static void main(String args[]) {
System.out.println(args[0]);
}
}
Abra una línea de comando en la carpeta C:\temp
y escriba el siguiente comando para compilar la clase Temp:
javac Temp.java
Ejecute la clase Java compilada, agregando la -classpath
opción para que JRE sepa dónde encontrar la clase:
java -classpath C:\temp Temp Hello!
java
no estaba mirando $ CLASSPATH (porque usó -classpath o -jar) o 2) la configuración de classpath no se estableció en el entorno que no estaba en vigor en el contexto que java
era correr; por ejemplo, porque no "fuente" el archivo donde se agregaron los comandos setenv en el shell derecho.
Según el mensaje de error ("No se pudo encontrar o cargar la clase principal"), hay dos categorías de problemas:
No se pudo encontrar la clase principal cuando hay un error tipográfico o una sintaxis incorrecta en el nombre completo de la clase o no existe en el classpath proporcionado .
La clase principal no se pudo cargar cuando la clase no se puede iniciar , normalmente la clase principal extiende otra clase y esa clase no existe en el classpath proporcionado.
Por ejemplo:
public class YourMain extends org.apache.camel.spring.Main
Si camel-spring no está incluido, se informará este error.
extends
). Acabo de aprender de la manera difícil que cuando la clase principal no se carga porque extiende otra que no se pudo encontrar , Java no informa qué clase real no se encontró (a diferencia deNoClassDefFoundError
). Entonces sí, sucede, y es una situación desgarradora cuando no se sabe esto.
Tuve tal error en este caso:
java -cp lib.jar com.mypackage.Main
Funciona con ;
Windows y :
Unix:
java -cp lib.jar; com.mypackage.Main
Main
no está en el archivo JAR. -cp lib.jar;
significa lo mismo que -cp lib.jar;.
el directorio actual está incluido en el classpath.
Prueba -Xdiag .
La respuesta de Steve C cubre muy bien los posibles casos, pero a veces determinar si no se pudo encontrar o cargar la clase podría no ser tan fácil. Uso java -Xdiag
(desde JDK 7). Esto imprime un buen stacktrace que proporciona una pista de lo que significa el mensaje de Could not find or load main class
mensaje.
Por ejemplo, puede señalar otras clases utilizadas por la clase principal que no se pudieron encontrar y evitar que se cargue la clase principal.
Usa este comando:
java -cp . [PACKAGE.]CLASSNAME
Ejemplo: si su nombre de clase es Hello.class creado a partir de Hello.java, utilice el siguiente comando:
java -cp . Hello
Si su archivo Hello.java está dentro del paquete com.demo, utilice el siguiente comando
java -cp . com.demo.Hello
Con JDK 8 muchas veces sucede que el archivo de clase está presente en la misma carpeta, pero el java
comando espera classpath y por esta razón agregamos -cp .
para tomar la carpeta actual como referencia para classpath.
-cp .
es innecesario, porque si no $CLASSPATH
está configurado, entonces .
es el classpath predeterminado.
echo %CLASSPATH%
salida?) Y no, no puedo comprobarlo porque no tengo una PC con Windows.
A veces, lo que podría estar causando el problema no tiene nada que ver con la clase principal, y tuve que averiguarlo por las malas. Era una biblioteca referenciada que moví, y me dio el:
No se pudo encontrar o cargar Linux de clase principal xxx
Acabo de eliminar esa referencia, la agregué nuevamente y funcionó bien nuevamente.
En este caso tienes:
No se pudo encontrar o cargar la clase principal ? Classpath
Es porque está utilizando "-classpath", pero el guión no es el mismo guión utilizado java
en el símbolo del sistema. Tuve este problema al copiar y pegar desde el Bloc de notas a cmd.
Tuve el mismo problema y finalmente encontré mi error :) Utilicé este comando para compilar y funcionó correctamente:
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
Pero este comando no funcionó para mí (no pude encontrar ni cargar la clase principal 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
Finalmente, simplemente agregué el carácter ':' al final de la ruta de clase y el problema se resolvió:
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
En mi caso, apareció un error porque había proporcionado el nombre del archivo de origen en lugar del nombre de la clase.
Necesitamos proporcionar el nombre de la clase que contiene el método principal al intérprete.
Esto podría ayudarlo si su caso es específicamente como el mío: como principiante, también me encontré con este problema cuando intenté ejecutar un programa Java.
Lo compilé así:
javac HelloWorld.java
Y traté de ejecutar también con la misma extensión:
java Helloworld.java
Cuando eliminé .java
y reescribí el comando como java HelloWorld
, el programa se ejecutó perfectamente. :)
Parece que todas las respuestas aquí están dirigidas a usuarios de Windows. Para Mac, el separador de classpath es :
, no ;
. Como error al configurar el classpath usando;
no se , esto puede ser difícil de descubrir si viene de Windows a Mac.
Aquí está el comando correspondiente de Mac:
java -classpath ".:./lib/*" com.test.MyClass
En este ejemplo, dónde está el paquete com.test
y lib
se debe incluir una carpeta en classpath.
/*
es necesario?
Ubicación del archivo de clase: C: \ test \ com \ company
Nombre del archivo: Main.class
Nombre de clase completo: completo com.company.Main
Comando de línea de comando:
java -classpath "C:\test" com.company.Main
Tenga en cuenta que la ruta de clase NO incluye \ com \ company
Pasé una cantidad de tiempo decente tratando de resolver este problema. Pensé que de alguna manera estaba configurando mi classpath incorrectamente, pero el problema fue que escribí:
java -cp C:/java/MyClasses C:/java/MyClasses/utilities/myapp/Cool
en vez de:
java -cp C:/java/MyClasses utilities/myapp/Cool
Pensé que el significado de totalmente calificado significaba incluir el nombre de ruta completo en lugar del nombre completo del paquete.
utilities.myapp.Cool
o sea el nombre de su paquete, si lo hay.
Primero configure la ruta con este comando;
set path="paste the set path address"
Entonces necesitas cargar el programa. Escriba "cd (nombre de la carpeta)" en la unidad almacenada y compílelo. Por ejemplo, si mi programa está almacenado en la unidad D, escriba "D:", presione Intro y escriba "cd (nombre de la carpeta)".
if "cd" helps then it by luck rather than by judgement
. Esto es incorrecto (creo), ya que Java usa el directorio actual .
como parte de la ruta de clase por defecto.
Lo que solucionó el problema en mi caso fue:
Haga clic derecho en el proyecto / clase que desea ejecutar, luego Run As
-> Run Configurations
. Luego, debe corregir su configuración existente o agregar una nueva de la siguiente manera:
abra la Classpath
pestaña, haga clic en el Advanced...
botón y luego agregue la bin
carpeta de su proyecto.
Si usa Maven para compilar el archivo JAR, asegúrese de especificar la clase principal en el archivo 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>
Este es un caso específico, pero como llegué a esta página buscando una solución y no la encontré, la agregaré aquí.
Windows (probado con 7) no acepta caracteres especiales (como á
) en los nombres de clase y paquete. Sin embargo, Linux sí.
Descubrí esto cuando construí un .jar
NetBeans e intenté ejecutarlo en la línea de comandos. Se ejecutó en NetBeans pero no en la línea de comando.
En Windows, coloque .;
el valor CLASSPATH al principio.
Los . (punto) significa "buscar en el directorio actual". Esta es una solución permanente.
También puede configurarlo "una vez" con set CLASSPATH=%CLASSPATH%;.
. Esto durará mientras su ventana de cmd esté abierta.
Realmente necesitas hacer esto desde la src
carpeta. Allí escribe la siguiente línea de comando:
[name of the package].[Class Name] [arguments]
Digamos que se llama a su clase CommandLine.class
y el código se ve así:
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]);
}
}
}
Entonces deberías cd
ir a la carpeta src y el comando que necesitas ejecutar se vería así:
java com.tutorialspoint.java.CommandLine this is a command line 200 -100
Y la salida en la línea de comando sería:
args[0]: this
args[1]: is
args[2]: a
args[3]: command
args[4]: line
args[5]: 200
args[6]: -100
cd
entrar src
y luego ejecutar el comando java ../bin com.blah.blah.MyClass
que funcionó para mí. Así que gracias por el consejo!
En Java, cuando a veces ejecuta la JVM desde la línea de comandos utilizando el ejecutable de Java e intenta iniciar un programa desde un archivo de clase con public static void main (PSVM), puede encontrarse con el siguiente error aunque el parámetro classpath la JVM es precisa y el archivo de clase está presente en el classpath:
Error: main class not found or loaded
Esto sucede si el archivo de clase con PSVM no se pudo cargar. Una posible razón para eso es que la clase puede estar implementando una interfaz o extendiendo otra clase que no está en el classpath. Normalmente, si una clase no está en el classpath, el error arrojado indica como tal. Pero, si la clase en uso se extiende o implementa, Java no puede cargar la clase en sí.
Referencia: https://www.computingnotes.net/java/error-main-class-not-found-or-loaded/
Al ejecutar el java
con la -cp
opción como se anuncia en Windows PowerShell, puede obtener un error similar al siguiente:
The term `ClassName` is not recognized as the name of a cmdlet, function, script ...
Para que PowerShell acepte el comando, los argumentos de la -cp
opción deben estar contenidos entre comillas como en:
java -cp 'someDependency.jar;.' ClassName
Formar el comando de esta manera debería permitir que Java procese los argumentos de classpath correctamente.
También me enfrenté a errores similares al probar una conexión JDBC Java MongoDB. Creo que es bueno resumir mi solución final en resumen para que en el futuro cualquiera pueda mirar directamente los dos comandos y sea bueno continuar.
Suponga que está en el directorio donde existen su archivo Java y sus dependencias externas (archivos JAR).
Compilar:
javac -cp mongo-java-driver-3.4.1.jar JavaMongoDBConnection.java
Correr:
java -cp mongo-java-driver-3.4.1.jar: JavaMongoDBConnection
JavaMongoDBConnection
no tiene paquete y 2) no cambia el directorio. Es, por decir lo menos, frágil. Y al no explicar los problemas, llevará a los novatos a probar este enfoque en situaciones en las que no funcionará . En resumen, fomenta las "técnicas de programación de vudú": en.wikipedia.org/wiki/Voodoo_programming
Muy bien, ya hay muchas respuestas, pero nadie mencionó el caso en que los permisos de los archivos pueden ser los culpables.
Cuando se ejecuta, un usuario puede no tener acceso al archivo JAR o a uno de los directorios de la ruta. Por ejemplo, considere:
Archivo jar en /dir1/dir2/dir3/myjar.jar
El usuario1 que posee el archivo JAR puede hacer:
# Running as User1
cd /dir1/dir2/dir3/
chmod +r myjar.jar
Pero todavía no funciona:
# Running as User2
java -cp "/dir1/dir2/dir3:/dir1/dir2/javalibs" MyProgram
Error: Could not find or load main class MyProgram
Esto se debe a que el usuario en ejecución (Usuario2) no tiene acceso a dir1, dir2 o javalibs o dir3. Puede volver loco a alguien cuando el Usuario1 puede ver los archivos y puede acceder a ellos, pero el error aún ocurre para el Usuario2.
Recibí este error después de hacer mvn eclipse:eclipse
esto desordenó .classpath
un poco mi archivo.
Tuve que cambiar las líneas .classpath
de
<classpathentry kind="src" path="src/main/java" including="**/*.java"/>
<classpathentry kind="src" path="src/main/resources" excluding="**/*.java"/>
a
<classpathentry kind="src" path="src/main/java" output="target/classes" />
<classpathentry kind="src" path="src/main/resources" excluding="**" output="target/classes" />
No pude resolver este problema con las soluciones indicadas aquí (aunque la respuesta indicada, sin duda, aclaró mis conceptos). Enfrenté este problema dos veces y cada vez que probé diferentes soluciones (en el IDE de Eclipse).
main
métodos en diferentes clases de mi proyecto. Entonces, había eliminado el main
método de las clases posteriores.main
métodos no solucionará el problema. No hay nada técnicamente incorrecto con una aplicación que tiene múltiples puntos de entrada.