OK、JVMがクラスのインスタンスを作成する方法に関して理解する必要のあることがいくつかあります。最初から始めます。
JVMが起動すると、アプリケーションの実行に使用されるクラスをロードする必要があります。これを行うには、ブートストラップクラスローダー、拡張機能クラスローダー、システムクラスローダーの3つのクラスローダーが使用されます。それぞれ$JAVA_HOME/libおよび$JAVA_HOME/ lib/extのjarファイルからの最初の2つのロードクラス。これらは基本的にJVMを実行するために必要なものです-今のところそれらについて心配する必要はありません。3番目のクラスローダーであるシステムクラスローダーは、関心のあるものです。このシステムクラスローダーは、クラスパスを使用して、アプリケーションを形成するためにJVMに追加するクラスを検索します。
クラスローダーにはまだまだたくさんのことがありますが、今のところはそれで十分です。
したがって、システムクラスローダーはクラスパスを使用してクラスをロードします。最も単純な形式では、クラスパスは、Javaコンパイラが作成したクラスを出力するディレクトリへの参照にすぎません。そのディレクトリ内には、クラスを作成したときに使用したパッケージ構造（アプリケーションのコンテキスト内でクラスを編成するために使用される.javaファイルの先頭にあるパッケージ宣言）と.classファイルを表すディレクトリの階層があります。コンパイルされたクラスが含まれています。JVMでクラスが必要になると、システムクラスローダーはパッケージを表すディレクトリ構造を解析し、クラスをロードします（または、クラスが見つからない場合はClassNotFoundExceptionをスローします）。
現在、Javaの強みの1つは、利用可能なサードパーティライブラリの数が非常に多いことです。明らかに、ディレクトリをコピーしてコードを共有することは機能しないため、JavaアーカイブまたはJARファイルが使用されます。JARは、いくつかの標準ディレクトリに加えて、パッケージ構造を表す同じディレクトリと前述の.classファイルを含むzipファイルにすぎません。もちろん、拡張子.jarを取得しますが、zipファイルを開くことができるツールはJARを開きます。JARを使用するには、ディレクトリと同じようにクラスパスに追加するだけで、ディレクトリと同じように、システムクラスローダーは必要に応じてクラスをロードするために含まれる構造を解析します。
とはいえ、HttpClientの場合のように、サードパーティのライブラリを使用する場合は、 JARだけをダウンロードすることはめったにありません。明らかに、サードパーティのライブラリにはクラスだけでなく、ほとんどのクラスにドキュメント、例、さらにはソースコードが含まれています。ただし、サードパーティライブラリを使用するプロセスは同じです。使用するクラスを含むJARを抽出し、そのJARをクラスパスに追加する必要があります。
これはほぼ完全な話です。一般的なアプリケーションで使用されるサードパーティライブラリの数が増えるにつれて、これらのライブラリの管理の問題も増え、Ant with Ivy、最近ではMavenが普及しました。ビルド機能に加えて、アプリケーションが依存するサードパーティライブラリを宣言し、それらのライブラリをダウンロードしてクラスパスに追加するプロセスを合理化する方法を提供します。しかし、彼らがしていることは、ライブラリをダウンロードして手動でクラスパスに追加する場合とまったく同じです。