|
JavaTM 拡張機能の FAQ
|
目次
標準拡張機能とはどのようなものですか。
拡張機能は、プログラミング言語 Java で書かれたクラス (およびそれに関連するネイティブコード) のパッケージで、拡張機能を使うことにより、アプリケーションの開発者は Java プラットフォームのコア部分の機能を拡張できます。拡張機能機構により、システムクラスとほとんど同じように Java Virtual Machine (VM) から拡張機能クラスを利用できます。これに加えて、必要な拡張機能が JDKTM ソフトウェアにインストールされていない場合に、指定された URL からそれを取得することも可能になります。
「標準」拡張機能は、コア API に含まれない Java API を実装した拡張機能のうち、オープンに公開されており、統一的で適合性が確かめられた (つまり「標準」) と、Sun が認定した拡張機能を指します。API が標準拡張機能と見なされるためには、次の 3 つが必要です。
- API を説明した完全な仕様書
- 実装のテストと検証を可能にするための Java Compatibility Kit
- リファレンス実装 (プラットフォーム固有のものでも可)
標準拡張機能が必要な理由は何ですか。
Java プラットフォームのコア部分のサイズは、Version 1.0 のリリース以来、確実に増加の一途をたどっています。最初の Java プラットフォームのコアパッケージ数は 8 でしたが、Version 1.1 では 22 パッケージに増え、Version 1.2 では 50 パッケージを超えています。拡張機能機構は、コア API のサイズを増やさずに、必要に応じて Java プラットフォームに機能を追加する標準的な手段を提供します。
拡張機能はどのようにしてパッケージにするのですか。
拡張機能は、1 つまたは複数の Java Archive (JAR) ファイルにまとめられます。拡張機能は、複数の JAR ファイルで構成されることもあります。その場合、どれかの JAR ファイルが、拡張機能名を指定するとともに拡張機能を構成するほかの JAR ファイルを参照する主 JAR ファイルになります。
JAR ファイルが拡張機能となるのは、次の 2 つの場合です。
- Java Runtime Environment の
lib/ext
ディレクトリ (JDK ソフトウェアの jre/lib/ext に相当する) に置かれた場合。このような拡張機能を「インストール型」拡張機能と呼ぶ
- アプレットまたはアプリケーションが含まれる JAR ファイルのマニフェストの Class-Path ヘッダで参照された場合。このような拡張機能を「ダウンロード型」拡張機能と呼ぶ
インストール型拡張機能とダウンロード型拡張機能の違いは何ですか。
拡張機能の主 JAR ファイルが、JDK または JRE のディレクトリ構造の次のディレクトリに置かれた場合、この拡張機能はインストール型拡張機能になります。
<java-home>/lib/ext [すべて, 信頼できる]
<java-home>
は、Java Runtime Environment (または JDK ソフトウェアの jre ディレクトリ) のトップレベルのディレクトリです。インストール型拡張機能のネイティブコードバイナリは、存在する場合は次のディレクトリに置きます。
<java-home>¥bin [Win32]
<java-home>/lib/<arch> [Solaris]
<arch> は、Solaris プロセッサアーキテクチャ (sparc
または i386
) です。
ダウンロード型拡張機能は、アプレット、アプリケーション、またはその他の拡張機能のマニフェストの Class-Path ヘッダから参照されている JAR ファイルです。Class-Path ヘッダの例を次に示します。
Class-Path: servlet.jar infobus.jar acme/beans.jar
この場合、servlet.jar
、infobus.jar
、および acme/beans.jar
に含まれるクラスがアプレットまたはアプリケーションの拡張機能になります。Class-Path フィールドに URL を指定した場合、その URL は、アプレットまたはアプリケーションが含まれる JAR ファイルの URL からの相対 URL になります。
インストール型拡張機能とダウンロード型拡張機能の間には、次のような違いがあります。
- インストール型拡張機能のクラスは、同じ Virtual Machine 上のすべてのコードによって共有される。これに対して、ダウンロード型拡張機能のクラスは、そのダウンロード型拡張機能を使用するアプリケーションまたはアプレットのセッションによってしか使用されない
- 拡張機能は、その JAR ファイルが
<java-home>/lib/ext
(ここで <java-home> は Java Runtime Environment または JDK ソフトウェアの jre のトップレベルのディレクトリ) に置かれることによってインストール型拡張機能となる。一方、ダウンロード型拡張機能となる JAR ファイルが置かれる位置には何の意味もない。ダウンロード型拡張機能は、ほかの JAR ファイルのマニフェストの Class-Path ヘッダから参照されるため、拡張機能となる
- JAR ファイルに含められたアプレットやアプリケーションだけがダウンロード型拡張機能を利用できる。JAR ファイルに含められていないアプレットやアプリケーションは、ダウンロード型拡張機能を参照するマニフェストを持たない
拡張機能内のクラスはどのようにして呼び出されるのですか。
VM は、特定の名前のクラスを探すとき、最初にコア API のクラスを検索します。システムクラスの中に目的のクラスがない場合は、次にインストール型拡張機能からそのクラスを検索します。システムクラスからもインストール型拡張機能からも見つからない場合は、アプリケーションまたはアプレットが参照しているダウンロード型拡張機能を検索します。拡張機能の JAR ファイルをクラスパスに含める必要はありません。
Sun は標準拡張機能を無償で提供する予定ですか。
Sun では、無料の標準拡張機能と有料の「プレミアム」拡張機能の 2 つの形態を考えています。Sun が拡張機能のバイナリリリースとともにソースをリリースするかどうかは (有料か無料かを含めて)、状況を見ての判断になります。標準拡張機能の仕様は無料です。
標準拡張機能にプラットフォーム固有のネイティブコードを含めることはできますか。
インストール型の標準拡張機能の実装には、ネイティブコードを含めることができます。さらに、プロパティ、ローカリゼーションカタログ、イメージ、直列化されたデータなどのリソースが使用されることもあります。
プラットフォームに固有の実装の場合、インストールプログラムは、JDK または JRE のディレクトリ構造に拡張機能をインストールする前に、拡張機能がどのプラットフォーム用かをユーザに問い合わせます。
標準拡張機能をほかの拡張機能に依存させることはできますか。
ほかの標準拡張機能のパブリックな API に依存させることができます。
標準拡張機能にはどのような名前が付けられますか。
標準拡張機能には、javax.* の名前空間内の名前が付けられます。ただし、オープンスタンダードの理由から必要な場合など、場合によって例外も認められるようになる予定です。ただし、パッケージ名が javax で始まるという理由だけでは、そのパッケージがコアプラットフォームの一部ではなく拡張機能であるということにはなりません。Swing パッケージには javax で始まる名前が付けられ、それが Version 1.2 プラットフォームより前の、コア拡張機能ではない拡張機能であることを示します。これらの名前は、javax.* の名前空間内にあっても、コア 1.2 プラットフォームの一部です。
標準拡張機能は Java Development Kit に含めてリリースされるのですか。
標準拡張機能は、必ずしも Java Development Kit に含めてリリースされるわけではありません。標準拡張機能は、リリースの際は現在の Java プラットフォームで使用できるようにしなければならず、将来のバージョンの Java プラットフォームは、既存の標準拡張機能が使用できるようにしなければなりません。
Java のライセンス契約者は標準拡張機能を採用しなければならないのですか。
ライセンス契約者が採用しなければならないのは、コアプラットフォームのパッケージだけです。標準拡張機能を採用する必要はありません。
標準拡張機能は、コアパッケージのようにさまざまなプラットフォーム間で広く利用できるようになるのですか。
これは場合によります。Sun の目標は javax パッケージを広く利用できるようにすることです。javax パッケージによっては、Java Development Kit に含められ無償で提供されるものもあれば、無償でダウンロードできるようになるものもあります。また、有償でライセンスが与えられるようになるものもあります。Sun では、Java プラットフォームのベンダーが、自社製品に多くの標準拡張機能を含めるようになることを期待しています。
標準拡張機能と 100% Pure Java とはどのような関係がありますか。
Sun がリリースする、プラットフォームに依存しない標準拡張機能は、通常は 100% Pure Java として認定されます。
アプリケーションで標準拡張機能を使用しても 100% Pure Java ロゴプログラムに準拠していると見なされますか。
使用する標準拡張機能が 100% Pure である場合だけそうなります。100% Pure の認定を受けるためには、アプリケーションと、アプリケーションで使用する拡張機能の両方を提出しなければなりません。アプリケーションと、それが使用するすべての標準拡張機能がテストの対象になります。100% Pure の標準拡張機能では、テストの負担が大幅に緩和されますが、100% Pure の認定を受けていない標準拡張機能であっても、アプリケーションと組み合わせた場合、標準拡張機能の使われ方によっては 100% Pure 認定の用件を満たすことがあります。
標準拡張機能にはどのようなものがありますか。
拡張機能はバージョン管理されますか。
1.2 Java プラットフォームの拡張機能機構では、バージョン管理機能は独自に提供してはいませんが、拡張機能のパッケージは、すべてのパッケージと同じように JDK 1.2 のパッケージのバージョン ID 機能を使用できます。
セキュリティについてはどのようになっていますか。
拡張機能は、オプションでインストールされたシステムコードとして扱われるため、インストールされているセキュリティマネージャの制限を考慮する必要があります。拡張機能は、セキュリティマネージャインタフェースに変更を加えなければならなくなるような、セキュリティにかかわる新しい動作はしません。
ネットワーク経由でロードされる拡張機能が、制御されたシステムサービスにアクセスする必要がある場合は信頼できるものでなければなりません。信頼できる機関による署名が付けられたものであるか、信頼できる場所からロードされたものでなければなりません。
インストール型の拡張機能のコードソースには、事前に構成されたセキュリティポリシーが割り当てられています。インストール型の拡張機能に置かれた正確な信頼度レベルは、次の標準の Java ポリシー構成ファイルによって指定されます。
<java-home>/lib/security/java.policy
ここで、<java-home> は、Java Runtime Environment または JDK ソフトウェアの jre のトップレベルのディレクトリです。デフォルトのポリシーは、インストール型の拡張機能がシステムのクラスパスに置かれた場合と同一に動作できるようにします。これは、インストール型拡張機能がネイティブコードをロードするという必要性に基づいています。
Java 1.2 Security Model は、インストール型拡張機能のコードが信頼できないコードから呼び出された場合のために、ある種の安全策を提供しています。しかし、拡張機能のコードが特権ブロックを使用する場合は必ず、システムのコードと同じように、セキュリティ上の危険がないかどうかコードを十分に確認する必要があります。
リモートからロードされる拡張機能で、正常な動作のため、アクセスチェックが行われるシステムサービス (ファイル入出力など) にアクセスする必要があるものについては、信頼できる機関による署名が付けられたものであるか、信頼できる場所からロードされたものでなければなりません。