JP2023070452A - 情報処理装置、クラスのロード方法、集約の方法およびプログラム - Google Patents

Abstract

【課題】ファイル単位で権限が管理される環境において複数のファイルを１つの統合ファイルにまとめた場合であっても、統合ファイルに含まれた個々のファイルの単位で権限を管理することができる情報処理装置、クラスのロード方法、集約の方法及びプログラムを提供する。【解決手段】方法は、複数のライブラリファイル夫々に関連付く複数のライブラリファイル夫々に含まれるクラスの権限を保持する。アーカイブファイルは、複数のライブラリファイル夫々に含まれるクラスを特定するクラスマップをを有する。クラスローダは、設定された担当ライブラリファイルを特定する情報を保持し、クラスマップに基づいて、アーカイブファイルに含まれた担当ライブラリファイルから、指定されたクラスをロードし、ロードしたクラスに対して、当該クラスを含む担当ライブラリファイルに関連付けて保持されている権限を設定する。【選択図】図６

Description

本発明は、Ｊａｖａプログラムを実行するためのクラスローダ等を含む情報処理装置、クラスのロード方法、集約の方法およびプログラムに関する。

従来、複数のアプリケーションの権限を管理して実行する仕様Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ（ＯＳＧｉ）が普及している。アプリケーションの権限の管理は、Ｊａｖａ（登録商標）仮想マシン（以降ＪａｖａＶＭと記載）が標準で備えるセキュリティマネージャを用いて行う。セキュリティマネージャを用いる権限管理方法として、デバイスが保持するアプリケーションプログラムと、アプリケーションの権限を設定するポリシーファイルを個別に管理する仕組みが考案されている（例えば特許文献１参照）。

特許第５１３２７３０号公報

ＯＳＧｉでは、ＯＳ上の１プロセス上で複数のアプリケーションを実行できる。しかし、１プロセスで同時に開けるファイル数には上限がある。そのため、動かすアプリケーションが増えると、ＪａｖａＶＭが開くｊａｒファイルも増えて、上限に達してしまう。ｊａｒファイルは一般的なアーカイブファイルであるため、複数のｊａｒファイルを１つのｊａｒファイルとしてまとめなおせば、ＪａｖａＶＭが開くファイル数を削減することができる。しかし、セキュリティマネージャの権限管理はファイル単位で設定するため、複数のｊａｒファイルを１つのｊａｒファイルにまとめると、まとめられた個々のｊａｒファイルの権限を管理できなくなる課題が生じる。

本発案は上記の課題に鑑みてなされたものであり、ファイル単位で権限が管理される環境において複数のファイルを１つの統合ファイルにまとめた場合であっても、統合ファイルに含まれた個々のファイルの単位で権限を管理することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。すなわち、本発明の一側面によれば、クラスを含む複数のライブラリファイルを集約したアーカイブファイルから、前記複数のライブラリファイルのいずれかに含まれたクラスをロードするクラスローダを有する情報処理装置であって、
前記複数のライブラリファイルそれぞれに関連付けて前記複数のライブラリファイルそれぞれに含まれたクラスの権限を保持する第１の保持手段を有し、
前記アーカイブファイルは、前記複数のライブラリファイルそれぞれに含まれた前記クラスを特定するクラスマップを含み、
前記クラスローダは、
設定された担当ライブラリファイルを特定する情報を保持する第２の保持手段と、
前記クラスマップに基づいて、前記アーカイブファイルに含まれた前記担当ライブラリファイルから、指定されたクラスをロードするロード手段と、
前記ロード手段によりロードしたクラスに対して、当該クラスを含む前記担当ライブラリファイルに関連付けて前記第１の保持手段により保持されている権限を設定する権限設定手段と、を有する
ことを特徴とする情報処理装置が提供される。

また本発明の他の側面によれば、複数のライブラリファイルを１つのアーカイブファイルに集約する情報処理装置であって、
集約対象のライブラリファイルと該ライブラリファイルに含まれたクラスとを関連付けたクラスマップを生成する第１の生成手段と、
前記集約対象のライブラリファイルと該ライブラリファイルに含まれたリソースファイルとを関連付けたリソースマップを生成する第２の生成手段と、
集約対象のライブラリファイルに含まれたクラスの所在を示すリストと前記クラスマップと前記リソースマップとを含むアーカイブファイルを生成する第３の生成手段と、を有する
ことを特徴とする情報処理装置が提供される。

本発明によれば、ファイル単位で権限が管理される環境において複数のファイルを１つの統合ファイルにまとめた場合であっても、統合ファイルに含まれた個々のファイルの単位で権限を管理することができる。

情報処理装置のハードウェア構成の一例を示す概略図である。 情報処理装置上に構築するシステム構成の一例を示す模式図である。 ＯＳＧｉ仕様によるアプリケーションＦＷ２０４とＪａｖａＶＭ２０３の構成を示す模式図である。 約ｌｉｂ用クラスローダを備えるアプリケーションＦＷ２０４の構成を示す模式図である。 ＪａｖａＶＭ２０３上でｊａｒファイルが含むクラスをロードする処理の流れを示すフローチャートである。 実施形態１にかかる集約ｌｉｂ用クラスローダ４０１がクラスをロードして権限を設定する処理の流れを示すフローチャートである。 実施形態１にかかる複数のｊａｒファイルを１つのｊａｒファイルにまとめる処理の流れを示すフローチャートである。 実施形態２にかかるリソース取得の処理の流れを示すフローチャートである。 実施形態１にかかる権限を取得する処理の詳細についてフローチャートである。 実施形態１にクラスロード処理の詳細を示すフローチャートである。 実施形態４にかかるアプリケーションＦＷ２０４の起動処理を示すフローチャートである。 セキュリティマネージャ３０１に指示する権限の設定を記したセキュリティポリシーファイルの例を示す図である。 ｊａｒファイルに格納されているファイルのリストの例である。 マニフェストファイルの記載例を示す図である。 実施形態１にかかる集約したｌｉｂｓ．ｊａｒファイルの構成図である。 実施形態１にかかるｌｉｂｓ．ｊａｒを読み込むための集約ｌｉｂ用クラスローダの構成図である。 実施形態２にかかる集約ｌｉｂ用クラスローダ４０１の構成図である 実施形態４にかかる集約前後の各ｊａｒファイルの構成を示す図である。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜実施形態１＞
●ハードウェア
本発明の実施形態１におけるハードウェアとシステムの構成を説明する。図１は、一般的な情報処理装置１００のハードウェア構成の一例を示す図である。図１に示すように情報処理装置１００は、ハードウェア構成として、ＣＰＵ１１を含む。

