JARs en classpath: Cómo incluir todas las bibliotecas de una carpeta en 2025

Introducción: La maldición de los miles de JARs

¿Alguna vez te has encontrado en una situación donde tu proyecto Java crece y la carpeta lib/ se convierte en un auténtico zoológico de decenas, o incluso cientos, de archivos JAR? ¿Y cada vez que ejecutas la aplicación, recuerdas angustiosamente qué JAR agregaste y cuál olvidaste? Te resulta familiar, ¿verdad?

La pregunta "Including all the jars in a directory within the Java classpath" es una de las más populares en Stack Overflow. Y con razón. Una tarea aparentemente trivial se convierte en un dolor de cabeza si no se conocen las herramientas adecuadas. En este artículo analizaremos todas las formas: desde las más antiguas, como los dinosaurios, hasta las más modernas que utiliza todo desarrollador Java que se precie en 2025.

¡Prepárate, nos embarcamos en un fascinante viaje por la jungla del classpath!

¿Por qué es esto un problema? (o "La epopeya con -cp")

En los viejos tiempos (antes de Java 6), los desarrolladores se veían obligados a enumerar cada archivo JAR manualmente. Se veía más o menos así:

java -cp lib/guava.jar:lib/spring-core.jar:lib/log4j.jar:lib/jackson.jar MyApp

Ahora imagina que tienes 30 bibliotecas. Un solo error tipográfico y la aplicación falla con ClassNotFoundException. ¡Una pesadilla! Fue entonces cuando la comunidad comenzó a buscar formas de incluir todos los jars en el classpath de Java con una sola línea.

Método n.º 1: Wildcard — el salvador de Java 6

A partir de Java 6, la JVM incorporó una capacidad mágica: el wildcard (comodín). Simplemente indicas la ruta a la carpeta con un asterisco, y la JVM carga automáticamente todos los archivos JAR de allí.

Cómo funciona:

java -cp "lib/*" MyApp

¡Importante! Presta atención a las comillas. Sin ellas, en algunos shells (por ejemplo, en Unix), el asterisco puede ser interpretado por el shell y obtendrás algo diferente a lo esperado. Las comillas garantizan que * se pase exactamente a la JVM.

Este método sigue siendo relevante hoy en día. Es simple, elegante y resuelve el 90% de los problemas. Pero hay un detalle: el wildcard no funciona de forma recursiva. Si tienes carpetas anidadas (lib/subdir/), su contenido no se cargará. Para ello, debes indicar cada nivel manualmente:

java -cp "lib/*:lib/subdir/*" MyApp

¿Cuándo usar wildcard?

\n
• Estás escribiendo un script o utilidad simple.
\n
• No tienes un sistema de compilación (Maven/Gradle).
\n
• Necesitas ejecutar algo rápidamente "sobre la marcha".
\n

Método n.º 2: Maven — el estándar de la industria

Si trabajas en un proyecto real, probablemente uses Maven. Y la pregunta "cómo incluir todos los JARs de una carpeta" se resuelve a nivel de compilación.

Maven gestiona las dependencias por sí mismo. Simplemente las indicas en pom.xml, y Maven descarga los JARs necesarios y los agrega automáticamente al classpath.

Ejemplo de pom.xml:

<dependencies>\n    <dependency>\n        <groupId>org.springframework.boot</groupId>\n        <artifactId>spring-boot-starter-web</artifactId>\n        <version>3.2.0</version>\n    </dependency>\n    <dependency>\n        <groupId>com.google.code.gson</groupId>\n        <artifactId>gson</artifactId>\n        <version>2.10.1</version>\n    </dependency>\n</dependencies>

Al compilar (por ejemplo, mvn package), Maven crea un fat JAR (o utiliza el plugin maven-dependency-plugin) que incluye todas las dependencias. Ya no necesitas pensar en el classpath: está empaquetado internamente.

Pero, ¿qué pasa si necesitas incluir todos los JARs de alguna carpeta local no gestionada por Maven? Para eso existen las System Dependencies (aunque se considera un antipatrón):

<dependency>\n    <groupId>com.example&