Appplication classes originate from developer-written source code or external libraries and are primarily resolved by the application class loader. The JVM determines where to search for these compiled .class files through the CLASSPATH environment variable or command-line flags like -cp or -classpath. When multiple configurations are present, command-line arguments override environment settings. If neither is defined, the runtime defaults to the current working directory (.).

To verify this default behavior, consider a simple standalone class named ClasspathVerifier. Compiling it and running the executable from its directory without specifying any path variables allows the JVM to locate the bytecode successfully. Internally, the active search directories are stored in the java.class.path system property. The following snippet demonstrates how to retrieve and display this runtime configuration:

public class ClasspathVerifier {
    public static void main(String[] args) {
        System.out.println("Runtime execution confirmed.");
        String activePaths = System.getProperty("java.class.path");
        System.out.println("Resolved classpath: " + activePaths);
    }
}

Executing this program without external path definitions yields . as the output, confirming the default search location.

When a global CLASSPATH variable is defined in the operating system, the JVM incorporates it into its search sequence. Alternatively, passing -cp or -classpath directly to the java executable provides a session-specific configuration. Testing both simultaneously reveals a clear precedence order: explicit command-line flags supersede environment variables. If a directory specified in the environment lacks the target bytecode but is included via -cp, the JVM successfully resolves the class using the command-line directive, proving its higher priority.

Core platform classes, such as java.lang.Object and fundamental I/O utilities, reside within bootstrap archives like rt.jar. These are loaded by the primordial Bootstrap ClassLoader, which operates without explicit path configuration from the developer. The search locations for these foundational libraries are exposed via the sun.boot.class.path system property. Modifying the previous verifier to query this property instead reveals a semicolon-separated list of critical JAR files located in the jre/lib directory.

The population of this property occurs during JVM initialization. In HotSpot (JDK 8 era), the startup routine locates the native JVM library (e.g., jvm.dll on Windows), strips the binary and architecture identifiers to derive the installation root (JAVA_HOME), and concatenates standard library paths into the bootstrap property. This internal path resolution ensures that only recognized core archives are loaded, ignoring incorrectly named files even if placed in standard directories. Note that modern JDK releases have deprecated this system property.

To inject custom implementations or patch core framework bugs, developers historically utilized -Xbootclasspath/p (prepend) and -Xbootclasspath/a (append). The prepend flag forces the class loader to prioritize custom archives over native ones. The example below demonstrates replacing a standard utility with a modified version containing an additional method:

import java.lang.reflect.Method;
import java.util.Collections;

public class BootpathOverrideDemo {
    public static void main(String[] args) throws Exception {
        // Locate the custom method in the patched class
        Method customAction = Collections.class.getDeclaredMethod("patchedOperation");
        
        // Execute the override logic
        customAction.invoke(null);
    }
}

When launching the JVM with -Xbootclasspath/p:/path/to/custom-core.jar, the bootstrap loader encounters the modified Collections implementation first. Consequently, the reflection call successfully invokes patchedOperation, effectively bypassing the original JDK implementation. This mechanism allowed low-level framework modifications prior to the module system introduction.

Starting with JDK 9, the modular architecture deprecated sun.boot.class.path and removed -Xbootclasspath. Equivalent functionality for patching modules is now achieved through the --patch-module flag, which aligns with the strong encapsulation principles of the Java Platform Module System.