ＣＰＵ１１が、記憶部１３に記憶されている後述するアプリケーションやプログラム実行環境等の各々に対応するプログラムに基づき処理を行うことによって、後述する各機能、又はフローチャートを実現する。

また、ＣＰＵ１１には、バス１０を介して、入力部１２、記憶部１３、表示部１４及び外部接続ＩＦ１５が接続されている。入力部１２は、情報を入力するキーボード及び／又はマウスである。記憶部１３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等を含み、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータ等を記憶する。表示部１４は、画面等を表示するディスプレイである。外部接続ＩＦ１５は、ネットワークインタフェース、外部機器との各種接続インタフェースである。

尚、ＣＰＵ１１はプログラムを実行することで各種の手段として機能することが可能である。なお、ＣＰＵ１１と協調して動作するＡＳＩＣなどの制御回路がこれらの手段として機能してもよい。また、ＣＰＵ１１と情報処理装置１００の動作を制御する制御回路との協調によってこれらの手段が実現されてもよい。また、ＣＰＵ１１は単一のものである必要はなく、複数であってもよい。この場合、複数のＣＰＵ１１は分散して処理を実行することが可能である。また、複数のＣＰＵ１１は単一のコンピュータに配置されていてもよいし、物理的に異なる複数のコンピュータに配置されていてもよい。なお、ＣＰＵ１１がプログラムを実行することで実現する手段が専用の回路によって実現されてもよい。

●ソフトウェア
次に、情報処理装置１００上に構築するシステム構成について、図２を用いて説明する。図２は、情報処理装置１００のシステム構成の一例を示す図である。オペレーティングシステム２０１（以降ＯＳ２０１と記載）は、システム全体の基盤となるソフトウェアである。プロセス２０２は、ＯＳ２０１上でソフトウェアを動作させる実行の単位である。プロセス２０２上では複数のプログラムを動作させることができる。複数のプログラムを一つのプロセス２０２上で動作させる利点は、プロセス２０２間の通信コストがなくなることである。ただし、一つのプロセス２０２が利用できるＯＳ２０１の資源には上限がある。資源とは、メモリやファイルディスクリプタを含む。ファイルディスクリプタ（以降、ＦＤと記載）とは、プロセス２０２がファイルを開くための資源である。

本実施形態では、ＯＳ２０１はＬｉｎｕｘ（登録商標）とする。一般的なＬｉｎｕｘ（登録商標）ではＦＤの上限は１０２４個である。単にＦＤの上限を増やすだけなら、リソースの上限を設定するｕｌｉｍｉｔコマンドで設定できる。しかし、ＯＳにはＦＤ集合のいずれか一つがＩ／Ｏを実行可能な状態になるのを待つｓｅｌｅｃｔコマンドがある。ｓｅｌｅｃｔコマンドはＦＤの上限を増やすと正しく動かなくなるため、ｓｅｌｅｃｔコマンドを利用している組み込み向けライブラリなどを実行するデバイスでは、ＦＤの上限を増やせない。

ＪａｖａＶＭ２０３は、プロセス２０２上で動作する。ＪａｖａＶＭ２０３上では、ＯＳＧｉの実装であるアプリケーションフレームワーク２０４（以降アプリケーションＦＷ２０４と記載）が動作する。アプリケーションＦＷ２０４に管理されて、複数のアプリケーション２０５が動作する。

●アプリケーションＦＷとＪａｖａＶＭの構成
次に、アプリケーションＦＷ２０４とＪａｖａＶＭ２０３の構成について図３を用いて説明する。ＪａｖａＶＭ２０３には、セキュリティマネージャ３０１が含まれる。アプリケーションＦＷ２０４は、各アプリケーション２０５をロードするためのアプリケーションクラスローダ３０２を生成して、アプリケーション２０５を実行する。アプリケーションクラスローダ３０２は、Ｊａｖａ標準のクラスローダを継承したものである。この構成はＯＳＧｉ仕様によるものであり、公知である。

Ｊａｖａ標準のクラスローダは生成時にＵＲＬの配列を受け取る仕様である。ｊａｒファイルのＵＲＬを受け取っておき、クラスロードの指示を受けた時にはＵＲＬで示されるｊａｒファイルを読みこんでクラスを探索し、該当するクラスが見つかればロードする。

一般的なｊａｒファイルの構成について図１３を用いて説明する。図１３は、ｊａｒファイルに格納されているファイルのリストの例である。

図１３（ａ）は、ｌｉｂＡ．ｊａｒのファイルのリストである。Ｊａｖａプログラムのクラスは、階層構造のパッケージで一意の名前になるようになっており、ｌｉｂＡ．ｊａｒにはｃｏｍ／ｃｉｎｃ／ｌｉｂａ．ＡクラスのファイルであるＡ．ｃｌａｓｓファイルが格納されている。

また、ｊａｒファイルにはマニフェストというキーバリュー形式のファイルを含めることができる。このマニフェストは、ｊａｒファイル内のＭＥＴＡ－ＩＮＦ／ＭＡＮＩＦＥＳＴ．ＭＦファイルとなるのが、ｊａｖａの仕様である。マニフェストファイルの記載例を、図１４に示す。Ｍａｎｉｆｅｓｔ－Ｖｅｒｓｉｏｎ項目はｊａｖａの仕様で定義されている項目である。さらにマニフェストには独自の定義を記載してよいため、図１４の例ではｌｉｂＶｅｒｓｉｏｎ項目を記載している。

