Answer.

Classpath is a parameter that defines the list of directories, JARs, and ZIPs where the Java Virtual Machine and compiler search for classes and resources when launching an application.

Background:

Since the inception of Java, there has been a need to organize the loading of a large number of classes that often reside in different directories. Classpath was designed to flexibly specify where to look for dependencies.

The Problem:

If classpath is misconfigured, the application will not find the necessary classes, leading to loading errors (e.g., ClassNotFoundException or NoClassDefFoundError).

The Solution:

Classpath can be set via the environment variable CLASSPATH, the command-line argument -cp, or -classpath. It is important to explicitly specify all directories and JAR files required for the application's functionality. Example of launching with classpath:

java -cp ".;lib/*" com.example.Main

Key features:

Multiple paths can be specified using ; (Windows) or : (Linux/macOS)
Supports wildcards: lib/* — all JARs in the lib folder
If not specified, the current directory is used by default

Trick Questions.

Can Java find classes by itself if they are not listed in the classpath?

No, Java does not automatically search for classes outside of the specified classpath. Each path must be explicitly mentioned or added during the build or launch step.

Does the order of paths in the classpath affect class loading?

Yes, if there are name collisions, the class found in the first specified path will be loaded first. Order is important to avoid version conflicts.

Can a new JAR be added to the classpath "on the fly" after the application is started?

No, the standard classpath mechanism is static after the JVM starts. Dynamically loading new classes requires special ClassLoaders.

Common Mistakes and Anti-patterns

Syntax errors in paths (especially on Windows/Linux)
Version incompatibility of libraries due to duplicate JARs
Missing necessary dependencies
"Hardcoded" classpath in scripts that do not support different environments

Real-life Example

Negative Case

A Java application is launched with the parameter -cp lib/mylib.jar, forgetting to add the folder with the test config. As a result, the application crashes with an error, even though the library seems to be present.

Pros:

Simplicity: only specified what is needed

Cons:

Lack of flexibility (every time the application is extended, the path must be manually corrected)
Easy to make mistakes

Positive Case

Using maven/gradle, which automatically constructs the classpath based on dependencies. Launching is done through a wrapper script.