Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
The Java virtual machine (JVM) employs a class loader to load classes used by an application on an as-needed basis. The
CLASSPATH environment variable tells the class loader where to find third-party and user-defined classes. You can also specify the
classpath on a per-application basis with the
-classpath JVM command-line argument, which overrides the classpath specified in the
CLASSPATH environment variable.
Classpath entries can be directories that contain class files for classes not in a package, the package root directory for classes in a package, or archive files (such as .zip or .jar files) that contain classes. Classpath entries are colon-separated on Unix-type systems and semicolon-separated on MS Windows systems.
Class loaders are organized in a delegation hierarchy, with each class loader having a parent class loader. When a class loader
is asked to find a class, it first delegates the request to its parent class loader before attempting to find the class itself.
The system class loader, the default class loader provided by the JDK or JRE installed on your system, loads third-party and
user-defined classes using the
CLASSPATH environment variable or the
-classpath JVM command-line argument. The system class loader delegates to the extension class to load classes that use the Java Extension
mechanism. The extension class loader delegates to the bootstrap class loader (the buck stops here!) to load the core JDK
You can develop specialized class loaders to customize how the JVM dynamically loads classes. For example, most servlet engines use a custom class loader to dynamically reload servlet classes that have changed in directories specified in a custom classpath.
Of particular importance, and much consternation, the class loader will load classes in the order they appear in the classpath. Starting with the first classpath entry, the class loader visits each specified directory or archive file attempting to find the class to load. The first class it finds with the proper name is loaded, and any remaining classpath entries are ignored.
Sounds simple, right?
Whether they would admit it or not, beginner and veteran Java developers alike have at some point (usually at the worst possible moment!) been tricked by the onerous classpath. As the number of dependent third-party and user-defined classes increases for an application, and the classpath becomes a dumping ground for every conceivable directory and archive file, it's not always obvious which class the class loader will load first. This is especially true in the unfortunate event that the classpath contains duplicate class entries. Remember, the class loader loads the first properly named class it finds in the classpath and effectively "hides" all other properly named classes of lower precedence.