また、ｊａｒファイルにはプログラムが表示する画像ファイルなどを含めることができる。図１３（ａ）のｌｉｂＡ．ｊａｒは、Ｉｍａｇｅフォルダにｌｏｇｏ．ｊｐｇファイルを含んでいる。同様に、図１３（ｂ）には、ｌｉｂＢ．ｊａｒのファイルのリストを示す。ｌｉｂＡ．ｊａｒとｌｉｂＢ．ｊａｒは一般的なｊａｒファイル形式なので、ＭＡＮＩＦＥＳＴ．ＭＦファイルは必ず同じパスになる。ただし、これらのＭＡＮＩＦＥＳＴ．ＭＦファイルの内容は異なる。また、図１３（ａ）（ｂ）では、ｌｉｂＡ．ｊａｒとｌｉｂＢ．ｊａｒが偶然にＩｍａｇｅディレクトリにｌｏｇｏ．ｊｐｇという画像ファイルを持つ例を示している。ただし同じｌｏｇｏ．ｊｐｇというファイル名でも、それぞれの画像はそれぞれ異なる。

●権限の設定
次に、セキュリティマネージャ３０１で権限を設定する方法について、図１２を用いて説明する。図１２は、セキュリティマネージャ３０１に指示する権限の設定を記したセキュリティポリシーファイルの一例である。

図１２に示すように、Ｊａｖａのセキュリティポリシーファイルは、ファイルの場所を指定して、そのファイルからロードされたクラスの権限を記載する。図１２の例では、クラスの権限として、ファイルへのアクセス権限（ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ）が、そのクラスを含むｊａｒファイルに関連付けて設定されている。すなわちセキュリティポリシーファイルは、ｊａｒファイルごとに権限を自保持する。図１２の例では、／ｌｉｂディレクトリのｌｉｂＡ．ｊａｒファイルからロードされたクラスには、ＦｉｌｅＸ．ｔｘｔへの読み込み権限（"ｒｅａｄ"）を設定している。同様に、ｌｉｂＢ．ｊａｒには、ＦｉｌｅＹ．ｘｍｌへの読み込みと書き込みの権限（"ｒｅａｄ，ｗｒｉｔｅ"）を設定している。ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ以外にも多くの権限があるが、Ｊａｖａの標準仕様なので詳細説明は省略する。

次に、Ｊａｖａ標準のクラスローダがセキュリティマネージャ３０１と連携して権限を設定する処理について、図５を用いて説明する。図５は、ＪａｖａＶＭ２０３上でｊａｒファイルが含むクラスをロードする処理の流れを示すフローチャートである。なお、前述のとおり、アプリケーションクラスローダ３０２はＪａｖａ標準のクラスローダを継承した子クラスのため、メソッドをオーバライドしなければ標準のクラスローダと同じ動きとなる。そこで以下の説明および図５では、アプリケーションクラスローダ３０２のことを単にクラスローダと呼んでいる。

クラスローダが図１３（ａ）に例示したｌｉｂＡ．ｊａｒからクラスＡを読み込む例で説明する。ロードを開始すると、クラスローダはｌｉｂＡ．ｊａｒから対象クラス、ここではクラスＡを読み込む（Ｓ５０１）。次に、クラスローダはｌｉｂＡ．ｊａｒのファイルパスを指定して、セキュリティマネージャ３０１に権限を問い合わせる（Ｓ５０２）。

すると、セキュリティマネージャ３０１は、ｌｉｂＡ．ｊａｒのファイルパスを指定して、クラスＡをロードしたクラスローダ（本例ではアプリケーションクラスローダ３０２）に権限を問い合わせる（Ｓ５０３）。

そして、クラスローダがｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドをオーバライドしているかを判定する（Ｓ５０４）。すなわち、標準のクラスローダから継承されたクラスローダにおいて、ｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドが標準のクラスローダから変更されているか判定する。ｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドは、当該クラスの権限を獲得するメソッドである。Ｊａｖａ標準のクラスローダはｇｅｔＰｅｒｍｉｓｓｉｏｎｓをオーバライドしない。Ｊａｖａ標準のクラスローダをそのまま継承するアプリケーションクラスローダもｇｅｔＰｅｒｍｉｓｓｉｏｎｓをオーバライドしない。しかし、Ｊａｖａ標準クラスファイルは容易に解読できるため、セキュリティを高めるために独自フォーマットのクラスファイルを使う拡張をしたいケースなどがある。そこで、自作のクラスローダをオーバライドして実装できるように、このようなフローがＪａｖａの仕様で定められている。

ステップＳ５０４において、クラスローダがｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドをオーバライドしていなければ、再度ｌｉｂＡ．ｊａｒを指定して、セキュリティマネージャ３０１にデフォルトの権限を問い合わせる（Ｓ５０５）。そして、セキュリティマネージャ３０１は図１２に示したセキュリティポリシーファイルに従って、そこに設定された権限すなわちｌｉｂＡ．ｊａｒのデフォルト権限を応答する（Ｓ５０６）。そして、クラスローダは取得した権限をクラスＡに設定する（Ｓ５０７）。

ステップＳ５０４において、ｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドをオーバライドしていれば、オーバライドしたｇｅｔＰｅｒｍｉｓｓｉｏｎｓの実装で取得した権限をクラスＡに設定する（Ｓ５０８）。

ここまで、公知である一般的なＯＳＧｉとＪａｖａの仕様について説明した。セキュリティマネージャ３０１にはファイル単位での権限設定が可能だが、１プロセスで開けるファイル数には上限があるため、複数のｊａｒファイルを１つのｊａｒファイルにまとめたうえで、個別に権限を設定したいという課題が生じる。

