Is a large class path of multiple (perhaps even unused) jar files inefficient

Question

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?

Answer 1

This is so not a problem, you shouldn't worry about it. The class loader is smart enough to load the classes it needs, and often loads classes on demand (i.e. it's not typically going to load up a bunch of code that isn't going to be used). This has nothing to do with how large or long running your application is.

In the case of a large number of JARs I'd be more concerned about JAR Hell.

As far as the question of faster, I suppose there might be some difference between the various approaches, but if there is you can easily test this yourself by just trying it via experimentation. The situation is likely application specific, since the code that each application loads is different.

I think smooth reggae's answer is good for some additional detail on the class loading topic.

Answer 2

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.)

Answer 3

How classes are found and the chapter on loading, linking and initializing in the JVM specification are useful references.

From personal experience, I can attest that the longer your classpath for javac the more time your compilation will take; this is especially a problem when your classpath features JARs that are not required for compilation. For a simple test, try compiling the canonical HelloWorld.java without -cp, with a couple of JAR files added to -cp and then with several JAR files added to -cp; the time taken for compilation goes up as the number of JARs in the -cp list goes up.