クラスライブラリのアーカイブ化

クラスライブラリ（アプリケーション）のパッケージを アーカイブ形式にまとめる方法を解説します。
大規模なアプリケーションやクラスライブラリは、 複数のパッケージの集合体となります。 Javaではアプリケーションとクラスライブラリは、 その構造、内部のクラスの取り扱いなど、形式的な部分は全く同じです。 唯一の違いは、アプリケーションの中には最低１個は main()メソッドを含む クラスが存在し、Javaインタープリタによって直接起動されるという点だけです。 ここで説明するアプリケーションという言葉の中には、 JDKのような汎用のクラスライブラリも含まれると考えてください。
Javaでは１つのクラスは、どんなに規模が小さいものでも （たとえば内容を持たないインターフェイスでさえ）必ず単独のバイトコードの ファイルになります。 アプリケーションの規模が大きくなると、 当然ファイルの数は非常に多数となるでしょう。 しかも、それらはパッケージに対応する階層ディレクトリの中に格納されています。 この管理の方法は開発中には非常に効率的なのですが、 アプリケーションが完成してしまった後では必ずしも取り扱いやすいとは言えません。 特に完成したアプリケーションを製品として出荷する場合には、 コピーの操作だけでも大変ですし、ユーザーの側でも管理が面倒になってしまいます。 そこでアプリケーションを構成するパッケージやクラスを単独のファイルにまとめる 仕組みが必要になります。
このような「アーカイブ化」の方法は他の言語でも行われることですが、 Javaのユニークな点は、そのアーカイブ化のために採用したルールでしょう。 Javaの場合、アーカイブ化もシステムに依存しない方式で行なわなければなりません。 そこで、既に主要なシステムの上で利用可能となっている既存の圧縮形式の zip を 正式のアーカイブ化のルールに決めたのです。


単独のzipファイルにまとめれば扱いが容易になる

zip形式のファイルは、単独のファイルの中にディレクトリ構造のとその内部の ファイルの情報がそっくり格納されます。 したがって、zip形式のファイル自体を CLASSPATH の対象として指定します。 たとえば JDKのクラスライブラリが典型的な例ですが、 それらは classes.zip という名前のファイルにまとめられています。 仮にこのファイルが /usr/local/java/lib というディレクトリの中にあった とすると、 それに対するクラスパスの設定は次のように行うことになります。 


CLASSPATH=/usr/local/java/lib/classes.zip
zip形式のファイルの名前は classes.zip である必要はありません。 むしろ重要なのはパッケージの名称との対応です。 zip形式のファイルの中には ディレクトリ名としてパッケージの名称が保存されています。 実行する場合には、その名前も正しく指定する必要があります。 別の例を挙げましょう。 ziptool.zip というアーカイブ化されたパッケージがあり、 その中に Zip.class, UnZip.classなどのクラスが含まれているとします。 パッケージ名も ziptoolです。このアーカイブファイルがカレントディレクトリ に存在したとすると、クラスパスの指定と UnZipの実行は次のようになります。 （実行時の ziptool.zip は単なる引数の指定です。） 

CLASSPATH=./ziptool.zip
java ziptool.UnZip ziptool.zip

javaやjavacを始めとするツールも、zip形式のアーカイブにきちんと対応しています。 zip形式のアーカイブに変換しても各クラスの提供する機能に違いはありません。 あるいは、 圧縮された分だけコードをロードするための入力の処理の作業は短くなるという 利点もあります。