●ｊａｒファイルの集約
ここから、この課題を解決するための本発明の実施形態について説明する。まず、複数のｊａｒファイルを１つのｊａｒファイルにまとめる方法について、図７を用いて説明する。図７は、集約対象のｊａｒファイルを１つのｊａｒファイルにまとめる処理の流れを示すフローチャートである。集約されるｊａｒファイルは、１または複数のクラスを含むクラスのライブラリであり、ライブラリファイルと呼ぶこともある。またライブラリファイルを集約したファイルをアーカイブファイルまたは集約ファイルと呼ぶことがある。

デバイスのアプリケーションから共通して利用される機能をライブラリとしてまとめたものが、ｌｉｂＡ．ｊａｒやｌｉｂＢ．ｊａｒであるとする。これらはデバイス内のｌｉｂディレクトリに配置されるものとする。このとき、ｌｉｂディレクトリ内のｊａｒを１つにまとめれば、ＦＤの使用量を削減できる。

そこで、ｌｉｂディレクトリ内の各ｊａｒファイルをｌｉｂｓ．ｊａｒファイルとして集約或いは統合する処理を行う。この処理はデバイス内で行ってもよいし、デバイスにインストールするファームイメージの作成処理で行ってもよい。

集約処理では、まずｌｉｂパスにあるｊａｒファイルをリスト化する（Ｓ７０１）。次に、リストの最後のファイルまで処理したかを判定する（Ｓ７０２）。未処理のファイルがあるなら、そのうちからｊａｒファイルをひとつ選択する（Ｓ７０３）。そして、そのｊａｒファイル名のフォルダに、ｊａｒファイルが内包していたファイルを展開する（Ｓ７０４）。そして、後述するクラスマップ１５０１に、展開したファイルのファイル名とクラスリストを記載し、リソースマップ１５０２に、展開したファイルのファイル名とファイルリストを記載する（Ｓ７０５）。

ステップＳ７０２ですべて処理済みなら、展開済みのフォルダと、クラスマップ１５０１を記載したファイルと、リソースマップ１５０２を記載したファイルとを、１つのｊａｒファイルとして圧縮する（Ｓ７０６）。その結果得られるｊａｒファイルは図１５に例示したファイルそれぞれを含んでいる。

図１５に、集約したｌｉｂｓ．ｊａｒファイルの構成を示す。図１５（ａ）は、ｌｉｂｓ．ｊａｒファイルが含むファイルのリストである。このリストでは、集約されたライブラリのファイルやそれぞれのマニフェストファイル、それぞれのリソースファイルの所在と対応するライブラリとが特定されており、集約ファイルリストあるいはアーカイブファイルリストなどと呼ぶ。Ｊａｖａの正式なクラス名は、パッケージ名とクラス名から構成される。パッケージ名に開発元やライブラリの識別子を含めることで、Ｌｏｇ．ｃｌａｓｓなどのよくある名前のクラスも一意のクラス名として識別できる。このように正式なクラスは一意の名前になるため、ｃｏｍ／ｃｉｎｃ／ｌｉｂａ／Ａ．ｃｌａｓｓやｃｏｍ／ｃｓｏｆｔ／ｌｉｂｂ／Ｂ．ｃｌａｓｓをそのまま格納している。

一方、マニフェストファイルや画像ファイルは、各ｊａｒファイル間で同一名となって競合しうるため、ステップＳ７０４で作成したｊａｒファイル名のディレクトリｌｉｂＡやｌｉｂＢの下に格納している。クラスマップ１５０１はＣｌａｓｓｍａｐ．ｃｓｖファイル、リソースマップ１５０２はＲｅｓｏｕｒｃｅｍａｐ．ｃｓｖファイルとしてそれぞれ保持しているが、ファイル形式はｃｓｖ以外でもよい。

図１５（ｂ）と図１５（ｃ）が、ステップＳ７０５で作成したクラスマップ１５０１とリソースマップ１５０２の例である。クラスマップ１５０１には、クラスを含んでいたｊａｒファイル名をキーとして、クラスのリストを記載する。リソースマップ１５０２には、画像やマニフェストを含んでいたｊａｒファイル名をキーとして、各ファイルのリストを記載する。なお図１５の例では、図１５（ａ）に示したアーカイブファイルリストからリソースファイルの所在とリソースファイルを含むｊａｒファイルを特定できる。そのため図１５（ｃ）のリソースマップはなくともよい。逆にリソースマップを保持して、アーカイブファイルリストからリソースファイルに関する記述を省いてもよい。もちろん図１５のように両方含めてもよい。なお、アーカイブファイルリストにリソースファイルの所在とリソースファイルを含むｊａｒファイルを特定する記述を含む場合、その記述のこともリソースマップと呼んでよい。

以上、複数のｊａｒファイルを集約したｌｉｂｓ．ｊａｒの作成について説明した。このｌｉｂｓ．ｊａｒを読み込むには、集約ｌｉｂ用クラスローダが必要となる。集約ｌｉｂ用クラスローダの作成はＪａｖａＶＭが行ってもよいし、アプリケーションＦＷ２０４が行ってもよい。図４に、アプリケーションＦＷ２０４上に集約ｌｉｂ用クラスローダ４０１を作成したときの構成図を示す。

●集約ｌｉｂ用クラスローダ
次に、ｌｉｂｓ．ｊａｒを読み込むための集約ｌｉｂ用クラスローダの構成について、図１６を用いて説明する。集約ｌｉｂ用クラスローダ４０１は、クラスマップ１５０１を参照してクラスをロードするクラスロード部１６０１をもつ。また、担当するｌｉｂを管理する担当ｌｉｂ管理部１６０３を備える。また、セキュリティポリシーファイルの設定内容と、担当ｌｉｂ管理部１６０３の情報に基づいて権限を管理する権限管理部１６０２を備える。

