Question
Is there a way to include all JAR files inside a directory in the Java classpath?
For example, I am trying to run:
java -classpath lib/*.jar:. my.package.Program
However, Java cannot find classes that definitely exist inside those JAR files. Do I need to add each JAR file to the classpath separately, or is there a standard way to include all JARs from a folder?
Short Answer
By the end of this page, you will understand how the Java classpath works, when wildcard JAR loading is supported, why lib/*.jar may not behave as expected, and how to correctly include all JAR files from a directory when running Java programs.
Concept
The classpath tells the Java runtime where to look for compiled classes and packaged libraries such as JAR files.
When you run a Java program, the JVM does not automatically search every folder on your machine. It only looks in the locations you explicitly provide through the classpath.
A classpath entry can be:
- A directory containing
.classfiles - A specific
.jarfile - In modern Java launchers, a wildcard like
lib/*to include all JARs in one directory
A common source of confusion is that Java wildcard classpath support is not the same as shell file expansion.
For Java, the supported wildcard form is typically:
lib/*
not:
lib/*.jar
Why this matters:
lib/*tells the Java launcher to include all JAR files in that directorylib/*.jarmay be expanded by the shell before Java sees it, which can produce unexpected results- Wildcards apply to JAR files in a directory, not recursively to subdirectories
So in most cases, the correct approach is:
java -cp "lib/*:." my.package.Program
On Windows, the separator is ; instead of ::
Mental Model
Think of the classpath as a list of places Java is allowed to search.
If your program needs a book, Java will only look in the libraries listed on that search list.
.means: "also look in the current directory"lib/some.jarmeans: "look in this one exact library"lib/*means: "look in every JAR sitting directly inside thelibfolder"
If a library is not on that list, Java acts as if it does not exist, even if the file is right there on disk.
Syntax and Examples
The most common syntax is:
java -cp "lib/*:." my.package.Program
What this means
-cpis short for-classpathlib/*includes all JAR files in thelibdirectory.includes the current directorymy.package.Programis the main class to run
Linux/macOS example
java -cp "lib/*:." com.example.Main
Windows example
java -cp "lib/*;." com.example.Main
Including one specific JAR manually
java -cp "lib/a.jar:lib/b.jar:." com.example.Main
Important note about *.jar
This often looks reasonable:
Step by Step Execution
Consider this command:
java -cp "lib/*:." com.example.Main
Now walk through what happens:
- The
javalauncher starts. - It reads the classpath from
-cp. - It sees two classpath entries:
lib/*.
lib/*is interpreted by Java as: include all JAR files directly insidelib..tells Java to also search the current directory for compiled classes.- Java tries to load
com.example.Main. - If
com/example/Main.classexists under the current directory, Java loads it. - When
Mainreferences classes from external libraries, Java searches the JARs included fromlib/*. - If the needed class is found in one of those JARs, execution continues.
- If not, Java throws an error such as:
java.lang.ClassNotFoundException
Small trace example
Suppose:
Real World Use Cases
Classpath configuration is used in many practical situations:
Running a small Java app manually
You have compiled .class files and a lib/ folder of dependencies.
java -cp "lib/*:." com.example.Main
Launching internal tools or scripts
Teams often keep utility programs with a local lib/ directory for database drivers, JSON libraries, or logging frameworks.
Using JDBC drivers
Database drivers are usually shipped as JAR files. Including all JARs in lib/ makes it easy to run tools that connect to MySQL, PostgreSQL, or Oracle.
Legacy applications without Maven or Gradle
Older Java projects often depend on manually managed JAR files. Wildcard classpaths reduce command length and setup errors.
Batch jobs and scheduled tasks
A cron job or task scheduler may run a Java command-line application that loads libraries from a deployment folder.
Real Codebase Usage
In real projects, developers rarely type long classpaths by hand for large applications. Instead, they use a few common patterns.
1. A lib/ directory plus wildcard classpath
Useful in simple deployments:
java -cp "app.jar:lib/*" com.example.Main
2. Build tools manage dependencies
Tools like Maven and Gradle usually generate the runtime classpath automatically. This avoids manual mistakes.
3. Startup scripts
Teams often create shell scripts or batch files so users do not need to remember separators or quoting rules.
#!/bin/sh
java -cp "lib/*:." com.example.Main
4. Guarding against missing dependencies
When a classpath is wrong, applications may fail at startup. Developers often test startup early so missing libraries are caught quickly.
5. Packaging into one executable JAR
Instead of many JAR files, some teams package dependencies into a single distributable artifact. This simplifies deployment, though the underlying classpath concept still matters.
6. Environment-specific launch configuration
Different environments may load different driver or plugin JARs by pointing the classpath to different folders.
Common Mistakes
Using lib/*.jar instead of lib/*
This is the most common issue.
Broken example:
java -cp lib/*.jar:. com.example.Main
Better:
java -cp "lib/*:." com.example.Main
Forgetting the current directory
If your own compiled classes are not inside a JAR, you often still need ..
Broken example:
java -cp "lib/*" com.example.Main
If Main.class is in the current directory structure, use:
java -cp "lib/*:." com.example.Main
Using the wrong path separator
- Linux/macOS use
: - Windows uses
;
Broken on Windows:
Comparisons
| Approach | Example | Pros | Cons |
|---|---|---|---|
| Add each JAR manually | -cp "lib/a.jar:lib/b.jar:." | Explicit and predictable | Becomes long and hard to maintain |
| Use wildcard directory | -cp "lib/*:." | Short and convenient | Only includes JARs directly in one folder |
| Use shell expansion | -cp lib/*.jar:. | May appear convenient | Can behave differently by shell and is easy to get wrong |
| Use Maven/Gradle | mvn exec or Gradle run task | Best for larger projects | Requires build tool setup |
| Package one fat JAR | java -jar app.jar |
Cheat Sheet
Classpath basics
-cpand-classpathmean the same thing.means current directory- Linux/macOS separator:
: - Windows separator:
;
Include all JARs in a folder
Linux/macOS:
java -cp "lib/*:." com.example.Main
Windows:
java -cp "lib/*;." com.example.Main
Rules
- Use
lib/*, not usuallylib/*.jar - Wildcard includes JARs directly in that folder
- Wildcard does not search subdirectories recursively
- Add
.if your compiled classes are in the current directory - Quote the classpath to keep it as one argument
Common errors
ClassNotFoundException→ class not found on classpathNoClassDefFoundError→ class was present at compile time or expected, but missing at runtime
FAQ
Can I include all JAR files from a directory in Java?
Yes. Use a wildcard directory entry such as lib/* in the classpath.
Why does lib/*.jar not work reliably?
Because the shell may expand it before Java handles the classpath. Java's wildcard classpath support is designed around lib/*.
Does lib/* include subdirectories too?
No. It includes JAR files directly inside lib, not nested folders.
Do I still need to include . in the classpath?
Yes, if your own compiled .class files are being loaded from the current directory structure.
What is the difference between ClassNotFoundException and NoClassDefFoundError?
ClassNotFoundException usually means Java could not locate a class when asked to load it. NoClassDefFoundError often means the class was expected at runtime but is missing from the actual runtime classpath.
Is the classpath separator the same on every operating system?
No. Use : on Linux/macOS and ; on Windows.
Mini Project
Description
Create a small Java command-line application that uses an external library stored in a lib/ directory. This project demonstrates how to run your own compiled class together with dependency JARs using a wildcard classpath.
Goal
Run a Java program successfully by loading all dependency JARs from a lib/ folder using the correct classpath syntax.
Requirements
- Create a Java class with a
mainmethod. - Place at least one dependency JAR inside a
lib/directory. - Compile the program so the class file is available from the project directory.
- Run the program using a wildcard classpath entry for the
lib/folder. - Make sure the program can use a class from the external JAR at runtime.
Keep learning
Related questions
Avoiding Java Code in JSP with JSP 2: EL and JSTL Explained
Learn how to avoid Java scriptlets in JSP 2 using Expression Language and JSTL, with examples, best practices, and common mistakes.
Choosing a @NotNull Annotation in Java: Validation vs Static Analysis
Learn how Java @NotNull annotations differ, when to use each one, and how to choose between validation, IDE hints, and static analysis tools.
Convert a Java Stack Trace to a String
Learn how to convert a Java exception stack trace to a string using StringWriter and PrintWriter, with examples and common mistakes.