JARs im Classpath: So binden Sie alle Bibliotheken aus einem Ordner im Jahr 2025 ein

Einleitung: Der Fluch der tausend JARs

Waren Sie schon einmal in der Situation, dass Ihr Java-Projekt wuchs und der Ordner lib/ sich in einen regelrechten Zoo aus Dutzenden, wenn nicht Hunderten von JAR-Dateien verwandelte? Und jedes Mal, wenn Sie die Anwendung starten, erinnern Sie sich qualvoll daran, welches JAR Sie hinzugefügt und welches Sie vergessen haben? Kommt Ihnen bekannt vor, oder?

Die Frage "Including all the jars in a directory within the Java classpath" ist eine der beliebtesten auf Stack Overflow. Und das zu Recht. Was scheinbar eine triviale Aufgabe ist, wird schnell zum Kopfzerbrechen, wenn man die richtigen Werkzeuge nicht kennt. In diesem Artikel werden wir alle Methoden durchgehen: von den uralten bis zu den modernsten, die jeder selbstachtende Java-Entwickler im Jahr 2025 verwendet.

Machen Sie sich bereit, wir begeben uns auf eine spannende Reise durch den Dschungel des Classpaths!

Warum ist das überhaupt ein Problem? (oder "Die Odyssee mit -cp")

In der guten alten Zeit (vor Java 6) waren Entwickler gezwungen, jede JAR-Datei manuell aufzulisten. Das sah ungefähr so aus:

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

Stellen Sie sich nun vor, Sie haben 30 Bibliotheken. Ein Tippfehler – und die Anwendung stürzt mit ClassNotFoundException ab. Ein Albtraum! Damals begann die Community, nach Möglichkeiten zu suchen, wie man alle JARs in den Java Classpath mit einer einzigen Zeile einbinden kann.

Methode Nr. 1: Wildcard – der Retter aus Java 6

Ab Java 6 erhielt die JVM eine magische Fähigkeit – den Wildcard (Platzhalter). Sie geben einfach den Pfad zum Ordner mit einem Sternchen an, und die JVM lädt automatisch alle JAR-Dateien von dort.

So funktioniert es:

java -cp "lib/*" MyApp

Wichtig! Beachten Sie die Anführungszeichen. Ohne sie kann das Sternchen in manchen Shells (z. B. unter Unix) von der Shell interpretiert werden, und Sie erhalten nicht das, was Sie erwarten. Die Anführungszeichen stellen sicher, dass * genau so an die JVM übergeben wird.

Diese Methode ist bis heute aktuell. Sie ist einfach, elegant und löst 90 % der Probleme. Es gibt jedoch einen Haken: Der Wildcard funktioniert nicht rekursiv. Wenn Sie verschachtelte Ordner haben (lib/subdir/), wird deren Inhalt nicht geladen. Dazu müssen Sie jede Ebene manuell angeben:

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

Wann sollte man den Wildcard verwenden?

\n
• Sie schreiben ein einfaches Skript oder ein Dienstprogramm.
\n
• Sie haben kein Build-System (Maven/Gradle).
\n
• Sie müssen schnell etwas "mal eben" starten.
\n

Methode Nr. 2: Maven – der Industriestandard

Wenn Sie an einem echten Projekt arbeiten, verwenden Sie höchstwahrscheinlich Maven. Und die Frage "Wie binde ich alle JARs aus einem Ordner ein?" wird hier auf der Build-Ebene gelöst.

Maven verwaltet die Abhängigkeiten selbst. Sie geben sie einfach in der pom.xml an, und Maven lädt die benötigten JARs herunter und fügt sie automatisch zum Classpath hinzu.

Beispiel einer 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>

Beim Bauen (z. B. mvn package) erstellt Maven ein fat JAR (oder verwendet das Plugin maven-dependency-plugin), das alle Abhängigkeiten enthält. Sie müssen nicht mehr über den Classpath nachdenken – er ist im Inneren verpackt.

Was aber, wenn Sie alle JARs aus einem lokalen Ordner einbinden müssen, der nicht von Maven verwaltet wird? Dafür gibt es System Dependencies (auch wenn dies als Antipattern gilt):

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