次に、集約ｌｉｂ用クラスローダ４０１の動作について、図６を用いて説明する。図６はＪａｖａＶＭ２０３上で集約ｌｉｂ用クラスローダ４０１を作成し、集約ｌｉｂ用クラスローダ４０１がクラスをロードして権限を設定する処理の流れを示すフローチャートである。この説明例では、ｌｉｂｓ．ｊａｒからクラスＡをロードするとして説明する。

まず、ＪａｖａＶＭ２０３上で集約ｌｉｂ用クラスローダを作成する（Ｓ６０９）。作成はＪａｖａＶＭが行ってもよいし、アプリケーションＦＷ２０４が行ってもよい。集約ｌｉｂ用クラスローダは、集約前の個別のｊａｒファイルの数と同じだけ作るのが、もっとも単純である。次に、作成したクラスローダに担当ファイル名（あるいは担当ライブラリファイルの名称）を設定する（Ｓ６１０）。担当ファイル名の例は、ｌｉｂＡ．ｊａｒやｌｉｂＢ．ｊａｒである。この説明の例では、ｌｉｂＡ．ｊａｒを設定したものとする。設定された担当ファイル名は、所定の記憶場所に保持される。

次に、ｌｉｂｓ．ｊａｒのクラスマップ１５０１を参照して、ｌｉｂＡ．ｊａｒのクラスのリストを取得する（Ｓ６１１）。そして、ｌｉｂｓ．ｊａｒからクラスをロードする（Ｓ６１２）。ステップＳ６１２の詳細は後述する。そして、クラスのロード処理が例外を投げたがどうかを確認する（Ｓ６１３）。例外を投げたとは、たとえばロード処理の結果として、該当するクラスが見つからないなどの応答が返された場合などである。

例外を投げていなければ、Ｊａｖａ標準のクラスローダと同様にｌｉｂＡ．ｊａｒを指定して権限を問い合わせる（Ｓ６０２）。セキュリティマネージャ３０１は、クラスＡをロードしたクラスローダに権限を問い合わせる（Ｓ６０３）。集約ｌｉｂ用クラスローダはｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドをオーバライドしているので、ステップＳ６０４ではＹｅｓしかありえない。なおＳ６０４（Ｓ５０４も同様）では判定を行わず、ｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドを実行してもよい。その場合、オーバライドされていなければＳ５０５－Ｓ５０６が実行され、オーバライドされていればＳ６１４が実行される。そして、オーバライドしたｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドによって権限を取得する（Ｓ６１４）。ステップＳ６１４の処理の詳細は後述する。そして、その取得した権限をクラスＡに設定する（Ｓ６０８）。

●権限の設定
ステップＳ６１４の処理の詳細について、図９を用いて説明する。権限の取得のためのｇｅｔＰｅｒｍｉｓｓｉｏｎｓメソッドは、クラスファイルのパスであるＣｏｄｅＳｏｕｒｃｅを受け取る（Ｓ９０１）。しかし、本発明では同じＣｏｄｅＳｏｕｒｃｅについて異なる権限を取得するために、受け取ったＣｏｄｅＳｏｕｒｃｅは参照しない。代わりに、図１２に示したセキュリティポリシーファイルを参照して、ステップＳ６１０で設定した担当ファイル名に該当するファイルの権限を応答する（Ｓ９０２）。図１２の例では、例えば担当ファイル名がｌｉｂＡ．ｊａｒであれば、ＦｉｌｅＸ．ｔｘｔなるファイルについて読み出し権限があることを応答する。なお場合によっては、セキュリティポリシーファイルを参照せず、独自の権限設定をしてもよい。

●クラスのロード
次に、ステップＳ６１２の詳細について、図１０を用いて説明する。Ｊａｖａ仕様のクラスロード用メソッドには、クラス名だけを受け取るメソッドと、クラス名とｒｅｓｏｌｖｅフラグを受け取るメソッドがあるが、本発明の実施はどちらでも可能である。図１０では、後者のメソッドを例に説明する。なお、クラス名だけを受け取るメソッドの場合は、ｒｅｓｏｌｖｅフラグをｆａｌｓｅで、クラス名とｒｅｓｏｌｖｅフラグを受け取るメソッドを呼ぶだけである。

まず、クラスのロード指示で、クラス名とｒｅｓｏｌｖｅフラグを受け取る（Ｓ１００１）。すると、クラスローダは親のクラスローダが存在するかを確認する（Ｓ１００２）。親のクラスローダが存在するなら、親のクラスローダでクラスをロードする（Ｓ１００３）。そして、クラスをロードできたかを判定する（Ｓ１００４）。ロードできていれば、そのクラスを応答する（Ｓ１００５）。応答されるクラスとは、たとえばクラス名等のクラスの識別情報であってよい。

ステップＳ１００１、Ｓ１００２，Ｓ１００３，Ｓ１００４は一般的なクラスローダと同様の処理である。Ｊａｖａではシステム用のクラスローダを親としてアプリ用のクラスローダが作られるが、Ｊａｖａ標準のクラスはシステムのクラスローダでロードするため、このような動作となっている。

ステップＳ１００４でクラスをロードできなかった場合に、本実施形態の集約ｌｉｂ用クラスローダの特徴的な処理を始める。まず、クラスマップ１５０１を参照して、ステップＳ１００１で受け取ったクラス名が、担当ｌｉｂ管理部１６０３で担当と設定されたｊａｒファイルのものかを判定する（Ｓ１００６）。担当するクラスの判定では、担当ｌｉｂ管理部１６０３に設定された担当Ｊａｒファイルのクラスであれば、自身が担当するクラスと判定する（Ｓ１００７）。担当するクラスでなければ、例外を投げる（Ｓ１００８）。

