The way I see it, (correct me if I’m wrong) a class is cached, so that the need to search the class path is only necessary the first time the class is referenced. It will only happen as often as the static initializer is called, which is only one time during the life cycle of the program. (or more specifically, the Class Loader)
But in the case of a large, long-life program that includes many many libraries that may or may not be used.
Do the Jar files get loaded into memory, causing unnecessary usage due to the fact that most of the classes are never used? Will it stay in Memory?
Is referencing a directory a better option? Or is the Jar file already unzipped into a temporary location to begin with?
Is it faster to use the directory method than the Jar file method?
Is it reasonable to extract all Jar files into a single directory, to reduce the number of locations in the class path? When is this a good idea?
The jar file central directories (placed at the end of zips) will be parsed and loaded into memory. The directory is flat so all of it needs to be loaded. A significant part of the delay when starting a simple Java process is the opening of rt.jar which is huge. So, yes that’s start up time and memory overhead right there.
Look up for each class should be constant time. However, there are some O(n) algorithms there. So for an application as a whole that O(n^2) for class loading (although the constant is quite small and may well be dominated by linear time operations).
Doing file access on loads of files will be inefficient. The JDK was using a zip for system classes before jars.
(Class loading may happen some time before static initialisation when the static initialiser will be run if present – see three-argument
Class.forName.)