JARファイルは普及しているZIPファイル形式に基づくファイル形式で、多数のファイルを1つにまとめるために使用されます。 JAR ファイルは、基本的にはオプションのMETA-INFディレクトリを格納するZIPファイルです。 JARファイルは、コマンドラインJARツール、またはJavaプラットフォームでjava.util.jar APIを使用して作成できます。 JARファイルの名前には制約がないため、各プラットフォームで許可されているファイル名を使うことができます。
モジュラJARファイルは、最上位ディレクトリ(またはルート)ディレクトリにモジュール記述子module-info.classを持つJARファイルです。 モジュール記述子は、モジュール宣言のバイナリ形式です。 (マルチリリースJARファイルの項では、モジュラJARファイルの定義をさらに改良しています。)
モジュール・パスではなく、モジュール・パスにデプロイされたモジュラJARファイルは、明示的モジュールです。 依存およびサービス・プロバイダは、モジュール記述子で宣言されます。 モジュラJARファイルがクラス・パスにデプロイされている場合、非モジュラJARファイルと同様に動作します。
モジュール・パスにデプロイされた非モジュラJARファイルは、自動モジュールです。 JARファイルにメイン属性Automatic-Module-Name (「主な属性」を参照してください)がある場合、その属性の値はモジュール名、それ以外の場合、モジュール名はModuleFinder.of(Path...)で指定されたJARファイルの名前から導出されます。
マルチリリースJARファイルを使用すると、1つのJARファイルで複数のメジャー・バージョンのJavaプラットフォーム・リリースをサポートできます。 たとえば、マルチリリースJARファイルは、Java 8とJava 9の両方のメジャー・プラットフォーム・リリースに依存できます。この場合、一部のクラス・ファイルはJava 8のAPIに依存し、その他のクラス・ファイルはJava 9のAPIに依存します。 これにより、ライブラリおよびフレームワークの開発者は、Javaプラットフォームの特定のメジャー・バージョンのAPIの使用を、すべてのユーザーがそのメジャー・バージョンに移行するという要件から切り離すことができます。 ライブラリおよびフレームワークの開発者は、古い機能をサポートしながら、新しいJava機能への移行とサポートを段階的に行うことができます。
マルチリリースJARファイルは、メイン属性によって識別されます。
Multi-Release: trueJARマニフェストのメイン・セクションで宣言されています。
Javaプラットフォーム・リリースのメジャー・バージョン9以上に依存するクラスおよびリソース・ファイルは、最上位(またはルート)ディレクトリの下ではなく、バージョニングされたディレクトリの下に配置できます。 バージョン管理されたディレクトリは、META-INFディレクトリの下にあり、次の形式になります。
META-INF/versions/Nここで、Nは、Javaプラットフォーム・リリースのメジャー・バージョン番号の文字列表現です。 具体的には、Nは仕様に準拠している必要があります。
| N: | {1-9} {0-9}* |
Nの値が9より小さいバージョニングされたディレクトリは、前述の仕様に準拠しないNの文字列表現として無視されます。
バージョンNのバージョニングされたディレクトリの下のクラス・ファイルは、マルチリリースJARのクラス・ファイル・バージョンが、Javaプラットフォーム・リリースのN番目のメジャー・バージョンに関連付けられたクラス・ファイル・バージョン以下である必要があります。 クラス・ファイルのクラスがpublicまたはprotectedの場合、そのクラスは、クラス・ファイルが最上位ディレクトリの下にある同じ完全修飾名とアクセス修飾子のクラスを保持する必要があります。 論理拡張子によって、これは、バージョンがNより小さいバージョニングされたディレクトリにあるクラス・ファイルのクラス(存在する場合)に適用されます。
マルチリリースJARファイルが、Javaプラットフォーム・リリース・ランタイムのメジャー・バージョンNのクラス・パスまたはモジュール・パス(自動モジュールまたは明示的なマルチリリース・モジュールとして)にデプロイされている場合、クラス・ローダー・ロードそのJARファイルからのクラスは、最初にNバージョン・ディレクトリの下のクラス・ファイルを検索し、次に、以前のバージョン・ディレクトリを降順(存在する場合)、9の下位のメジャー・バージョン・バウンドまで、最後に最上位のディレクトリの下から検索します。
マルチリリースJARファイルのクラスによってエクスポートされるパブリックAPIは、バージョン間で正確に同じである必要があります。したがって、バージョン管理されたディレクトリ下のクラス・ファイルのバージョン管理されたパブリック・クラスまたは保護クラスが、最上位ディレクトリ下のクラス・ファイルのクラスよりも優先される理由が最低限必要です。 jarツールなどのツールなど、広範なAPI検証チェックを実行することは困難でコストがかかります。大規模な検証を実行する必要はなく、Javaランタイムで検証を実行する必要はありません。 この仕様の将来のリリースでは、慎重な進化をサポートするために、まったく同じAPI制約が緩和される可能性があります。
META-INFディレクトリの下のリソースをバージョニングできません(サービス構成など)。
マルチリリースJARファイルには署名できます。
マルチリリースJARファイルは、Javaランタイムのブート・クラス・ローダーではサポートされていません。 マルチリリースJARファイルが(-Xbootclasspath/aオプションを使用して)ブート・クラス・パスに追加されると、JARは通常のJARファイルであるかのように扱われます。
モジュラ・マルチリリースJARファイルは、モジュール記述子module-info.classを持つマルチリリースJARファイルで、最上位ディレクトリ(モジュラJARファイル用)または直接バージョニングされたディレクトリ内にあります。
(モジュール記述子でエクスポートされたものとして宣言されていない)非エクスポート・パッケージ内のpublicまたはprotectedクラスは、クラス・ファイルが最上位ディレクトリの下にある同じ完全修飾名とアクセス修飾子のクラスを優先する必要はありません。
モジュール記述子は、通常、ほかのクラスやリソースファイルとは異なる方法で扱われます。 モジュール記述子は、バージョン管理された領域の下に存在していても、最上位ディレクトリの下には存在していません。 これにより、たとえば、Java 8バージョニングされたクラスのみが最上位ディレクトリの下に存在し、Java 9バージョニングされたクラス(モジュール・ディスクリプタを含む、またはモジュール・ディスクリプタのみ)が9バージョニングされたディレクトリの下に存在することが保証されます。
バージョニングされていないモジュール記述子、またはトップレベルのMが保持するバージョニングされたモジュール記述子は、2つの例外を除いて、Mと同一である必要があります。
java.*モジュールとjdk.*モジュールのtransitive以外のrequires句を、あらかじめバージョン管理されているディスクリプタと、java.*およびjdk.*モジュールの外部で定義されたサービス・タイプであっても、あらかじめバージョン管理されているディスクリプタには、異なるuses句を指定できます。ツール(jarツールなど)では、バージョニングされたモジュール記述子の検証を実行する必要がありますが、検証を実行するためにJavaランタイムは必要ありません。
META-INFディレクトリ内の次のファイル/ディレクトリは、アプリケーション、クラス・ローダーおよびサービスを構成するためにJava 2プラットフォームによって認識および解釈されます。
MANIFEST.MFパッケージ関連データの定義に使用されるマニフェスト・ファイル。
INDEX.LISTこのファイルは、アプリケーションで定義されたパッケージの場所情報を含むjarツールの新しい-i"オプションによって生成されます。 JarIndex実装に組み込まれており、クラスのロード処理を速くするためにクラス・ローダーによって使用されます。
x.SFJARファイルのシグネチャ・ファイル。'x'は、ベース・ファイル名を表します。
x.DSA同じベース・ファイル名を持つ署名ファイルに関連付けられた署名ブロック・ファイル。 対応する署名ファイルのデジタル署名が格納されます。
services/このディレクトリには、クラス・パスにデプロイされたJARファイルまたはモジュール・パスに自動モジュールとしてデプロイされたJARファイルのすべてのサービス・プロバイダ構成ファイルが格納されます。 詳細は、サービス・プロバイダ開発の仕様を参照してください。
versions/このディレクトリには、multi-release JARファイルのバージョニングされたクラスおよびリソース・ファイルの下に格納されます。
各構成ファイルの内容を詳細に設定する前に、形式の規則をいくつか定義する必要があります。 ほとんどの場合、マニフェスト・ファイルおよびシグネチャ・ファイルに含まれる情報は、RFC822標準によって示される、いわゆる"name: value"ペアとして表されます。 これらのペアは、ヘッダーまたは属性とも呼ばれます。
名前と値のペアのグループは、"セクション"と呼ばれます。 セクションはほかのセクションと空白行で分けられます。
バイナリ・データは、どの形式であれbase64で表されます。 行の長さが72バイトを超えるようなバイナリ・データについては継続が必要です。 バイナリ・データの例はダイジェストおよび署名です。
実装によっては、65535バイトまでのヘッダー値がサポートされます。
このドキュメントの仕様には同一の文法が使われており、終端記号は固定幅のフォントで示され、終端以外の記号はイタリック体で示されています。
| セクション: | *header +newline |
| 空でないセクション: | +header +newline |
| newline: | CR LF | LF | CR (その後に続かない LF) |
| header: | name : 値 |
| name: | 英数字*headerchar |
| value: | SPACE *otherchar newline *continuation |
| continuation: | スペース *otherchar newline |
| 英数字: | {A-Z} | {a-z} | {0-9} |
| headerchar: | alphanum | - | _ |
| otherchar: | NUL, CRおよびLFを除く任意のUTF-8文字 |
上の仕様で定義されている終端以外の記号は、以降の仕様で使われています。
JARファイル・マニフェストは、メイン・セクションと各JARファイル・エントリの複数の個別セクションで構成され、それぞれ改行文字で区切られています。 メイン・セクションおよび個別セクションは、すでに説明したセクションの構文に準拠しています。 各セクションには、固有の制約と規則があります。
メイン・セクションには、JARファイル自体およびアプリケーションに関するセキュリティおよび構成情報が含まれます。 また、各マニフェスト・エントリに適用されるメイン属性も定義します。 このセクションには、"Name"と同じ名前の属性はありません。 メイン・セクションは、空白行で終わります。
個別のセクションでは、このJARファイルに格納されているパッケージまたはファイルの様々な属性を定義します。 JARファイル内のすべてのファイルをマニフェストのエントリにリストする必要はありませんが、署名するすべてのファイルはリストする必要があります。 マニフェスト・ファイル自体はリストしないでください。 各セクションは"Name"という名前の属性で始まり、その値はファイルへの相対パス、またはアーカイブ外のデータを参照する絶対URLである必要があります。
1つのファイル・エントリに複数の個別セクションがある場合は、これらのセクションの属性はマージされます。 特定の属性の値がセクションによって異なる場合は、最後のセクションの値が認識されます。
理解できない属性は無視されます。 アプリケーションによって使われる実装固有の情報に、理解できない属性が含まれていることがあります。
| マニフェストファイル: | メインセクションの改行*個別セクション |
| メインセクション: | version-info newline *メイン属性 |
| バージョン情報: | Manifest-Version : バージョン番号 |
| バージョン番号: | digit+{.digit+}* |
| main属性: | (任意の正当な主要属性)改行 |
| 個別セクション: | Name : value 改行*perentry-attribute |
| perentry-attribute: | (任意の正当なエントリ属性)復帰改行 |
| newline: | CR LF | LF | CR (その後に続かない LF) |
| digit: | {0-9} |
上の仕様では、メイン・セクションに指定した属性はメイン属性、個別セクションに指定した属性はエントリ別属性として参照されます。 属性によっては、メイン・セクションと個別セクションの両方で指定できます。この場合、そのエントリでは、メイン属性の値はエントリ別属性の値によってオーバーライドされます。 これら2種類の属性は、次のように定義されます。
メイン属性は、マニフェストのメイン・セクションに指定されている属性です。 メイン属性は、次のグループに分類されます。
jarツールによって生成される。 automatic modulesの仕様を参照してください。 java -jar x.jar"を実行してjavaランタイムから直接起動できる、実行可能jarファイルにバンドルされたスタンドアロン・アプリケーションで使用されます。
.class」が付いていてはならない。 java.lang.instrumentパッケージのサマリーに指定されている2つの形式のいずれかで、パブリック静的メソッド名agentmainを定義します。 追加属性(Can-Retransform-Classesなど)を使用して、エージェントに必要な機能を指定できます。 エントリ別属性は、そのマニフェスト・エントリが関連付けられている個別のJARファイル・エントリにだけ適用されます。 メイン・セクションに同じ属性も表示された場合、エントリごとの属性の値は、メイン属性の値を上書きします。 たとえば、JARファイルa.jarには、次のコンテンツがマニフェストに定義されています。
Manifest-Version: 1.0
Created-By: 1.8 (Oracle Inc.)
Sealed: true
Name: foo/bar/
Sealed: falseこの場合、foo.barパッケージを除き、a.jar内にアーカイブされているパッケージがすべてシールされます。
エントリ別属性は、次のグループに分類されます。
JARファイルに署名するには、コマンド行jarsignerツールを使うか、java.security APIを直接使います。 JARファイルをjarsignerツールで署名した場合は、META-INFディレクトリ内の署名に関係しないファイルを含め、すべてのファイル・エントリが署名されます。 署名に関係するファイルは次のとおりです。
META-INF/MANIFEST.MFMETA-INF/*.SFMETA-INF/*.DSAMETA-INF/*.RSAMETA-INF/SIG-*署名に関係しないファイルがMETA-INFサブディレクトリ内にあっても、それらのファイルは署名に関係するファイルとは見なされません。 上記のファイル名と大文字と小文字の区別が異なるファイル名は予約済みで、それらのファイルは署名されません。
JARファイルのサブセットを署名するには、java.security APIを使用します。 署名されたJARファイルは、ファイルのマニフェストが更新されていることとMETA-INFディレクトリに署名ファイルと署名ブロック・ファイルが追加されていることを除けば、元のJARファイルとまったく同じです。 jarsignerを使用しない場合、署名プログラムは、署名ファイルと署名ブロック・ファイルの両方を構築する必要があります。
署名付きJARファイル内で署名されたすべてのファイル・エントリについて、そのエントリがすでにマニフェスト内に存在していないかぎり、個別のマニフェスト・エントリが作成されます。 各マニフェスト・エントリには、1つまたは複数のダイジェスト属性とオプションのMagic属性がリストされます。
各署名者は、拡張子が.SFの署名ファイルによって表されます。 このファイルの大部分は、マニフェスト・ファイルと同じです。 このファイルは、署名者から提供された情報を含むメイン・セクションで構成されますが、この情報は特定のjarファイル・エントリに固有のものではありません。 メイン・セクションには、Signature-VersionおよびCreated-By属性(「メイン属性」を参照)に加えて、次のセキュリティ属性を含めることができます。
java.security.MessageDigestアルゴリズムの標準名)。この属性の値は、マニフェストのメイン属性のダイジェスト値になる。java.security.MessageDigestアルゴリズムの標準名)。この属性の値は、マニフェスト全体のダイジェスト値になる。メイン・セクションの後には、個々のエントリのリストが続きます。それらのエントリの名前も、マニフェスト・ファイル内に存在する必要があります。 それぞれの個別エントリには、少なくともマニフェスト・ファイル内の対応するエントリのダイジェストが含まれている必要があります。
マニフェスト・ファイルに登場するが署名ファイルには登場しないパスまたはURLは、計算に使用されません。
JARファイルの検証が成功するのは、署名が有効であり、かつ署名の生成以後にJARファイル内のどのファイルも変更されていない場合です。 JARファイルの検証は、次のステップで行われます。
マニフェストがはじめて解析されるときに、署名を署名ファイルに対して検証します。 効率化のために、この検証結果を記録しておくことができます。 この検証では、実際のアーカイブ・ファイルでなく、署名そのものだけが検証されます。
署名ファイルに1つのx-Digest-Manifest属性が存在する場合は、マニフェスト全体から計算したダイジェストに照らして値を検証します。 署名ファイルに複数のx-Digest-Manifest属性が存在する場合は、そのうち少なくとも1つが計算したダイジェスト値と一致することを検証します。
署名ファイルにx-Digest-Manifest属性が存在しないか、前のステップで計算したダイジェスト値がいずれも一致しない場合は、効率的に劣る方法で検証が行われます。
署名ファイルに1つのx-Digest-Manifest-Main-Attributesエントリが存在する場合は、マニフェスト・ファイル内のメイン属性から計算したダイジェストに照らして値を検証します。 この計算に失敗すると、JARファイルの検証が失敗します。 この判断は、効率化のために記録しておくことができます。 署名ファイルにx-Digest-Manifest-Main-Attributesエントリが存在しなくても、JARファイルの検証に影響はなく、マニフェストのメイン属性が検証されないだけです。
署名ファイルの各ソース・ファイル情報セクション内の値を、マニフェスト・ファイルの対応するエントリから計算したダイジェスト値に照らして検証します。 いずれのダイジェスト値も一致しない場合、JARファイルの検証が失敗します。
x-Digest-Manifest属性に格納されたマニフェスト・ファイルのダイジェスト値が現在のマニフェスト・ファイルのダイジェスト値と一致しない場合は、署名(および署名ファイル)の生成後に(jarツールを使用して) JARファイルに1つ以上のファイルが追加された可能性があります。 jarツールを使用してファイルを追加した場合、マニフェスト・ファイルは(新しいファイル用のセクションが追加されて)変更されますが、署名ファイルは変更されません。 この場合、署名ファイルのヘッダー以外のセクションに格納されたダイジェスト値が、マニフェスト・ファイル内の対応するセクションのダイジェスト値と一致するときは、署名の生成時にJARファイル内に存在していたファイルのうち、どのファイルも変更されていないことになり、検証は成功したものとして扱われます。
マニフェストの各エントリについて、相対ファイル・パスまたはURLのいずれかを指定する"Name:"属性で参照される実際のデータに対して計算されたダイジェストに対して、マニフェスト・ファイルのダイジェスト値を検証します。 いずれのダイジェスト値も一致しない場合、JARファイルの検証が失敗します。
マニフェスト・ファイルの例:
Manifest-Version: 1.0
Created-By: 1.8.0 (Oracle Inc.)
Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)
Name: common/class2.class
SHA1-Digest: (base64 representation of SHA1 digest)
SHA-256-Digest: (base64 representation of SHA-256 digest)対応する署名ファイルは次のようになります。
Signature-Version: 1.0
SHA-256-Digest-Manifest: (base64 representation of SHA-256 digest)
SHA-256-Digest-Manifest-Main-Attributes: (base64 representation of SHA-256 digest)
Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)
Name: common/class2.class
SHA-256-Digest: (base64 representation of SHA-256 digest)特定のマニフェスト・エントリ上で署名を有効化するためにもう1つ必要なことは、そのエントリのマニフェスト・エントリ内のMagicキー・ペア値の値をベリファイアが理解することです。
Magic属性はオプションですが、パーサーがそのエントリの署名を検証する場合は、エントリのMagicキーの値を理解する必要があります。
Magic属性の値は、カンマで区切られたコンテキスト固有の文字列のセットです。 カンマの前後の空白は無視されます。 大文字小文字も無視されます。 Magic属性の正確な意味はアプリケーションによって異なります。 これらの属性は、マニフェスト・エントリに含まれるハッシュ値の計算方法を示し、そのため署名の正しい検証には欠くことのできないものです。 このキーワードは、動的または埋込みコンテンツ、多国語ドキュメント用の複数ハッシュなどに使用します。
次に、マニフェスト・ファイルでのMagic属性の使用例を2つ示します。
Name: http://www.example-scripts.com/index#script1
SHA-256-Digest: (base64 representation of SHA-256 hash)
Magic: JavaScript, Dynamic
Name: http://www.example-tourist.com/guide.html
SHA-256-Digest: (base64 representation of SHA-256 hash)
SHA-256-Digest-French: (base64 representation of SHA-256 hash)
SHA-256-Digest-German: (base64 representation of SHA-256 hash)
Magic: Multilingual最初の例では、これらMagicの値はhttp問い合わせの結果がドキュメント自身ではなく、ドキュメントに埋め込まれたスクリプトであり、またそのスクリプトが動的に生成されるということを示します。 この2つの情報は、マニフェストのダイジェスト値と比較し、有効な署名と比較するハッシュ値の計算方法を示します。
第2の例では、Magic値は検索されたドキュメントの内容は特定の言語であるという合意を示し、検証のためのダイジェストの値は検索されたドキュメントを記述する言語に依存することを示します。
デジタル署名とは、署名された.SF署名ファイルです。 これらはバイナリ・ファイルであり、人間が解釈することは意図されていません。
デジタル署名ファイルは、.SFファイルとファイル名は同じですが、拡張子が異なります。 拡張子はデジタル署名のタイプによって変化します。
.RSA (PKCS7署名、SHA-256+RSA).DSA (PKCS7署名、DSA)前述にリストされていないシグネチャ・アルゴリズムのデジタル・シグネチャ・ファイルは、META-INFディレクトリにあり、プレフィクス"SIG-"が必要です。 対応する署名ファイル(.SFファイル)にも同じ接頭辞を付けなければなりません。
外部署名データをサポートしない形式については、ファイルは.SFファイルの署名されたコピーで構成されることになります。 したがって、一部のデータが重複する可能性があるため、ベリファイアは2つのファイルを比較する必要があります。
外部データをサポートする形式は、.SFファイルを参照するか、暗黙的な参照によって計算を実行します。
各.SFファイルは複数のデジタル署名を持つ可能性がありますが、これらの署名は同じ正当なエンティティによって生成される必要があります。
ファイル名の拡張子には、1 - 3文字の英数字を使うことができます。 認識されない拡張子は無視されます。
ここでは、マニフェストおよび署名ファイルに適用されるその他の制約および規則について説明します。
1.3から、ネットワーク・アプリケーション、特にアプレットのクラス・ローダーによるクラス検索処理を最適化するために、JarIndexが導入されています。 当初、アプレット・クラス・ローダーは単純な線形検索アルゴリズムを使用して、"ARCHIVE"タグまたは"Class-Path"メイン属性から構築される内部検索パス上の各要素を検索します。 クラスまたはリソースが検出されるまで、クラス・ローダーによって検索パスの各要素がダウンロードされて開かれます。 クラス・ローダーが存在しないリソースの検索を試行した場合、アプリケーションまたはアプレット内のjarファイルがすべてダウンロードされることになります。 この結果、大きなネットワーク・アプリケーションおよびアプレットの場合は、起動および応答が遅くなり、ネットワーク帯域幅が浪費される可能性があります。 JarIndexメカニズムでは、アプレットに定義されているすべてのjarファイルのコンテンツが収集され、アプレットのクラス・パスにある最初のjarファイルのインデックス・ファイルに情報が格納されます。 最初のjarファイルがダウンロードされると、アプレット・クラス・ローダーでは収集されたコンテンツ情報を使用して効率的にjarファイルがダウンロードされます。
既存のjarツールの機能が拡張され、jarファイルのリストを検査して、クラスおよびリソースがどのjarファイルに配置されているかについてのディレクトリ情報を生成できるようになりました。 このディレクトリ情報は、ルートjarファイルのMETA-INFディレクトリにあるINDEX.LISTという名前の、単純なテキスト・ファイル内に格納されます。 クラス・ローダーによって、ルートjarファイルがロードされ、INDEX.LISTファイルが読み込まれ、そのファイルを使用して、ファイル名とパッケージ名からjarファイル名のリストへのマッピングを格納したハッシュ表が構築されます。 クラス・ローダーがクラスまたはリソースを検索する場合、ハッシュ表を問い合わせて適切なjarファイルを検出した後、必要に応じてダウンロードします。
クラス・ローダーによって、特定のjarファイルでINDEX.LISTファイルが検出されると、そのファイルにリストされた情報は常に信頼されます。 特定のクラスに対してマッピングが見つかったが、クラス・ローダーがリンクをたどってそれを見つけることができなかった場合は、未指定のエラーまたはRuntimeExceptionがスローされます。 この例外が発生した場合は、アプリケーション開発者は、拡張機能に対してjarツールを実行し直し、インデックス・ファイルに正しい情報を取得する必要があります。
大量の領域オーバーヘッドの発生をアプリケーションで回避し、インメモリー・ハッシュ表を高速で構築するために、INDEX.LISTファイルの容量はできるかぎり小さくなるように管理されます。 クラスのパッケージ名がnullでない場合は、マッピングはパッケージ・レベルで記録されます。 通常は、1つのパッケージ名が1つのjarファイルにマッピングされますが、パッケージが複数のjarファイルにわたる場合には、このパッケージのマップされた値はjarファイルのリストになります。 リソース・ファイルにディレクトリの接頭辞がある場合は、マッピングはディレクトリ・レベルでも記録されます。 パッケージ名がnullのクラスの場合およびルート・ディレクトリにリソース・ファイルが格納されている場合にのみ、マッピングが個別のファイル・レベルで記録されます。
INDEX.LISTファイルには、1つ以上のセクションが含まれ、それぞれ1行の空白行で区切られています。 セクションごとに1つのjarファイルのコンテンツが定義されています。各セクションでは、jarファイルのパス名を定義するヘッダーの後に、パッケージ名またはファイル名のリストが1行ずつ続きます。 すべてのjarファイルのパスは、ルートjarファイルのコード・ベースを起点とする相対パスです。 これらのパス名は、バンドル型拡張機能が現在の拡張機能メカニズムによって解釈される方法と同じ方法で解決されます。
インデックス・ファイルのファイル名またはパッケージ名に、ASCII以外の文字が使われているときは、UTF-8エンコーディングが使われます。
| index file: | version-info空白行セクション* |
| バージョン情報: | JarIndex-Version: バージョン番号 |
| バージョン番号: | Digit+{.digit+}* |
| セクション: | ボディブランクライン |
| body: | ヘッダー名* |
| header: | char+.jar改行 |
| name: | 文字+改行 |
| 文字: | NULL, CRおよびLFを除く任意の有効なUnicode文字 |
| 空白行: | 改行 |
| newline: | CR LF | LF | CR (その後に続かない LF) |
| digit: | {0-9} |
INDEX.LISTファイルは、jar -i.を実行して生成されます 詳細は、jarのマニュアル・ページを参照してください。
新しいクラスのロード方式は、現在の拡張機能メカニズムを基にして開発されたアプリケーションと完全な下位互換性があります。 クラス・ローダーによって最初のjarファイルがロードされ、META-INFディレクトリ内でINDEX.LISTファイルが検出されたときは、インデックス・ハッシュ表が構築され、その拡張機能に対して新しいロード方式が使われます。 それ以外の場合、クラス・ローダーでは元の線形検索アルゴリズムが使われます。
アプリケーションのマニフェストでは、必要な他のライブラリのJARファイルおよびディレクトリを参照する1つ以上の相対URLを指定できます。 これらの相対URLは、含まれるアプリケーションのロード元のコード・ベースを基準にして扱われます。
アプリケーション(より一般的にはJARファイル)は、マニフェスト属性Class-Pathを介して必要なライブラリの相対URLを指定します。 この属性は、ホストJava Virtual Machineで他のライブラリが見つからない場合に、そのライブラリの実装を検索するためのURLをリストします。 この相対URLには、アプリケーションが必要とするライブラリまたはリソースが含まれるJARファイルとディレクトリを含めることができます。 '/'で終了していない相対URLは、JARファイルを参照すると想定されます。 たとえば、
Class-Path: servlet.jar infobus.jar acme/beans.jar images/JARファイルのマニフェストで指定できるClass-Pathヘッダーは1つだけです。
現時点では、セキュリティ上の理由により、URLはJARファイルのコード・ベースから相対的に指定する必要があります。 したがって、リモート・オプション・パッケージは、アプリケーションと同じコード・ベースを元にして指定します。
各相対URLは、含まれているアプリケーションまたはライブラリのロード元のコード・ベースに対して解決されます。 解決されたURLが無効であるか、参照するリソースが見つからない場合、そのURLは無視されます。
解決されたURLは、アプリケーション、アプレット、またはサーブレットのクラス・パスの拡張に使用され、クラス・パスの、そのアプリケーション、アプレット、またはサーブレットが含まれるJARファイルのURLの直後に挿入されます。 重複するURLは取り除かれます。 たとえば、次のようなクラス・パスが指定されているとします。
a.jar b.jarb.jarに次のClass-Pathマニフェスト属性が含まれている場合:
Class-Path: x.jar a.jar最終的なアプリケーション・クラス・パスは次のようになります。
a.jar b.jar x.jarもちろん、x.jarに依存情報が含まれる場合は、依存ファイルはこれと同じ規則に従って追加されます。後に続くURLについても同様です。 実際の実装では、JARファイルの依存関係が遅延して処理されるため、JARファイルは必要になるまで実際に開かれません。
JARファイルとパッケージは、同一バージョン内で整合性が保たれるように、オプションでシール,することができます。
JARファイル内のパッケージをシールした場合、そのパッケージ内で定義されているすべてのクラスは、同一のJARファイルが元になっていなければなりません。 そうでない場合は、SecurityExceptionがスローされます。
JARファイルをシールした場合、そのJARファイルで定義されているすべてのパッケージは、特別に設定をオーバーライドしないかぎり、シールされます。
パッケージをシールするかどうかは、マニフェスト属性Sealedで指定します。このマニフェスト属性は、trueかfalseの値をとります。大文字小文字は区別されません。 たとえば、
Name: javax/servlet/internal/
Sealed: trueこのように指定すると、javax.servlet.internalがシールされ、このパッケージに含まれるすべてのクラスは同一のJARファイルからロードされなければなりません。
この属性が指定されていない場合は、パッケージのシール属性は、そのパッケージが含まれるJARファイルのシール属性と同じになります。
JARファイルをシールするかどうかは、上と同じマニフェスト・ヘッダーSealedで指定します。このマニフェスト・ヘッダーも、同じくtrueかfalseの値をとります。 たとえば、
Sealed: trueこのように指定すると、このアーカイブに含まれるすべてのパッケージは、マニフェスト・エントリの中でSealed属性により明示的に設定をオーバーライドしないかぎり、シールされます。
この属性が指定されていない場合は、下位互換性を保つため、そのJARファイルはシールされていないものとみなされます。 このあと、システムはシール情報を見るため、パッケージのヘッダーのチェックを継続します。
パッケージをシールすると、パッケージ保護されたメンバーへのアクセスは、同一のJARファイルが元になるパッケージで定義されているクラスに制限されるため、パッケージのシールはセキュリティの上でも重要です。
名前のないパッケージはシール可能ではないため、シールされるクラスは独自のパッケージに配置する必要があります。
パッケージjava.util.jar
パッケージjava.security
パッケージjava.util.zip
Copyright © 1993, 2017, Oracle and/or its affiliates. All rights reserved.