担当するクラスであれば、ロードしようとするクラスがロード済みクラスにあるかを判定する（Ｓ１００９）。ロード済みクラスかどうかの判定は、Ｊａｖａ標準の関数で行える（Ｓ１０１０）。ロード済みクラスであれば、Ｒｅｓｏｌｖｅフラグがｔｒｕｅかを判定する（Ｓ５０４）。ｔｒｕｅであれば、Ｊａｖａ標準の関数であるｒｅｓｏｌｖｅＣｌａｓｓメソッドによって、ロードしたクラスのリンク関係の処理を実行する（Ｓ１０１２）。そして、ステップＳ１００５と同様にクラスを応答する（Ｓ１０１３）。

ステップＳ１０１０でロード済みクラスでなかったときは、担当と設定されているｊａｒファイルから担当するクラスを探索する（Ｓ１０１４）。そして、クラスが見つかったかを判定する（Ｓ１０１５）。クラスが見つかれば、ステップＳ１０１１以降の処理を行う。

ステップＳ１０１５でクラスが見つからなければ、ステップＳ１００８以降の処理を行う。ただし、ステップＳ１０１５でクラスが見つからない場合は、ステップＳ１００６で参照したクラスマップ１５０１が壊れているときか、ｌｉｂｓ．ｊａｒファイルが壊れているときのみであり、通常は発生しない。

以上、１つにまとめたｊａｒファイルの作成方法と、まとめたｊａｒファイルをロードする専用のクラスローダについて説明した。

以上説明した構成及び手順により、本実施形態によれば、複数のｊａｒファイルを１つに集約することで、システム資源、特にファイルディスクリプタを節約できる。これにより、ファイルディスクリプタの上限に起因する、アプリケーションから同時に開くことのできるファイル数を実質的に増加させることができる。併せて、ロードされるクラスの権限を、集約前のファイル単位で管理することができる。

＜実施形態２＞
実施形態１では、１つのｊａｒファイルにまとめたクラスをそれぞれ異なる権限で実行する方法について説明した。しかし、１つのｊａｒファイルにまとめて生じる課題には、権限管理のほかに、画像ファイルなどのリソースファイルの競合がある。Ｊａｖａの仕様で定義されているリソース取得用のメソッドには、ｆｉｎｄＲｅｓｏｕｒｃｅ、ｇｅｔＲｅｓｏｕｒｃｅ、ｇｅｔＲｅｓｏｕｒｃｅＡｓＳｔｒｅａｍがある。アプリケーション２０５はこれらのメソッドを用いることで、ｊａｒファイル内部のマニフェストファイルや画像ファイルなどのリソースファイルを取得する。

そこで、リソースファイルの競合を防ぎつつ、従来通りにリソースを取得できるクラスローダの作成方法について、実施形態２として説明する。

実施形態２にかかる集約ｌｉｂ用クラスローダ４０１の構成について、図１７を用いて説明する。クラスロード部１６０１、権限管理部１６０２、担当ｌｉｂ管理部１６０３は図１６の説明と同様である。加えて、リソースマップ１５０２を参照してリソースを管理するリソース管理部１７０１を備える。

次に実施形態２にかかるリソース取得の処理の流れについて、図８を用いて説明する。具体例として、ｌｉｂＡ．ｊａｒのＡ．ｃｌａｓｓ内で作成したプログラムが"ＭＥＴＡ－ＩＮＦ／ＭＡＮＩＦＥＳＴ．ＭＦ"を指定してｆｉｎｄＲｅｓｏｕｒｃｅメソッドを実行する場合での説明とする。

初めに、集約ｌｉｂ用クラスローダがｊａｒファイル内のリソースを指すファイルパスを受け取る（Ｓ８０１）。すると、リソース管理部１７０１は、受け取ったファイルパスを担当ｌｉｂ管理部１６０３に応じて書き換える（Ｓ８０２）。具体的には、"ｌｉｂＡ／ＭＥＴＡ－ＩＮＦ／ＭＡＮＩＦＥＳＴ．ＭＦ"と書き換える。そして、Ｊａｖａ標準のｆｉｎｄＲｅｓｏｕｒｃｅメソッドを実行して、ｌｉｂｓ．ｊａｒのｌｉｂＡディレクトリのマニフェストを応答する（Ｓ８０３）。リソースファイルは各ｊａｒファイル間で同一名となって競合しうるため、集約処理においてステップＳ７０４で作成したｊａｒファイル名のディレクトリ（例えばｌｉｂＡやｌｉｂＢ）の下に格納している。またファイルのリストでも、図１５（ａ）に示したように、そのディレクトリも含めてファイル名が特定されている。そのため、集約前のｊａｒファイルでは同一の名称が採用され得るリソースファイルであっても、集約されたｊａｒファイルでは固有に識別することができる。

以上、１つのｊａｒファイルにまとめるときに競合しうるリソースファイルを、まとめた後も同様に取得するための方法について説明した。

＜実施形態３＞
実施形態１では、１つのｊａｒファイルから異なる権限でプログラムを実行する方法について説明した。また、実施形態２では、複数のｊａｒファイルで競合するリソースがある場合でも適切なリソースを取得する方法について説明した。これらの実施形態は、まとめる前の集約対象である各ｊａｒファイルのクラスとリソースのロードを、それぞれ異なる集約ｌｉｂ用クラスローダが担当した。

しかし、同じ権限のｊａｒファイルが複数存在し、かつ、それらのｊａｒ間でリソースが競合しなければ、１つのクラスローダで複数のｊａｒを担当してよい。マニフェストについては、マニフェストの内容をそもそも参照しないライブラリであれば、１つのｊａｒファイルにする過程でマニフェストが失われても問題は生じない。

そこで、１つの集約ｌｉｂ用クラスローダが複数のｊａｒファイルを担当する例を、実施形態３として説明する。

ｌｉｂｓ．ｊａｒファイルとして、ｌｉｂディレクトリ内の各ｊａｒファイルを集約する処理は、図７と同様である。ただし、リソースが競合しないので、ステップＳ７０４と異なり、ｊａｒファイル名のフォルダを作る必要はない。リソースファイル名でリソースファイルを識別可能なためである。図１８に集約前後の各ｊａｒファイルの構成を示す。図１８（ａ）は集約前のｌｉｂＡ．ｊａｒ、図１８（ｂ）は集約前のｌｉｂＢ．ｊａｒを示す。図１８（ｃ）はｌｉｂＡ．ｊａｒとｌｉｂＢ．ｊａｒを集約したｌｉｂｓ．ｊａｒである。リソースが競合しないので、フラットに、すなわちリソースファイルのためのフォルダを設けることなくすべてのファイルを展開して再圧縮するのみでよい。マニフェストについては、ｌｉｂＡ．ｊａｒとｌｉｂＢ．ｊａｒが、集約しても競合しない独自の項目を定義しているときに、それらの項目をすべて集約後のｌｉｂｓ．ｊａｒのＭＡＮＩＦＥＳＴ．ＭＦに記載すればよい。

集約ｌｉｂ用クラスローダの動作は実施形態１と同様であるが、ステップＳ６１０では、同じ権限の複数のｊａｒファイルを担当ファイル名として設定する。また、リソース取得処理のステップＳ８０２では、ファイルパスの書き換えはしないでよい。

以上、同じ権限のライブラリが複数存在し、かつ、それらのライブラリ間でリソースが競合しない場合に、一つの集約ｌｉｂ用クラスローダで複数のｊａｒを担当する方法について説明した。

なお、集約前の複数のｊａｒファイルを１つのクラスローダが担当するための前述した条件は、それが満たされていることを前提として上述の構成を採用してもよい。或いは、条件が具備されている複数の集約対象のｊａｒファイルを集約して１つの集約ｊａｒファイルを生成してもよい。

後者の手順を、図７に基づいて説明する。まずＳ７０１では、ｊａｒファイルをリスト化するとともに、そのうちの１つのｊａｒファイルに着目し、それを基準ｊａｒファイルとする。また、基準ｊａｒファイルの権限について取得しておき、その名称のフォルダに転回しておく。

そしてＳ７０３では、基準ｊａｒファイルおよび処理済みのｊａｒファイルを除くｊａｒファイルのひとつを対象ｊａｒファイルとして選択し、対象ｊａｒファイルの権限を取得する。そして基準ｊａｒファイルと対象ｊａｒファイルそれぞれの権限と、リソースファイルと、マニフェストファイルとを比較し、権限が互いに同一であり、かつリソースファイルとマニフェストの内容とに重複がないか判定する。これらの条件が満たされたならば、対象ｊａｒファイルを集約の対象としてＳ７０４に進む。一方、条件が満たされないならば対象ｊａｒファイルは集約の対象外としてＳ７０２に戻る。Ｓ７０５はスキップしてよい。

ステップＳ７０６では集約したｊａｒファイルを生成するが、その際にはリソースファイルは特にフォルダにいれず、そのまま集約ｊａｒファイルに含めてよい。マニフェストファイルも一つにまとめてよい。さらに新たに作成した集約ｊａｒファイルのセキュリティポリシーをセキュリティマネージャ３０１に登録させる。

以上の手順により、一つのクラスローダ特にｊａｖａ標準のクラスローダによってクラスをロード可能な集約ｊａｒファイルを生成することができる。集約したｊａｒファイルについて、必ずしも元のｊａｒファイル名のフォルダの下に集約前のファイルを保持する必要がない。

これによりｊａｒファイルの数を減らすことができ、ＦＤを節約してより多くのアプリケーションを並列に実行することができる。

＜実施形態４＞
上記実施形態はｌｉｂｓ．ｊａｒと集約ｌｉｂ用クラスローダ４０１のみで実施できる。そのため、集約ｌｉｂ用クラスローダ４０１は、アプリケーションＦＷ２０４上で作成してもよいし、アプリケーションＦＷ２０４がない環境で作成してもよい。

しかし、ＦＤを多く消費するのは、アプリケーションＦＷ２０４上で多くのｊａｒを実行する場合のため、アプリケーションＦＷ２０４上で集約ｌｉｂ用クラスローダ４０１を用いる方が自然である。そこで、アプリケーションＦＷ２０４上で集約ｌｉｂ用クラスローダ４０１を用いる方法について、実施形態４として説明する。

図４は、集約ｌｉｂ用クラスローダを備えるアプリケーションＦＷ２０４の構成を示す図である。

実施形態４にかかるアプリケーションＦＷ２０４の起動処理について、図１１のフローチャートを用いて説明する。なおアプリケーションＦＷ２０４のことをアプリケーション実行の基盤となることからアプリケーションプラットフォームと呼ぶこともある。アプリケーションＦＷ２０４は起動されると、集約ｌｉｂ用クラスローダを生成する（Ｓ１１０１）。ステップＳ１１０１において、生成するクラスローダは集約する前のｊａｒの数と同数にするのが単純である。Ｊａｖａのクラスローダは生成時にＵＲＬの配列を受け取る仕様であるため、すべての集約ｌｉｂ用クラスローダのインスタンスは、ｌｉｂｓ．ｊａｒのＵＲＬを受け取ることになる。ただし、各インスタンスに設定する担当ファイル名は、ステップＳ６１０で説明した通り、異なるファイル名となる。

そして、アプリケーションＦＷ２０４は、デバイスにインストールされているアプリケーション２０５のリストを取得する（Ｓ１１０２）。もしすべてのアプリを開始済みであれば（Ｓ１１０３）、起動は終了する。もしそうでなければ、開始対象のアプリを１つ選択する（Ｓ１１０４）。そして、そのアプリを実行するためのアプリケーションクラスローダ３０２を生成する（Ｓ１１０５）。

そして、そのアプリケーションクラスローダ３０２が集約ｌｉｂ用クラスローダ４０１を参照するように設定する（Ｓ１１０６）。設定方法としては、アプリケーションクラスローダ３０２の親クラスとして設定してもよいし、単に参照だけを設定して必要なときにクラスロード処理を委譲できるようにするだけでもよい。

そして、アプリケーションクラスローダ３０２でアプリケーション２０５のクラスをロードして開始する（Ｓ１１０７）。

以上、アプリケーションＦＷ２０４上で集約ｌｉｂ用クラスローダ４０１を用いる方法について説明した。このような手順によりアプリケーションＦＷ２０４上で集約ｌｉｂ用クラスローダ４０１を用いることができる。それにより実施形態１乃至３の効果、すなわちＦＤの消費を抑制してより多くのアプリケーションを並列的に実行することが可能となる。
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１００ 情報処理装置、４０１ 集約ｌｉｂ用クラスローダ

Claims (12)

1. クラスを含む複数のライブラリファイルを集約したアーカイブファイルから、前記複数のライブラリファイルのいずれかに含まれたクラスをロードするクラスローダを有する情報処理装置であって、
   前記複数のライブラリファイルそれぞれに関連付けて前記複数のライブラリファイルそれぞれに含まれたクラスの権限を保持する第１の保持手段を有し、
   前記アーカイブファイルは、前記複数のライブラリファイルそれぞれに含まれた前記クラスを特定するクラスマップを含み、
   前記クラスローダは、
   設定された担当ライブラリファイルを特定する情報を保持する第２の保持手段と、
   前記クラスマップに基づいて、前記アーカイブファイルに含まれた前記担当ライブラリファイルから、指定されたクラスをロードするロード手段と、
   前記ロード手段によりロードしたクラスに対して、当該クラスを含む前記担当ライブラリファイルに関連付けて前記第１の保持手段により保持されている権限を設定する権限設定手段と、を有する
   ことを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記アーカイブファイルは、前記複数のライブラリファイルそれぞれに含まれたリソースファイルを特定するリソースマップを含み、
   前記クラスローダは、前記リソースマップに基づいて、前記ロード手段によりロードしたクラスに対して、当該クラスを含む前記担当ライブラリファイルに含まれたリソースファイルを取得するリソース取得手段を更に有する
   ことを特徴とする情報処理装置。
3. 請求項１または２に記載の情報処理装置であって、
   前記第２の保持手段は、担当ライブラリファイルとして、前記第１の保持手段により同一の権限が保持されているクラスを含むライブラリファイルを特定する情報を保持する
   ことを特徴とする情報処理装置。
4. 請求項１乃至３のいずれか一項に記載の情報処理装置であって、
   前記アーカイブファイルを読みこんで実行するアプリケーションプラットフォームをさらに有し、
   前記アプリケーションプラットフォームは、
   起動されると、アプリケーションごとに固有のクラスローダとして前記クラスローダを生成し、
   前記クラスローダでロードされた前記アプリケーションを、当該アプリケーションのクラスで実行する
   ことを特徴とする情報処理装置。
5. 請求項１乃至４のいずれか一項に記載のクラスローダとしてコンピュータを機能させるためのプログラム。
6. クラスを含む複数のライブラリファイルを集約したアーカイブファイルから、前記複数のライブラリファイルのいずれかに含まれたクラスをロードするクラスローダを有する情報処理装置によるクラスのロード方法であって、
   前記情報処理装置は、前記複数のライブラリファイルそれぞれに関連付けて前記複数のライブラリファイルそれぞれに含まれたクラスの権限を保持する第１の保持手段を有し、
   前記アーカイブファイルは、前記複数のライブラリファイルそれぞれに含まれた前記クラスを特定するクラスマップを含み、
   前記情報処理装置は、
   設定された担当ライブラリファイルを特定する情報を保持し、
   前記クラスマップに基づいて、前記アーカイブファイルに含まれた前記担当ライブラリファイルから、指定されたクラスをロードし、
   前記ロードしたクラスに対して、当該クラスを含む前記担当ライブラリファイルに関連付けて前記第１の保持手段により保持されている権限を設定する
   ことを特徴とするクラスのロード方法。
7. 複数のライブラリファイルを１つのアーカイブファイルに集約する情報処理装置であって、
   集約対象のライブラリファイルと該ライブラリファイルに含まれたクラスとを関連付けたクラスマップを生成する第１の生成手段と、
   前記集約対象のライブラリファイルと該ライブラリファイルに含まれたリソースファイルとを関連付けたリソースマップを生成する第２の生成手段と、
   集約対象のライブラリファイルに含まれたクラスの所在を示すリストと前記クラスマップと前記リソースマップとを含むアーカイブファイルを生成する第３の生成手段と、を有する
   ことを特徴とする情報処理装置。
8. 請求項７に記載の情報処理装置であって、
   前記集約対象のライブラリファイルに同一の権限が設定されている場合には、前記第１の生成手段は前記クラスマップを生成しない
   ことを特徴とする情報処理装置。
9. 請求項７または８に記載の情報処理装置であって、
   前記集約対象のライブラリファイルが異なる名称のリソースファイルを含む場合には、前記第２の生成手段は前記リソースマップを生成しない
   ことを特徴とする情報処理装置。
10. 請求項９に記載の情報処理装置であって、
    前記第３の生成手段は、前記アーカイブファイルを、標準のクラスローダで前記アーカイブファイルに含まれたクラスをロードできるアーカイブファイルとして生成する
    ことを特徴とする情報処理装置。
11. 請求項７乃至１０のいずれか一項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。
12. 第１の作成手段と第２の作成手段と第３の作成手段とを有する情報処理装置により複数のライブラリファイルを１つのアーカイブファイルに集約する方法であって、
    前記第１の作成手段が、集約対象のライブラリファイルと該ライブラリファイルに含まれたクラスとを関連付けたクラスマップを生成し、
    前記第２の作成手段が、前記集約対象のライブラリファイルと該ライブラリファイルに含まれたリソースファイルとを関連付けたリソースマップを生成し、
    前記第３の作成手段が、集約対象のライブラリファイルに含まれたクラスの所在を示すリストと前記クラスマップと前記リソースマップとを含むアーカイブファイルを生成する
    ことを特徴とする方法。

Images