(57)【要約】      （修正有）【課題】ソフトウェアのアップデートや機能拡張により、ライブラリの増加が重なっても、ファイルディスクリプタの消費を抑制する情報処理装置及びリソース管理方法を提供する。【解決手段】装置の起動処理の一部として、またはアプリがインストールされた場合に、クラスパスの設定にライブラリが複数あるか否かを判定し、ライブラリが複数設定されていると判定された場合に、設定されているライブラリを展開して、新たなライブラリとして統合した後に、新しく作成したライブラリを、クラスパスとして設定する。【選択図】図１４Ｂ
2017126293.tif 000002
【特許請求の範囲】
【請求項１】
開いたライブラリの数に応じた量のリソースを消費する情報処理装置であって、
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定手段と、
ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数のライブラリに統合する統合手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
前記統合手段は、前記判定手段でライブラリの数が複数であると判定された場合に、前記ライブラリを解凍し、前記ライブラリの数より少ない数のライブラリに圧縮して統合することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記統合手段は、前記情報処理装置が起動された際に、前記ライブラリを統合することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記統合手段は、前記プログラムとしてアプリケーションがインストールされた際に、前記ライブラリを統合することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項５】
前記プログラムを実行する際に、該プログラムで用いられるクラスを含むライブラリを開いて当該クラスをロードするロード手段を更に有することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
【請求項６】
前記判定手段は、前記インストールされたプログラムの設定ファイルに記述された、クラスの所在を示すクラスパスを参照して、前記プログラムについて設定されたクラスを含むライブラリを特定することを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
【請求項７】
前記統合手段は、前記ライブラリに含まれたクラスを１つのライブラリに統合することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
【請求項８】
前記統合手段は、前記ライブラリに含まれたクラスを、前記クラスパスごとに１つのライブラリに統合することを特徴とする請求項６に記載の情報処理装置。
【請求項９】
前記プログラムは、システムプログラムとアプリケーションとを含み、前記システムプログラムについては、前記設定ファイルにブートクラスパスとシステムクラスパスとが記述され、前記アプリケーションについては、前記設定ファイルにアプリケーションクラスパスが記述され、
前記統合手段は、前記ライブラリに含まれたクラスを、前記クラスパスごとに１つのライブラリに統合することを特徴とする請求項８に記載の情報処理装置。
【請求項１０】
前記統合手段は、統合されるクラスを含むライブラリを生成することで、前記ライブラリを統合することを特徴とする請求項１乃至９のいずれか一項に記載の情報処理装置。
【請求項１１】
前記統合手段は、ライブラリの統合の前後の、統合前のライブラリにおける相対的なクラスの構成を、統合後のライブラリにおいても維持するよう前記ライブラリを統合することを特徴とする請求項１乃至１０のいずれか一項に記載の情報処理装置。
【請求項１２】
前記リソースにはファイルディスクリプタが含まれることを特徴とする請求項１乃至１１のいずれか一項に記載の情報処理装置。
【請求項１３】
開いたライブラリの数に応じた量のリソースを消費する情報処理装置によるリソース管理方法であって、
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定工程と、
ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数のライブラリに統合する統合工程と
を有することを特徴とする情報処理装置によるリソース管理方法。
【請求項１４】
前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
前記統合工程は、前記判定工程でライブラリの数が複数であると判定された場合に、前記ライブラリを解凍し、前記ライブラリの数より少ない数のライブラリに圧縮して統合することを特徴とする請求項１３に記載のリソース管理方法。
【請求項１５】
開いたライブラリの数に応じた量のリソースを消費するコンピューターを、
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定手段と、
ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数のライブラリに統合する統合手段と
して機能させるためのプログラム。
【請求項１６】
前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
前記統合手段は、前記判定工程でライブラリの数が複数であると判定された場合に、前記ライブラリを解凍し、前記ライブラリの数より少ない数のライブラリに圧縮して統合することを特徴とする請求項１５に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスパスに設定されているライブラリを管理する情報処理装置及びリソース管理方法に関わる。
【背景技術】
【０００２】
Ｊａｖａ（登録商標）の実行環境において、クラス（実行に必要なコード）のロードはクラスローダによって行われる。クラスは、ＪＡＲ（Ｊａｖａ Ａｒｃｈｉｖｅ）形式のライブラリの中にあるクラスファイルで定義されている。ライブラリは複数のクラスのクラスファイルから構成されており、特定の機能毎に分けられていることが多い。なお、ライブラリが存在する場所を示すパスはクラスパスとして、あらかじめＪａｖａ（登録商標）の実行環境に設定しておく必要がある。これはクラスのロード時に、クラスローダが、クラスパスに設定されているライブラリから、ロードするクラスを探索するためである。ここで、クラスローダは、ライブラリを参照してクラスを探索するため、ファイルディスクリプタを消費することになる。Ｊａｖａ（登録商標）の実行環境では、パフォーマンスを向上させるため、あるいはライブラリへの参照が切れて動作が不安定になることを防ぐために、一度参照したライブラリは、実行環境上で動作するプログラムが終了するまで参照される。そのため、クラスローダがライブラリを参照するために消費したファイルディスクリプタはプログラムが終了するまで消費され続けることになる。
【０００３】
組込機器において、アプリケーションの実行環境である情報処理装置には、使用可能なリソースに制限がある。ファイルディスクリプタもリソースの一種であり、使用可能なファイルディスクリプタ数に制限がある。そのため、以下のようなことが行われている。まず、開発者はアプリケーションが使用するリソース量について上限値を定める。そして、ユーザ管理者がアプリケーションを開始する際に、その上限値に基づいて、アプリケーション管理フレームワークは情報処理装置の使用可能なリソース量を超えないことを確認する。
【０００４】
従来技術として、全く使用されることのないクラスを検知して、クラスパスから使用されることのないクラスがあるライブラリを削除する技術がある（例えば特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−２９３０８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１は、クラスパスから使用されるクラスがあるライブラリに対しては、そのまま残している。つまり、クラスパスから使用されるクラスがあるライブラリの数が多いと、ファイルディスクリプタを多く消費する。そのため、ファイルディスクリプタの使用可能な数を超えてしまうと、結果として、起動処理に影響を及ぼす。特に、ソフトウェアのアップデートや機能拡張により、ライブラリの増加が重なっていくと、ファイルディスクリプタの消費数が増えることになる。
【０００７】
そこで本願発明の目的は、使用するライブラリが増加したとしても、ファイルディスクリプタの消費を抑制することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明は、開いたライブラリの数に応じた量のリソースを消費する情報処理装置であって、インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定手段と、ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数のライブラリに統合する統合手段とを有することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ライブラリ増加に伴うファイルディスクリプタの増加を抑制することができる。
【図面の簡単な説明】
【００１０】
【図１】画像形成装置の構成図
【図２】画像形成装置のハードウェア構成図
【図３】第一の実施例における画像形成装置におけるアプリケーション実行環境の構成図
【図４】第一の実施例における起動オプション設定ファイルの構成図
【図５】第一の実施例におけるアプリ設定ファイルの構成図
【図６】画像形成装置１００内にあるライブラリ配置を示す図
【図７】第一の実施例におけるライブラリ内にあるクラスファイルの配置を示す図
【図８Ａ】、
【図８Ｂ】、
【図８Ｃ】第一の実施例における画像形成装置の処理の流れを示すフローチャート
【図９】第二の実施例における画像形成装置におけるアプリケーション実行環境の構成図
【図１０】第二の実施例における起動オプション設定ファイルの構成図
【図１１】第二の実施例におけるアプリ設定ファイルの構成図
【図１２】第二の実施例における統合ライブラリ内にあるクラスファイルの配置を示す図
【図１３Ａ】、
【図１３Ｂ】第二の実施例における画像形成装置の処理の流れを示すフローチャート
【図１４Ａ】、
【図１４Ｂ】第三の実施例における画像形成装置の処理の流れを示すフローチャート
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための形態について図面を用いて説明する。
［第一の実施例］
図１に掲げるのは本発明の第一の実施例のシステム全体の構成を示す図である。
画像形成装置１００は本実施例を実装した情報処理装置の一例であり、例えば多機能周辺装置（ＭＦＰ）である。情報処理装置１０１は画像形成装置１００を管理する。ネットワーク１２０は画像形成装置１００と情報処理装置１０１を接続する。情報処理装置１０１は画像形成装置１００をネットワーク１２０経由で利用するために用いられる。アプリケーションＡ１１０は画像形成装置１００上で動作するアプリケーションの一つの例である。アプリケーションＢ１１１は同様に画像形成装置１００上で動作するアプリケーションのもう一つの例である。さらにアプリケーションＣ１１２は同様に画像形成装置１００上で動作するアプリケーションのさらなる一つの例である。画像形成装置１００上では一つ、あるいは複数のアプリケーションを動作させることが可能である。ここではアプリケーションを三つ例示している。以後、「アプリケーション１１ｎ」という表現は、アプリケーションＡ１１０、アプリケーションＢ１１１、アプリケーションＣ１１２にて代表されるような一つまたは複数のアプリケーションを指す。一般利用者および管理者は画像形成装置１００の基本機能、アプリケーション１１ｎ、および、画像形成装置１００やアプリケーション１１ｎを管理するためのリソース管理装置を利用することが可能である。利用に当たっては、画像形成装置１００を直接操作、もしくはネットワーク１２０経由で情報処理装置１０１から操作することが可能である。
【００１２】
＜画像形成装置のハードウェア構成＞
図２は画像形成装置１００のハードウェア構成を図式化したものである。
コア部２００はプロセッサやメモリなどを含む制御部であり、コア部２００に接続された種々のデバイスを、プロセッサとメモリとが共働してプログラムを実行することで制御する。また、アプリケーションの実行環境を実現し、インストールされたアプリケーションを実行する。コア部２００には、ユーザインターフェース部２０１、記憶装置２０２、ネットワーク１２０に接続するためのネットワークインターフェース部２０３、スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６などが周辺デバイスとして接続されている。コア部２００はこれらデバイスを制御し、その機能をユーザーインターフェイス２０１あるいはネットワーク１２０を介してユーザに提供するとともに、アプリケーションに対しても提供している。
【００１３】
＜アプリケーション実行環境＞
図３は本実施例における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境である。
起動モジュール３００は、アプリケーション実行環境を立ち上げるためのモジュールである。ユーザが画像形成装置１００の電源を入れると、システムが動き出し、起動モジュール３００が、本実施例のための処理である統合ライブラリの作成処理をＬｉｂ管理モジュール３０４に命令する。Ｌｉｂ管理モジュール３０４は、本実施例を実施するためのモジュールであり、クラスパスに設定されているライブラリを一つの統合ライブラリとして作成し直すモジュールである。統合ライブラリの作成処理が終わった後に、起動モジュール３００はアプリケーション実行基盤３０１を起動する。アプリケーション実行基盤３０１はＪａｖａ（登録商標）の実行環境であり、例えばＪａｖａ（登録商標）ＶＭ（仮想マシン）である。クラスローダ３０２は、クラスをロードするためのモジュールである。アプリケーションやシステムプログラムが実行され、その中でクラスが使用されると、そのクラスは、クラスパスで特定されるそのクラスを含むライブラリからクラスローダ３０２によって動的にロードされる。
【００１４】
ロードされていないクラスの実行処理を命令された場合、クラスローダ３０２は、クラスパスに設定されているライブラリから、実行処理を命令されているクラスを探索する。クラスはアプリケーション実行基盤３０１が命令を実行するための実行コードになっており、クラスパスはクラスが含まれたライブラリの所在場所を示すパスの情報である。クラスパスにはシステムに必要なクラスが含まれた第一のクラスパスと、各アプリケーション１１ｎ用のクラスが含まれた第二のクラスパスがある。システムとは狭義にはオペレーティングシステムであるが、本例では、オペレーティングシステムを含む、アプリケーション以外のソフトウェアモジュールを指すこともある。第一のクラスパスは、システムのクラスをロードするために必要なパスであり、ブートクラスパス、システムクラスパスをそれぞれ含む、あるいは少なくともどちらか一方を含むクラスパスのことである。ブートクラスパスはＪａｖａ（登録商標）の実行環境を起動するために必要なクラスを含むライブラリの所在場所を示すパスである。システムクラスパスはアプリケーション実行基盤３０１、及びアプリ管理フレームワーク３０３を起動するために必要なクラスを含むライブラリの所在場所を示すパスである。第二のクラスパスは、アプリケーションのクラスを含むライブラリの所在場所を示すアプリクラスパス（あるいはアプリケーションクラスパス）である。第一のクラスパスは、起動モジュール３００がアプリケーション実行基盤３０１を起動するときに、起動オプションとしてアプリケーション実行基盤３０１に渡される。アプリケーション実行基盤３０１がその渡された第一のクラスパスを登録する。第二のクラスパスは、アプリ管理フレームワーク３０３がアプリケーション内に含まれるアプリ設定ファイル（例えば図５に示すアプリ設定ファイル５０２）から読み込むクラスパス（図５に示すアプリケーションクラスパス５１４）であり、アプリ管理フレームワーク３０３は読み込んだクラスパスを開始するアプリケーションのためだけの第二のクラスパスとして設定する。そのため、第二のクラスパスといっても、異なるアプリケーション１１ｎそれぞれに対する第二のクラスパスはそれぞれ全く異なったクラスパスとなる。本例ではアプリ設定ファイルとは例えばＪａｖａ（登録商標）のマニフェストファイルである。
【００１５】
クラスローダ３０２がクラスパスに設定されたライブラリからクラスを探索して、ライブラリの中に探索対象のクラスが見つかった場合、クラスローダ３０２はライブラリからクラスをロードする。そして、アプリケーション実行基盤３０１がロードしたクラスを実行する。対象のクラスが見つからなかった場合は、クラスが見つからなかったことをコンソール画面やブラウザの画面などのユーザインターフェース部２０１を通じてユーザに警告する。画像形成装置１００のシステムが動き始めてから、ユーザによって画像形成装置１００の電源が切られるまでにロードしていないクラスが実行されると、このようなクラスローダ３０２によるクラスのロード処理が行われる。また、クラスには、同名のクラスが衝突しないように名前空間が開発者によってあらかじめ与えられている。ライブラリは、１つ以上のクラスをＪＡＲ（Ｊａｖａ  Ａｒｃｈｉｖｅ）ファイルとして圧縮したファイルになっている。ライブラリの中でもクラスが衝突するのを防ぐために、ＪＡＲファイルには名前空間に対応したディレクトリ階層が構成され、その中にクラスのファイルが配置されていることが一般的である。本実施例でも、ライブラリ内が名前空間のディレクトリ階層で構成されている例を使って説明する。
【００１６】
アプリ管理フレームワーク３０３はアプリケーション１１ｎのインストールおよびアンインストール、実行と停止を管理するフレームワークであり、たとえばＯＳＧｉなどである。アプリケーション実行環境内へアプリケーション１１ｎをインストールして実行するには、アプリ管理フレームワーク３０３を利用する。管理者がアプリケーション１１ｎをインストールして開始するリクエストをアプリ管理フレームワーク３０３に行うことにより、アプリ管理フレームワーク３０３はアプリインストール処理やアプリ開始処理を行う。その際にアプリ管理フレームワーク３０３はそのアプリケーションのアプリ設定ファイル（例えば図５に示すアプリ設定ファイル５０２）を参照して、そこに宣言されているリソース上限値（例えば図５のリソース上限値５１３）が現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。そして、もしも納まらなければアプリケーションの開始を失敗させる。
以降は本実施例を実施するための特別な構成要素の説明である。
【００１７】
Ｌｉｂ管理モジュール３０４は、統合ライブラリ３０５を作成するためのモジュールである。Ｌｉｂ管理モジュール３０４は起動モジュール３００から統合ライブラリ作成処理を命令される。Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル（例えば図４の起動オプション設定ファイル４００）の第一のクラスパス（例えば図４のクラスパス４０２）に設定されているライブラリ、およびアプリ設定ファイル（例えば図５のアプリ設定ファイル５０２）の第二のクラスパス（例えば図５のクラスパス５１４）に設定されているライブラリを全て解凍する。そして、解凍して展開されたクラスを新しい統合ライブラリ３０５としてJARファイル形式で圧縮し直す。Ｌｉｂ管理モジュール３０４は、統合ライブラリを作成した後、起動オプション設定ファイル（例えば図４の起動オプション設定ファイル４００）にある第一のクラスパス（例えば図４のクラスパス４０２）の設定を、新しく作成した統合ライブラリ３０５のみになるように変更する。また、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル（例えば図５のアプリ設定ファイル５０２）の第二のクラスパス（例えば図５のクラスパス５１４）に設定されたライブラリの記載を削除する。第一のクラスパス、あるいは第二のクラスパスとして設定されていた複数ライブラリ内のクラス群をまとめた統合ライブラリ３０５のみを第一のクラスパスに設定し、クラスローダ３０２は統合ライブラリを見るだけで必要なクラスを探索することができる。統合ライブラリ３０５は、Ｌｉｂ管理モジュール３０４によって作成されるライブラリである。統合ライブラリ３０５は、前述の通り、第一のクラスパス、あるいは第二のクラスパスに設定されていた複数ライブラリのクラス群をJARファイル形式で圧縮したライブラリである。統合ライブラリ３０５に含まれるクラスは、一度クラスローダによってロードされると、アプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、アプリケーション１１ｎから実行することができるようになる。
【００１８】
＜起動オプション設定ファイルの例＞
図４は本実施例における起動オプション設定を記載する代表的なファイルの内容について解説した図である。
図４（ａ）は、本実施例におけるＬｉｂ管理モジュール３０４によって変更される前の起動オプション設定ファイル４００を示す図である。起動オプション設定ファイル４００は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更する前の起動オプション設定ファイルである。パス４０１は、アプリケーション実行基盤３０１を起動するための実行ファイルがある所在場所を示す所在情報である。パス４０２は、ライブラリの所在場所を示す所在情報であり、第一のクラスパスに相当する。ライブラリ４０３は、第一のクラスパスとして設定されている各ライブラリの所在情報である。第一のクラスパス４０２に設定されたライブラリ４０３には、アプリケーション実行基盤３０１や、アプリ管理フレームワーク３０３が、処理を実行するのに必要なクラス群を含んでいる。メインプログラム４０４は、アプリケーション実行基盤３０１がアプリ管理フレームワーク３０３を起動するために必要なメインプログラムの所在情報である。
図４（ｂ）は本実施例におけるＬｉｂ管理モジュールによって変更された後の起動オプション設定ファイル４１０を示す図である。起動オプション設定ファイル４１０は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更した後の起動オプション設定ファイルである。起動オプション設定ファイル４１０は、例えば起動オプション設定ファイル４００を変更して得られる。起動モジュール３００は起動オプション設定ファイル４１０の内容を読み込み、読み込んだ内容をアプリケーション実行基盤３０１の起動オプションとして使用する。統合ライブラリ４１１は、第一のクラスパスとして設定されている統合ライブラリ３０５の所在情報である。Ｌｉｂ管理モジュール３０４は統合ライブラリを作成した後、起動オプション設定ファイル４００のクラスパス設定に統合ライブラリのパスを追加し、統合ライブラリ以外のライブラリのパスを第一のクラスパス４０２から削除する。
【００１９】
＜アプリケーションファイルの例＞
図５（ａ）は本実施例におけるアプリケーション１１ｎを構成する代表的なファイルの内容について解説した図である。アプリケーション１１ｎはいくつかの種類のファイルを抱えている。アプリケーション実行コードファイル５００はアプリケーションの実行コード等を含むファイルである。アプリ内包ライブラリ５０１はアプリケーションの処理を実行するのに必要なライブラリである。アプリケーション１１ｎの処理の実行において、第一のクラスパス４０２に設定されているライブラリ４０３では、特定のクラスが足りず、機能を実現できない場合、開発者はアプリ用のライブラリをアプリ内包ライブラリ５０１として用意する。アプリ設定ファイル５０２は、アプリケーションID等の基本情報や、アプリケーションが使用するリソースの上限値、第二のクラスパスが記載されているファイルである。アプリ設定ファイル５０２は開発者があらかじめ記載しており、アプリ実行コードファイル５００、アプリ内包ライブラリ５０１と一緒にアプリケーション１１ｎに含めている。
【００２０】
図５（ｂ）は、Ｌｉｂ管理モジュール３０４によって、第二のクラスパス５１４に設定されたライブラリの記載を削除される前に、アプリ設定ファイル５０２に記載されている項目の例を示す図である。アプリ名５１１は、アプリケーション１１ｎの名称である。アプリ名５１１は画像形成装置１００のユーザインターフェース部２０１等で表示される。アプリケーションＩＤ５１２は、アプリ管理フレームワーク３０３が各アプリケーション１１ｎを一意に識別するために付けられている識別情報である。リソース上限値５１３は、アプリケーション１１ｎが使用するリソースの上限値である。リソース上限値５１３はリソースごとに定義される。開発者はあらかじめアプリケーション１１ｎが使用しうるリソースの上限値を計測しておき、アプリ設定ファイル５０２にリソース上限値５１３として宣言する。アプリ管理フレームワーク３０３はアプリケーション１１ｎをインストールして開始する際に、このリソース上限値５１３を参照する。そして、現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定し、納まればアプリを開始して、もしも納まらなければアプリケーション１１ｎの開始を失敗させる。第二のクラスパス５１４は、アプリケーション１１ｎの処理を実行する時に必要なアプリ実行コードファイル５００やアプリ内包ライブラリ５０１の所在場所を示す情報である。パス５１５は第二のクラスパスに設定されているアプリ実行コードファイル５００やアプリ内包ライブラリ５０１の所在場所の情報である。図５ｂでは簡単にするために、アプリ実行コードファイル５００のパスを相対パスで設定しているが、絶対パスで記載されていても良い。また、一般的には、アプリ内包ライブラリ５０１は第一のクラスパス４０２に設定されていないライブラリなので、第二のクラスパス５１４として所在場所を示す必要がある。
【００２１】
図５（ｃ）は、Ｌｉｂ管理モジュール３０４によって、第二のクラスパス５１４に設定されたライブラリの記載を削除された後の、アプリ設定ファイル５０２に記載されている項目の例を示す図である。起動モジュール３００が統合ライブラリ３０５の作成処理をＬｉｂ管理モジュール３０４に命令すると、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４を参照する。そして、そこに設定されているアプリ内包ライブラリ５０１を解凍し、第一のクラスパス４０２に設定されたライブラリ内のクラス、およびアプリ内包ライブラリ５０１内のクラスを、統合ライブラリ３０５としてＪＡＲファイル形式で圧縮し直す。その後、Ｌｉｂ管理モジュール３０４は第一のクラスパス４０２を、新しく作成した統合ライブラリ３０５のみに変更する。変更により第一のクラスパス４１１が得られる。そして、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４に設定されたライブラリの記載を削除する。アプリ設定ファイル５２０は、第二のクラスパス５１４に設定されたライブラリの記載を削除された後のアプリ設定ファイルである。ライブラリの記載を削除された後の第二のクラスパス５２１には、アプリ実行コードファイル５００のパスのみ設定されている。パス５２２は第二のクラスパスに設定されているアプリ実行コードファイル５００の所在情報である。パス５１５で設定されていたライブラリは、Ｌｉｂ管理モジュール３０４が統合ライブラリ３０５として起動オプション設定ファイルの第一のクラスパス４１１に設定するため、Ｌｉｂ管理モジュール３０４はアプリ設定ファイルからライブラリの設定を削除する。なお、本実施例では、起動オプション設定ファイルとアプリ設定ファイルとをまとめて設定ファイルと呼ぶことがある。
【００２２】
＜ライブラリ配置の一例＞
図６は、画像形成装置１００内にあるライブラリ配置の一例をツリー状で示した構成図である。フォルダ６０１は、第一のクラスパス４０２に設定されているライブラリを配置するためのフォルダである。図６では、ライブラリ６０１が画像形成装置１００の内部、すなわちＤｅｖｉｃｅ．ｓｙｓｔｅｍの下に残っており、起動オプション設定ファイル４００に記述された第一のクラスパスで示された通りのフォルダ構成が残され、維持されている。しかし、ストレージの使用リソースを軽減させるために、第一のクラスパス４０２の設定からライブラリ４０３を削除した後に、Ｌｉｂ管理モジュール３０４がライブラリ６０１を削除しても良い。統合ライブラリ６０２は、Ｌｉｂ管理モジュール３０４が作成したライブラリである。Ｌｉｂ管理モジュール３０４は統合ライブラリ６０２を作成した後、このライブラリ６０２のパスを第一のクラスパス４１１に設定する。フォルダ６０３は、画像形成装置１１ｎにインストールされたアプリケーション１１ｎを配置するためのフォルダである。アプリ管理フレームワーク３０３は、アプリケーション１１ｎをインストールする際に、アプリ内包ライブラリ５０１をアプリケーション１１ｎから取り出し、アプリ格納用フォルダ６０３に配置する。本実施例では、簡単にするため、図６ではアプリケーションごとにライブラリをまとめて配置した例としているが、起動オプションである第一のクラスパス４０２、４１１や、第二のクラスパス５１４と整合性が取れていれば、任意の場所に配置しても良い。図６では、たとえばＰｒｅｖｉｅｗＡｐｐという名称のアプリケーションのアプリ内包ライブラリ５０１であるｌｉｂｐａ１．ｊａｒ等が、ＰｒｅｖｉｅｗＡｐｐというフォルダの下に配置されている。
【００２３】
＜クラスファイルの配置の一例＞
図７は本実施例のライブラリ内にあるクラスファイルの配置の一例をツリー状で示した構成図である。
図７（ａ）は、Ｌｉｂ管理モジュール３０４が、クラスファイルを集めて圧縮するために解凍するライブラリ内を示した図である。ライブラリ７０１〜７０４は第一のクラスパス４０２に設定されているライブラリであり、その内に含まれたクラスファイルとその配置が示されている。ライブラリ７０５〜７０６は第二のクラスパス５１４に設定されているライブラリであり、その内に含まれたクラスファイルとその配置を示す。
図７（ｂ）は、Ｌｉｂ管理モジュール３０４がライブラリを解凍した後、全てのクラスファイルを圧縮して作成した統合ライブラリ３０５の内部構成を示した図である。ライブラリ７１０は、第一のクラスパス４１１に設定されている統合ライブラリであり、その内に含まれたクラスファイルとその配置を示す。図７（ａ）に記載されているクラスファイルは、統合ライブラリ内に全て配置されているため、クラスローダ３０１はこの統合ライブラリからクラスを探索するだけで、処理の実行に必要なクラスを見つけることが出来る。また図７の例では、ライブラリ内の相対的なパスは統合の前後で変わらない。
【００２４】
＜画像形成装置によるアプリケーション関連処理＞
図８Ａは、ユーザに画像形成装置１００の電源を入れられてから、電源を切られるまでの処理の流れを模式的に表した本実施例におけるフローチャートである。図８Ａの手順は、コア部２００、特にコア部２００に含まれたプロセッサにより実行される。この手順は例えばオペレーティングシステムによる開始され、各ソフトウェアモジュールが各ステップで動作する。以下の説明ではソフトウェアが主体であるかのように記述することもあるが、ソフトウェアは仮想的な処理主体であって、実体はソフトウェアを実行するプロセッサ或いはプロセッサコアである。
ユーザが画像形成装置１００の電源を入れるとオペレーティングシステムが動き出し、まず起動モジュール３００を起動して、Ｓ８１０１で、起動モジュール３００がＬｉｂ管理モジュール３０４に、統合ライブラリの作成処理を命令する。Ｌｉｂ管理モジュール３０４による統合ライブラリの作成処理については図８Ｂを参照して説明する。Ｌｉｂ管理モジュール３０４が統合ライブラリ作成処理を完了すると、Ｓ８１０２で、起動モジュール３００は、起動オプション設定ファイル４１０の内容を起動オプションとしてアプリケーション実行基盤３０１を起動する。アプリケーション実行基盤３０１が起動すると、メインプログラム４０４の処理が実行されて処理が進んでいく。アプリケーション実行基盤３０１の一部であるクラスローダ３０２は、クラスのロードを監視する。Ｓ８１０５で、クラスローダ３０２は、クラスがロードされたか否かを判定する。Ｓ８１０５で、クラスローダ３０２が、メインプログラムの実行中にアプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、あるいはアプリケーション１１ｎがクラスの生成処理を実行したと判定すると、Ｓ８１０３に処理が進み、実行しなかった場合はＳ８１０４に処理が進む。Ｓ８１０３で、クラスローダ３０２はクラスロード処理を行う。クラスロード処理が終了すると、Ｓ８１０６で、アプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、あるいはアプリケーション１１ｎがクラスを生成し、Ｓ８１０４に処理が進む。Ｓ８１０４で、アプリケーション実行基盤３０１は、メインプログラムの起動後に、ユーザによって画像形成装置１００の電源が切られたか否かを、例えばオペレーティングシステムからの通知などに基づいて判定する。電源が切られたと判定した場合は、アプリケーション実行基盤３０１が画像形成装置１００の電源を切るための処理を行って、画像形成装置１００のシステムは終了する。電源が切られていない場合は、アプリケーション実行基盤３０１はメインプログラムを続けて実行する。
【００２５】
このように、アプリケーション実行基盤３０１は、いったん起動されるとステップＳ８１０５〜Ｓ８１０４のループでクラスの生成と電源断とを監視する。そしてクラスが生成されるとクラスをロードし、電源がオフにされると電源オフ処理を行う。
【００２６】
＜統合ライブラリの作成処理＞
図８Ｂは、Ｓ８１０１の詳細フローチャートで、起動モジュール３００に統合ライブラリの作成処理を命令された際のＬｉｂ管理モジュール３０４の、本実施例における処理の流れを模式的に表したフローチャートである。
Ｓ８２０１で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２、および第二のクラスパス５１４に設定されているライブラリの合計数が複数であるか否かを判定する。これらのクラスパスは、第一のクラスパスについては起動オプション設定ファイル４００、第二のクラスパスについてはアプリ設定ファイル５０２を参照することでその内容を取得できる。設定されているライブラリが１つであった場合は、Ｌｉｂ管理モジュール３０４は統合ライブラリの作成処理を行わず、処理が終了する。設定されているライブラリが複数ある場合は、Ｓ８２０２に処理を進める。Ｓ８２０２で、Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル４００を読み込んで、第一のクラスパス４０２に複数のライブラリが設定されているか否かを判定する。第一のクラスパス４０２にライブラリが複数設定されている場合はＳ８２０３に処理を進め、複数設定されていない場合はＳ８２０４に処理を進める。Ｓ８２０３で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２に設定されているライブラリ４０３を全て解凍する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの解凍を行う。例えば、図４（ａ）の記載内容の場合、Ｌｉｂ管理モジュール３０４は、Ｌｉｂｓｙｓｔｅｍ００３．ｊａｒ、Ｌｉｂｓｙｓｔｅｍ００２．ｊａｒ、Ｌｉｂｓｙｓｔｅｍ００１．ｊａｒの順にライブラリを解凍する。このように、後に記載されたライブラリから解凍することで、同じ名前空間で同じクラス名が万が一存在して衝突した場合に、先に解凍されたクラスファイルを、後から解凍されたクラスファイルで上書きすることができる。一般的に、同じ名前空間、同じクラス名のものが衝突した場合、クラスパスが先に設定されているクラスファイルをロードする。したがって、クラスの衝突が起きた場合、記載が先にあるライブラリのクラスファイル、すなわち後から解凍されるクラスファイルで上書きすることで、本来、一般的な環境でロードされるはずのクラスの方を残すことができる。Ｓ８２０４で、Ｌｉｂ管理モジュール３０４は画像形成装置１００にインストールされているアプリケーション１１ｎがあるか否かを判定する。インストールされているアプリがない場合はＳ８２０６に処理を進め、インストールされているアプリがある場合はＳ８２０５に処理を進める。Ｓ８２０５で、Ｌｉｂ管理モジュール３０４は、第二のクラスパス５１４に設定されているアプリ内包ライブラリ５０１を全て解凍する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの解凍を行う。理由は上述した通りである。アプリ内包ライブラリ５０１の解凍処理が終わったら、Ｓ８２０６に処理を進める。Ｓ８２０６で、Ｌｉｂ管理モジュール３０４はＳ８２０３、およびＳ８２０５で解凍した全てのクラスファイルを統合ライブラリ３０５として１つのＪＡＲファイル形式に圧縮する。統合ライブラリ３０５の構成例は図７（ｂ）に示したとおりであり、図７（ａ）に示す統合前のすべてのクラスファイルが統合されている。そして、Ｓ８２０７で、Ｌｉｂ管理モジュール３０４はＳ８２０６で圧縮して作成した統合ライブラリ３０５を、第一のクラスパス４０２の設定に追加する。統合ライブラリの追加後、Ｓ８２０８でＬｉｂ管理モジュール３０４は第一のクラスパス４０２に設定されている統合ライブラリ以外のライブラリの記載を削除する。この例が図４（ｂ）に示されており、起動オプション設定ファイル４１０のような記載内容にする。ここで、ストレージの使用リソースを軽減させるために、第一のクラスパス４０２の設定から統合ライブラリ以外の記載を削除した後に、Ｌｉｂ管理モジュール３０４が、画像形成装置１００の内部に残っているライブラリ６０１を削除しても良い。Ｌｉｂ管理モジュール３０４は、起動オプション設定ファイルの記載内容を変更すると、統合ライブラリ３０５の作成処理を終了する。
【００２７】
＜クラスのロード処理＞
図８Ｃは、Ｓ８１０３の詳細フローチャートで、メインプログラム実行中にクラスが生成された時のクラスローダ３０２の、本実施例における処理の流れを模式的に表したフローチャートである。
Ｓ８３０１でクラスローダ３０２は、実行中のメインプログラムでロードされていないクラスが実行されたか否かを判定する。クラスがロード済みであった場合はクラスロードの処理は終了し、引き続きメインプログラムの処理を進める。ロードされていなかった場合は、Ｓ８３０２に処理を進める。Ｓ８３０２でクラスローダ３０２は、すでに統合ライブラリ３０５を開いているか否かを判定する。統合ライブラリ３０５が開かれていると判定した場合はＳ８３０４に処理を進め、開かれていないと判定した場合はＳ８３０３に処理を進める。Ｓ８３０３で、クラスローダ３０２は第一のクラスパス４１１に設定されている統合ライブラリ３０５を開く。この時、オープンしたライブラリの数に応じた量のリソースを消費する。具体的には、１つのファイルを開くのでクラスローダ３０２がファイルディスクリプタを１つだけ消費する。そしてＳ８３０４に処理を進める。Ｓ８３０４で、クラスローダ３０２は統合ライブラリ３０５にロードしたいクラスがあるか否かを判定する。ロードしたいクラスが見つかった場合、Ｓ８３０５で、クラスローダ３０２は統合ライブラリ３０５からクラスをロードし、クラスロード処理を終了する。ロードしたいクラスが見つからなかった場合、Ｓ８３０６で、クラスが見つからなかったことを、コンソール画面やブラウザの画面といったユーザインターフェース部２０１を通じてユーザに警告する。そしてクラスロード処理を終了する。
【００２８】
以上ように、本発明の第一の実施例では、アプリケーション実行基盤３０１の起動前に、Ｌｉｂ管理モジュール３０４は統合ライブラリ３０５を作成し、その統合ライブラリ３０５のみを第一のクラスパス４１１に設定する。その結果、クラスファイルが全て統合ライブラリ３０５に含まれるので、アプリケーション実行基盤３０１を起動した後に、クラスローダ３０２がクラスを探索する場合、クラスローダ３０２は統合ライブラリ３０５内のみを探索することでクラスを見つけることができる。すなわち、クラスローダ３０２が開くライブラリは１つのみになるので、使用するファイルディスクリプタの数も１つにすることができる。従って、第一のクラスパス４０２に設定されていたライブラリ数や、第二のクラスパス５１４に設定されていたライブラリ数に依らず、クラスローダ３０２がライブラリを開くために使用するファイルディスクリプタの数を１つにできる。
【００２９】
また、一度統合ライブラリ３０５を作成すれば、次回画像形成装置１００の起動時から、Ｌｉｂ管理モジュール３０４はＳ８２０１で、クラスパスに設定されているライブラリの数が１つである（統合ライブラリのみである）と判定する。そのため、統合ライブラリ３０５の作成処理は初めて画像形成装置１００を起動する時のみに行うだけで済む。さらに、システムのアップデートやアプリのインストールが発生し、起動オプション設定ファイル４１０や、アプリ設定ファイル５０２が更新された場合であっても、画像形成装置１００の次回の起動時にＬｉｂ管理モジュール３０４は統合ライブラリ作成処理を行う。アプリケーションやシステムプログラムのアップデートやインストールにより設定ファイルが更新されることで、第一のクラスパスや第二のクラスパスに設定されるライブラリも複数になることがある。ライブラリが複数になると、画像形成装置１００の次回起動時に、Ｌｉｂ管理モジュール３０４がＳ８２０１でそれを検知し、統合ライブラリを作り直すことができる。
また例えばアプリケーション実行基盤３０１が新たなアプリケーションのインストールや設定ファイルの更新を監視し、更新されたと判定すると、Ｌｉｂ管理モジュール３０４により図８Ｂの処理を実行させてもよい。
なお、本実施例では、統合ライブラリのみを第一のクラスパスに設定するようにしたが、画像形成装置１００で使用可能なファイルディスクリプタの上限値に納まるようであれば、一部のライブラリのみを統合ライブラリとして作成しても良い。例えば、Ｌｉｂ管理モジュール３０４が第一のクラスパス４０２に設定されているライブラリのみを解凍して、そこで解凍されたクラスファイルを統合ライブラリとして圧縮する。そして、Ｌｉｂ管理モジュール３０４は、統合ライブラリを第一のクラスパスに追加して、第一のクラスパスに設定されている解凍したライブラリのみ、記載を削除する。このようにすることで、Ｌｉｂ管理モジュール３０４の統合ライブラリ作成の処理が減るので、パフォーマンスを向上させることができる。このように、ライブラリの数が複数である場合には、それらライブラリに含まれたクラスを、そのライブラリの数より少ない数のライブラリ（本実施例では１つ）に統合する。統合後のライブラリの数が統合前のライブラリの数よりも少なければ、リソース消費量の節減という課題を解決できる。
【００３０】
［第二の実施例］
次に本発明の第二の実施例について図を用いて解説する。
第一の実施例では、第一のクラスパス４０２と第二のクラスパス５１４に設定されるライブラリ内の全てのクラスを１つの統合ライブラリ３０５として圧縮した。ここで、あるアプリケーション１１０の第二のクラスパス５１４に設定されていたライブラリのクラスを、１つの統合ライブラリとして圧縮すると、他のアプリケーション（例えば１１１）からもそのクラスを実行することができる。しかしながら、不正な動作を行うアプリケーションや、悪意のあるアプリケーションが、他のアプリケーションのクラスを実行すると画像形成装置１００の動作が不安定になる可能性がある。なお、一般的には、クラスパスを、ブートクラスパス、システムクラスパス、アプリクラスパスなどで分けて、それぞれのクラスパス設定で実行できるクラスの範囲を設定している。これにより、不正な動作を行うアプリケーションや、悪意のあるアプリケーションが、他のアプリケーションのクラスを実行することを防げるが、ライブラリ数増加によるファイルディスクリプタの消費数の増大を防ぐことができない。第二の実施例では、クラスの範囲ごとにクラスを統合することで、アクセス可能なクラスの制限と、ファイルディスクリプタの消費数の抑制とを両立させる。
【００３１】
本発明の第二の実施例の装置の構成を示す図は図１に掲げるものと同様である。
また本実施例における画像形成装置１００のハードウェア構成は図２に示したものと同様である。
【００３２】
図９は、本実施例における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境である。
アプリクラスローダ群９００は、アプリ管理フレームワーク３０３が各アプリケーションに対して生成するアプリクラスローダ９０１をまとめたアプリクラスローダ群である。アプリクラスローダ９０１は、アプリ内包ライブラリ５０２のクラスをロードするためのクラスローダである。アプリ管理フレームワーク３０３は、アプリケーション１１ｎを開始する際に、開始するアプリケーション用のアプリクラスローダ９０１生成する。そのため、各アプリケーション１１ｎに対応するアプリクラスローダ９０１が生成される。各種クラスローダの動作として、ロードされていないクラスが実行された場合、まずクラスローダ３０２がブートクラスパス１０１１、システムクラスパス１０１２（いずれも図１０で説明する）に設定されているライブラリから、ロードするクラスを探索する。第一の実施例ではブートクラスパスとシステムクラスパスをまとめて第一のクラスパスと呼んでいたが、以降の実施例では、それぞれブートクラスパス、システムクラスパスとそれぞれ分けて呼び実施例の説明を行う。また第一の実施例ではアプリクラスパスを第二のクラスパスと呼んでいたが、以降の実施例ではアプリクラスパスと呼び実施例の説明を行う。クラスローダ３０２が、ブートクラスパス１０１１およびシステムクラスパス１０１２に設定されているライブラリからクラスを見つけられた場合は、そのライブラリからクラスをロードする。見つけられなかった場合は、アプリクラスローダ群９００を起動する。そして処理を実行しているアプリケーション１１ｎに対応するアプリクラスローダ９０１が、アプリクラスパス１１０１に設定されているライブラリからロードするクラスを探索する。そこでクラスを見つけられればアプリクラスローダ９０１がクラスをロードする。アプリクラスローダ９０１もクラスを見つけることができなかった場合は、クラスが見つからなかったことをコンソール画面やブラウザの画面などのユーザインターフェース部を通じてユーザに警告する。
また、ブートクラスパス１０１１、システムクラスパス１０１２、各アプリケーション１１ｎに対するアプリクラスパス１１０１の設定で実行できるクラスの範囲はそれぞれ異なっている。
【００３３】
統合ライブラリ群９０２は、Ｌｉｂ管理モジュール３０４によって作成される統合ライブラリをまとめたライブラリ群である。本実施例の統合ライブラリ群９０２にはブートクラスパス統合ライブラリ９０３、システムクラスパス統合ライブラリ９０４、アプリクラスパス統合ライブラリ群９０６が含まれる。アプリクラスパス統合ライブラリ群９０６の各ライブラリは、アプリクラスローダ９０１と同様に、各アプリケーション１１ｎに対応したクラスを統合したアプリクラスパス統合ライブラリ９０５が存在する。
これら統合ライブラリ群９０２はＬｉｂ管理モジュール３０４によって作成される。Ｌｉｂ管理モジュール３０４は起動モジュール３００に統合ライブラリ作成処理を命令されると、まずブートクラスパス１００１に設定されているライブラリを全て解凍する。そして、解凍して展開されたクラスを新しいブートクラスパス統合ライブラリ９０３としてJARファイル形式で圧縮し直す。Ｌｉｂ管理モジュール３０４は、ブートクラスパス統合ライブラリ９０３を作成した後、起動オプション設定ファイル１０００にあるブートクラスパス１００１の設定を、新しく作成したブートクラスパス統合ライブラリ９０３のみになるように変更する。
次にＬｉｂ管理モジュールはシステムクラスパス１００２（図１０を参照して後述する）に設定されているライブラリを全て解凍する。そして、解凍して展開されたクラスを新しいシステムクラスパス統合ライブラリ９０４としてJARファイル形式で圧縮し直す。その後、Ｌｉｂ管理モジュール３０４は、起動オプション設定ファイル１０００にあるシステムクラスパス１００２の設定を、新しく作成したシステムクラスパス統合ライブラリ９０４のみになるように変更する。
【００３４】
最後にＬｉｂ管理モジュール３０４はインストールされているアプリケーション１１ｎごとに、アプリクラスパス統合ライブラリ作成処理を行う。アプリクラスパス統合ライブラリ作成処理として、まず、Ｌｉｂ管理モジュール３０４はアプリクラスパス１１０１（図１１を参照して後述する）に設定されたライブラリを全て解凍する。そして、解凍して展開されたクラスを新しいアプリクラスパス統合ライブラリ９０５としてJARファイル形式で圧縮し直す。Ｌｉｂ管理モジュール３０４は、アプリクラスパス統合ライブラリ９０５を作成した後、アプリ設定ファイル５０２にあるアプリクラスパス５１４のライブラリの設定を、新しく作成したアプリクラスパス統合ライブラリ９０５のみになるように変更する。ここまでの処理をインストールされたアプリケーション１１ｎすべてに対して行うと、Ｌｉｂ管理モジュール３０４のアプリクラスパス統合ライブラリの作成処理が完了する。
【００３５】
このようにして、Ｌｉｂ管理モジュール３０４はブートクラスパス、システムクラスパス、アプリクラスパスとして設定されていた複数ライブラリ内のクラス群をそれぞれの統合ライブラリとして作成し、その作成した統合ライブラリを各クラスパスに設定する。各統合ライブラリをクラスパスの種類ごとに設定することで、実行できるクラスの範囲をそれぞれのクラスパスの範囲に合わせて設定することができる。
【００３６】
＜起動オプション設定ファイル例＞
図１０は本実施例における起動オプション設定を記載する代表的なファイルの内容について解説した図である。
図１０（ａ）は、本実施例におけるＬｉｂ管理モジュール３０４によって変更される前の起動オプション設定ファイル１０００を示す図である。起動オプション設定ファイル１０００は、Ｌｉｂ管理モジュール３０４が起動オプション設定ファイルの内容を変更する前の記載内容である。ブートクラスパス１００１は、Ｊａｖａ（登録商標）の実行環境を起動するために必要なライブラリの所在場所を示すためのブートクラスパスである。システムクラスパス１００２は、アプリケーション実行基盤３０１、及びアプリ管理フレームワーク３０３を起動するために必要なライブラリの所在場所を示すためのシステムクラスパスである。
図１０（ｂ）は、本実施例におけるＬｉｂ管理モジュール３０４によって変更された後の起動オプション設定ファイル１０１０を示す図である。起動オプション設定ファイル１０１０は、Ｌｉｂ管理モジュール３０４がファイルの内容を変更した後の記載内容を示す。本実施例では、起動モジュール３００は起動オプション設定ファイル１０１０の内容を読み込み、読み込んだ内容をアプリケーション実行基盤３０１の起動オプションとして使用する。ブートクラスパス１０１１は、ブートクラスパス統合ライブラリ９０３の所在を示すクラスパスである。Ｌｉｂ管理モジュール３０４はブートクラスパス統合ライブラリ９０３の作成後に、起動オプション設定ファイル１０００のクラスパス設定にブートクラスパス統合ライブラリを追加してそれを新たなブートクラスパス１０１１とし、統合ライブラリ以外のライブラリをブートクラスパス１００１から削除する。システムクラスパス統合ライブラリ１０１２は、システムクラスパス統合ライブラリ９０４の所在を示すクラスパスである。Ｌｉｂ管理モジュール３０４はシステムクラスパス統合ライブラリ９０４の作成後に、起動オプション設定ファイル１０００のクラスパス設定にシステムクラスパス統合ライブラリを追加してそれを新たなシステムクラスパス１０１２とし、統合ライブラリ以外のライブラリをシステムクラスパス１００２から削除する。
【００３７】
＜アプリ設定ファイル例＞
図１１は、Ｌｉｂ管理モジュール３０４によって、アプリクラスパス５１４に設定されたライブラリの記載を削除された後の、アプリ設定ファイル５０２に記載されている項目の例を示す図である。起動モジュール３００が統合ライブラリの作成処理をＬｉｂ管理モジュール３０４に命令すると、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２のアプリクラスパス５１４を参照する。そして、そこに設定されているアプリ内包ライブラリ５０１を解凍し、解凍されたクラスをアプリクラスパス統合ライブラリ９０５としてJARファイル形式で圧縮し直す。その後、Ｌｉｂ管理モジュール３０４はアプリクラスパス５１４を、新しく作成したアプリクラスパス統合ライブラリ９０５のみになるように変更し、アプリクラスパス５１４に設定された統合ライブラリ以外のライブラリの記載を削除する。アプリ設定ファイル１１００は、Ｌｉｂ管理モジュール３０４がライブラリの記載を削除した後のアプリ設定ファイルを表している。アプリクラスパス１１０１は、アプリクラスパス統合ライブラリ９０５が設定されたアプリクラスパスである。所在情報１１０２は、アプリクラスパスに設定されているアプリ実行コードファイル５００やアプリクラスパス統合ライブラリの所在場所の情報である。
【００３８】
＜統合ライブラリ群の構成例＞
図１２は、Ｌｉｂ管理モジュール３０４が各クラスパスのライブラリを解凍した後、クラスパスごとにクラスファイルを圧縮して作成したそれぞれの統合ライブラリ内を示した図である。すなわち図１２は統合ライブラリ群９０２の内容を例示する。ブートクラスパス統合ライブラリ１２０１は、ブートクラスパス１０１１に設定されているブートクラスパス統合ライブラリ９０３内のクラスファイルの配置である。システムクラスパス統合ライブラリ１２０２は、システムクラスパス１０１２に設定されているシステムクラスパス統合ライブラリ９０４内のクラスファイルの配置である。アプリクラスパス統合ライブラリ１２０３〜１２０５は、インストールされている各アプリケーション１１ｎのアプリクラスパス１１０１に設定されているアプリクラスパス統合ライブラリ９０５内のクラスファイルの配置である。
各クラスパスに設定されていたライブラリのクラスファイルは、各統合ライブラリ内に全て配置されている。そのため、クラスローダ３０１やアプリクラスローダ９０１はこれらの統合ライブラリからクラスを探索するだけで、処理の実行に必要なクラスを見つけることが出来る。
【００３９】
＜統合ライブラリ生成処理＞
図１３Ａは、Ｓ８１０１の詳細フローチャートで、起動モジュール３００に統合ライブラリの作成処理を命令された際のＬｉｂ管理モジュール３０４の、本実施例における処理の流れを模式的に表したフローチャートである。なお図８Ａの手順は、本実施例と第一実施例とで共通である。画像形成装置１００の電源を入れてから、切るまでの処理の流れは第一の実施例と同様である。
Ｓ１３１０１で、Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル１０００を読み込んで、ブートクラスパス１００１に複数のライブラリが設定されているか否かを判定する。ブートクラスパス１００１にライブラリが複数設定されている場合はＳ１３１０２に処理を進め、複数設定されていない場合はＳ１３１１０に処理を進める。Ｓ１３１０２で、Ｌｉｂ管理モジュール３０４は、ブートクラスパス１００１に設定されているライブラリを全て解凍する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの解凍を行う。例えば、図１０（ａ）の記載内容の場合、Ｌｉｂ管理モジュール３０４はＬｉｂｓｙｓｔｅｍ００２．ｊａｒ、Ｌｉｂｓｙｓｔｅｍ００１．ｊａｒの順にライブラリを解凍する。このように、後に記載されたライブラリから解凍することで、同じ名前空間で同じクラス名が、万が一存在して衝突した場合に、先に解凍されたクラスファイルを、後から解凍されたクラスファイルで上書きすることができる。一般的に、同じ名前空間、同じクラス名のものが衝突した場合、クラスパスが先に設定されているクラスファイルをロードする。したがって、クラスの衝突が起きた場合、記載が先にあるライブラリのクラスファイル、すなわち後から解凍されるクラスファイルで上書きすることで、本来、一般的な環境でロードされるはずのクラスの方を残すことができる。Ｓ１３１０３で、Ｌｉｂ管理モジュール３０４はＳ１３１０２で解凍した全てのクラスファイルをブートクラスパス統合ライブラリ９０３として１つのＪＡＲファイル形式に圧縮する。そして、Ｓ１３１０４で、Ｌｉｂ管理モジュール３０４はＳ１３１０３で圧縮して作成したブートクラスパス統合ライブラリを、ブートクラスパス１００１の設定に追加する。その後、Ｓ１３１０５でＬｉｂ管理モジュール３０４はブートクラスパス１００１に設定されているブートクラスパス統合ライブラリ以外のライブラリの記載を削除する（起動オプション設定ファイル１０１１のような記載内容にする）。ここで、ストレージの使用リソースを軽減させるために、Ｓ１３１０５の後に、Ｌｉｂ管理モジュール３０４が、画像形成装置１００の内部に残っているような、ブートクラスパス１００１として設定されていたライブラリを削除しても良い。Ｌｉｂ管理モジュール３０４は、起動オプション設定ファイルの記載内容を変更すると、Ｓ１３１１０に処理を進める。
【００４０】
Ｓ１３１１０で、Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル１０００を読み込んで、システムクラスパス１００２に複数のライブラリが設定されているか否かを判定する。システムクラスパス１００２にライブラリが複数設定されている場合はＳ１３１１１に処理を進め、複数設定されていない場合はＳ１３１２０に処理を進める。Ｓ１３１１１で、Ｌｉｂ管理モジュール３０４は、システムクラスパス１００２に設定されているライブラリを全て解凍する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの解凍を行う。例えば、図１０（ａ）の記載内容の場合、Ｌｉｂ管理モジュール３０４はＬｉｂｓｙｓｔｅｍ００４．ｊａｒ、Ｌｉｂｓｙｓｔｅｍ００３．ｊａｒの順にライブラリを解凍する。このように、後に記載されたライブラリから解凍することで、同じ名前空間で同じクラス名が、万が一存在して衝突した場合に、先に解凍されたクラスファイルを、後から解凍されたクラスファイルで上書きすることができる。一般的に、同じ名前空間、同じクラス名のものが衝突した場合、クラスパスが先に設定されているクラスファイルをロードする。したがって、クラスの衝突が起きた場合、記載が先にあるライブラリのクラスファイル、すなわち後から解凍されるクラスファイルで上書きすることで、本来、一般的な環境でロードされるはずのクラスの方を残すことができる。Ｓ１３１１２で、Ｌｉｂ管理モジュール３０４はＳ１３１１１で解凍した全てのクラスファイルをシステムクラスパス統合ライブラリ９０４として１つのＪＡＲファイル形式に圧縮する。そして、Ｓ１３１１３で、Ｌｉｂ管理モジュール３０４はＳ１３１１２で圧縮して作成したシステムクラスパス統合ライブラリを、システムクラスパス１００２の設定に追加する。その後、Ｓ１３１１４でＬｉｂ管理モジュール３０４はシステムクラスパス１００２に設定されているシステムクラスパス統合ライブラリ以外のライブラリの記載を削除する（起動オプション設定ファイル１０１１のような記載内容にする）。ここで、ストレージの使用リソースを軽減させるために、Ｓ１３１１４の後に、Ｌｉｂ管理モジュール３０４が、画像形成装置１００の内部に残っているような、システムクラスパス１００２として設定されていたライブラリを削除しても良い。Ｌｉｂ管理モジュール３０４は、起動オプション設定ファイルの記載内容を変更すると、Ｓ１３１２０に処理を進める。
【００４１】
Ｓ１３１２０で、Ｌｉｂ管理モジュール３０４は、画像形成装置１００にインストールされているアプリケーション１１ｎの数だけＳ１３１２１〜Ｓ１３１２５の処理を繰り返す。アプリケーション１１ｎがインストールされていなければ、統合ライブラリの作成処理を命令された際のＬｉｂ管理モジュール３０４の処理は終了する。
Ｓ１３１２１で、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２を読み込んで、アプリクラスパス５１４に複数のライブラリが設定されているか否かを判定する。アプリクラスパス５１４にライブラリが複数設定されている場合はＳ１３１２２に処理を進め、複数設定されていない場合、他にインストールされているアプリケーションがなければ、Ｌｉｂ管理モジュール３０４は統合ライブラリの作成処理を終了する。他にインストールされているアプリケーションがある場合は、Ｌｉｂ管理モジュールはそのアプリケーションに対して、Ｓ１３１２１〜Ｓ１３１２５の処理を行う。Ｓ１３１２２で、Ｌｉｂ管理モジュール３０４は、アプリクラスパス５１４に設定されているライブラリを全て解凍する（或いは展開する）。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの解凍を行う。例えば、図５（ｂ）の記載内容の場合、Ｌｉｂ管理モジュール３０４はＬｉｂｐａ００５．ｊａｒ、Ｌｉｂｐａ００４．ｊａｒ、・・・、Ｌｉｂｐａ００１．ｊａｒの順にライブラリを解凍する。このように、後に記載されたライブラリから解凍することで、同じ名前空間で同じクラス名が、万が一存在して衝突した場合に、先に解凍されたクラスファイルを、後から解凍されたクラスファイルで上書きすることができる。一般的に、同じ名前空間、同じクラス名のものが衝突した場合、クラスパスが先に設定されているクラスファイルをロードする。したがって、クラスの衝突が起きた場合、記載が先にあるライブラリのクラスファイル、すなわち後から解凍されるクラスファイルで上書きすることで、本来、一般的な環境でロードされるはずのクラスの方を残すことができる。Ｓ１３１２３で、Ｌｉｂ管理モジュール３０４はＳ１３１２２で解凍した全てのクラスファイルをアプリクラスパス統合ライブラリ９０５として１つのＪＡＲファイル形式に圧縮する。そして、Ｓ１３１２４で、Ｌｉｂ管理モジュール３０４はＳ１３１１２で圧縮して作成したアプリクラスパス統合ライブラリを、アプリクラスパス５１４の設定に追加する。その後、Ｓ１３１２５でＬｉｂ管理モジュール３０４はアプリクラスパス５１４に設定されているアプリクラスパス統合ライブラリ以外のライブラリの記載を削除する（アプリ設定ファイル１１００のような記載内容にする）。ここで、ストレージの使用リソースを軽減させるために、Ｓ１３１１４の後に、Ｌｉｂ管理モジュール３０４が、画像形成装置１００の内部に残っているような、アプリクラスパス５１４として設定されていたライブラリを削除しても良い。画像形成装置１００にインストールされているアプリケーション１１ｎに対してＳ１３１２１〜Ｓ１３１２５の処理が完了したら、Ｌｉｂ管理モジュール３０４は、統合ライブラリの作成処理を終了する。
【００４２】
＜クラスのロード処理＞
図１３Ｂは、Ｓ８１０３の詳細フローチャートで、メインプログラム実行中のクラスローダ３０２とアプリクラスローダ９０１の、本実施例における処理の流れを模式的に表したフローチャートである。
Ｓ１３２００で、アプリケーション実行基盤３０１及びアプリ管理フレームワーク３０３又はそのいずれかがクラスの生成を実行すると、アプリケーション実行基盤３０１及びアプリ管理フレームワーク３０３又はそのいずれかがクラスローダ３０２に生成されたクラスのロード処理を命令する。アプリケーションがクラスの生成処理を実行すると、アプリクラスローダ群９００のうちの、クラスを生成しようとするアプリに対するアプリクラスローダが、クラスローダ３０２に生成されたクラスのロード処理を命令する。Ｓ１３２００で、クラスローダ３０２がクラスのロード処理を命令されると、Ｓ８３０１に処理を進める。Ｓ８３０１でクラスローダ３０２は、実行中のメインプログラムでロードされていないクラスが実行されたか否かを判定する。ロードされていないと判定された場合に、Ｓ１３２０１に処理を進める。Ｓ１３２０１でクラスローダ３０２は、すでにブートクラスパス統合ライブラリ９０３を開いているか否かを判定する。ブートクラスパス統合ライブラリ９０３が開かれていると判定した場合はＳ１３２０３に処理を進め、開かれていないと判定した場合はＳ１３２０２に処理を進める。Ｓ１３２０２で、クラスローダ３０２はブートクラスパス１０１１に設定されているブートクラスパス統合ライブラリ９０３を開く。そして、Ｓ１３２０３に処理を進める。Ｓ１３２０３で、クラスローダ３０２はブートクラスパス統合ライブラリ９０３にロードしたいクラスがあるか否かを判定する。ロードしたいクラスが見つかった場合、Ｓ１３２０４で、クラスローダ３０２はブートクラスパス統合ライブラリ９０３からクラスをロードし、クラスロード処理を終了する。ロードしたいクラスが見つからなかった場合、Ｓ１３２１０に処理を進める。
【００４３】
Ｓ１３２１０でクラスローダ３０２は、すでにシステムクラスパス統合ライブラリ９０４を開いているか否かを判定する。システムクラスパス統合ライブラリ９０４が開かれていると判定した場合はＳ１３２１２に処理を進め、開かれていないと判定した場合はＳ１３２１１に処理を進める。Ｓ１３２１１で、クラスローダ３０２はシステムクラスパス１０１２に設定されているシステムクラスパス統合ライブラリ９０４を開く。そして、Ｓ１３２１２に処理を進める。Ｓ１３２１２で、クラスローダ３０２はシステムクラスパス統合ライブラリ９０４にロードしたいクラスがあるか否かを判定する。ロードしたいクラスが見つかった場合、Ｓ１３２１３で、クラスローダ３０２はシステムクラスパス統合ライブラリ９０４からクラスをロードし、クラスロード処理を終了する。ロードしたいクラスが見つからなかった場合、Ｓ１３２２４に処理を進める。Ｓ１３２２４で、クラスローダ３０２は、アプリクラスローダ９０１からクラスのロード処理を命令されているか否かを判定する。アプリケーション実行基盤３０１、あるいはアプリ管理フレームワーク３０３がクラスの生成処理を実行する場合は、アプリケーション実行基盤３０１、あるいはアプリ管理フレームワーク３０３が、クラスローダ３０２にクラスのロード処理を命令する。それに対し、アプリケーション１１ｎがクラスの生成処理を実行した場合は、アプリクラスローダ９０１がクラスローダ３０２にクラスのロード処理を命令する。Ｓ１３２２４におけるクラスロード処理の状態は、クラスローダ３０２が、ブートクラスパスにもシステムクラスパスにも、設定されているライブラリからロードするクラスを見つけられなかった状態である。そのため、アプリクラスローダ９０１がクラスロード処理を命令した場合、クラスローダ３０２はアプリクラスローダ９０１にクラスロード処理を返し、アプリクラスローダ９０１がアプリクラスパスに設定されているライブラリからクラスロード処理を行う。ここで、クラスローダ３０２はクラスのロード処理を命令したアプリクラスローダ９０１に処理を返す。ロード処理を命令したアプリクラスローダ９０１は、クラスの生成処理を実行したアプリに対するアプリクラスローダであるため、複数あるアプリケーション群のうちから、クラスの生成処理を実行したアプリに対してのクラスロード処理を行うことができる。アプリクラスローダ９０１のクラスロード処理はＳ１３２２０で行う。アプリケーション実行基盤３０１、あるいはアプリ管理フレームワーク３０３が、クラスローダ３０２にクラスのロード処理を命令した場合はＳ８３０６に処理を進める。
【００４４】
Ｓ１３２２０で、アプリクラスローダ９０１は、処理を実行中のアプリケーション１１ｎに対するアプリクラスパス統合ライブラリ９０５をすでに開いているか否かを判定する。アプリクラスパス統合ライブラリ９０５が開かれていると判定した場合はＳ１３２２２に処理を進め、開かれていないと判定した場合はＳ１３２２１に処理を進める。Ｓ１３２２１で、アプリクラスローダ９０１はアプリクラスパス１１０１に設定されているアプリクラスパス統合ライブラリ９０５を開く。そして、Ｓ１３２２２に処理を進める。Ｓ１３２２２で、アプリクラスローダ９０１はアプリクラスパス統合ライブラリ９０５にロードしたいクラスがあるか否かを判定する。ロードしたいクラスが見つかった場合、Ｓ１３２２３で、アプリクラスローダ９０１はアプリクラスパス統合ライブラリ９０５からクラスをロードし、クラスロード処理を終了する。ロードしたいクラスが見つからなかった場合、Ｓ８３０６に処理を進める。Ｓ８３０６、あるいはＳ１３２２３の処理が完了すると、クラスロード処理を終了する。
【００４５】
以上の手順をまとめると以下のように書ける。プログラムの実行中にクラスの生成処理が実行されると、クラスローダはクラスロード処理を行う。生成するクラスがロードされていない場合、クラスローダ３０２はブートクラスパスに設定されているブートクラスパス統合ライブラリ９０３からロードするクラスを探索する。ブートクラスパスに設定されているブートクラスパス統合ライブラリ９０３からクラスを見つけられた場合は、クラスローダ３０２はブートクラスパス統合ライブラリ９０３からクラスのロードを行う。ブートクラスパス統合ライブラリ９０３からクラスを見つけられなかった場合、クラスローダ３０２はシステムクラスパス統合ライブラリ９０４からロードするクラスを探索する。システムクラスパス統合ライブラリ９０４からクラスを見つけられた場合は、クラスローダ３０２はシステムクラスパスで示されたシステムクラスパス統合ライブラリ９０４からクラスのロードを行う。システムクラスパス統合ライブラリ９０４からクラスを見つけられなかった場合、クラスローダ３０２はクラスロード処理をやめ、実行中のプログラムがシステムかアプリかを判定する。実行中のプログラムが、アプリケーション実行基盤３０１や、アプリ管理フレームワーク３０３などのシステムであった場合、クラスローダ３０２はクラスが見つからなかったエラーを警告する。実行中のプログラムがアプリであった場合、実行中のアプリのアプリクラスローダ９０１がクラスロード処理を行う。なお、アプリケーションの実行に伴ってアプリケーション実行基盤３０１やアプリ管理フレームワーク３０３が実行されている場合には、実行中のプログラムはアプリであると判定されるものとする。アプリがクラス生成処理を実行する場合、アプリクラスローダ群９００がクラスローダ３０２にクラスのロード処理を命令する。クラスローダ３０２は、クラスを見つけられなかった時に、クラスのロード処理を命令したアプリクラスローダ９０１に処理を返すことで、プログラム実行中のアプリに対するアプリクラスローダ９０１がクラスロード処理を始めることができる。例えば、アプリケーションＡ１１０に対するアプリクラスローダをアプリクラスローダＡとすると、実行中のプログラムがアプリケーションＡ１１０である場合、アプリクラスローダＡがクラスのロード処理をクラスローダ３０２に命令する。クラスローダ３０２がブートクラスパス統合ライブラリ９０３からも、クラスパス統合ライブラリ９０４からもロードするクラスを見つけられなかった場合、クラスローダ３０２はアプリクラスローダＡに処理を返す。アプリクラスローダＡに処理が返るため、複数あるアプリケーションの中から実行中であるアプリケーションＡ１１０のアプリクラスパスに設定されているアプリクラスパス統合ライブラリからクラスのロード処理を実行できる。アプリクラスローダがロード処理を始めると、アプリクラスローダは、対応するアプリクラスパス統合ライブラリ９０５からロードするクラスを探索する。アプリクラスパス統合ライブラリ９０５からロードするクラスを見つけられた場合、アプリクラスローダＡはクラスのロードを行う。アプリクラスパス統合ライブラリ９０５からロードするクラスを見つけられなかった場合は、クラスローダ３０２はクラスが見つからなかったエラーを警告する。クラスローダ３０２、あるいはアプリクラスローダＡがクラスをロードするか、あるいはロードするクラスが見つからず警告を出した場合、クラスのロード処理が終了する。
【００４６】
以上ように、本発明の第二の実施例では、アプリケーション実行基盤３０１の起動前に、Ｌｉｂ管理モジュール３０４は各クラスパスに対するライブラリを統合して統合ライブラリを作成し、その統合ライブラリのみを各クラスパスに設定する。その結果、各クラスパスに設定されていたライブラリのクラスファイルが全て統合ライブラリに含まれるので、クラスローダ３０２がクラスを探索する場合、クラスローダ３０２は各統合ライブラリ内のみを探索することでクラスを見つけることができる。そして、各統合ライブラリをクラスパスの種類ごとに設定しているので、実行できるクラスの範囲をそれぞれのクラスパスの範囲に合わせることができる。従って、各クラスパスに複数設定されていたライブラリの数に依らず、クラスローダのファイルディスクリプタ消費数をクラスパスの種類の数だけにすることができる。かつ、不正な動作を行うアプリケーションや、悪意のあるアプリケーションが、他のアプリケーションのクラスを実行することを防ぐことができる。
【００４７】
なお、本実施例では、ブートクラスパス、システムクラスパス、アプリクラスパスに対して統合ライブラリを作成し、クラスパスに設定するようにした。しかし、画像形成装置１００で使用可能なファイルディスクリプタの上限値に納まるようであれば、一部の種類のクラスパスのみに対して、統合ライブラリを作成し、設定しても良い。例えば、Ｌｉｂ管理モジュールがブートクラスパス、システムクラスパスに対してのみ統合ライブラリを作成し、クラスパスに設定しても良い。このようにすることで、Ｌｉｂ管理モジュール３０４の統合ライブラリ作成の処理が減るので、パフォーマンスを向上させることができる。
【００４８】
［第三の実施例］
次に本発明の第三の実施例について図を用いて解説する。
第一の実施例、及び第二の実施例では、画像形成装置１００の起動時にＬｉｂ管理モジュール３０４が統合ライブラリを作成し、クラスパスに設定する。画像形成装置１００の起動時に、Ｌｉｂ管理モジュール３０４がアプリクラスパスにライブラリが複数設定されているか否かを判定するため、新しくアプリケーション１１ｎがインストールされても統合ライブラリ作成処理を実行できる。しかしながら、アプリケーション１１ｎを画像形成装置１００にインストールした後に、ユーザ管理者が、画像形成装置１００を再起動せずに、アプリケーション１１ｎを開始する場合がある。その場合、画像形成装置１００を再起動するまで、新しくインストールされたアプリケーション１１ｎのライブラリの数分、クラスローダがファイルディスクリプタを消費してしまう。本実施例では、アプリケーションのインストール時にもライブラリの統合処理を行うことで、画像形成装置の再起動を行わなくともクラスライブラリを統合できるシステムを説明する。
【００４９】
本発明の第三の実施例の装置の構成を示す図は図１と同様である。また本実施例における画像形成装置１００のハードウェア構成は図２と同様である。本実施例における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境の構成図は図９と同様である。起動オプション設定ファイル、アプリ設定ファイルの構成はそれぞれ図１０（ｂ）、図１１と同様である。また、画像形成装置１０１の起動から電源オフまでの処理手順は図１４Ａに示したとおりである。
【００５０】
＜画像形成装置１００による処理＞
図１４Ａは、本実施例における画像形成装置１００の電源を入れてから、切るまでの処理の流れを模式的に表したフローチャートである。なお、個々のステップは図８と相違するものの、実行主体などについては図８と同様である。
Ｓ８１０１、Ｓ８１０２は図８Ａに示す処理と同様である。Ｓ８１０１の詳細は図１３Ａに示した手順である。Ｓ１４１０１で、メインプログラムの実行中に、アプリ管理フレームワーク３０３がアプリケーション１１ｎのリクエストを受信したか否かを判定する。ユーザ管理者が画像形成装置１００にアプリケーション１１ｎのインストールを行うようにリクエストを送ると、アプリ管理フレームワーク３０３がそのリクエストを受信する。アプリケーション１１ｎのインストールリクエストを受信していればＳ１４１０２に進み、受信していなければＳ８１０３に処理を進める。Ｓ８１０３、Ｓ８１０４は図８Ａに示す処理と同様である。Ｓ８１０３の詳細は図１３Ｂに示した手順である。Ｓ１４１０２で、アプリ管理フレームワーク３０３が、Ｓ１４１０１でユーザに指定されたアプリケーション１１ｎを画像形成装置１００にインストールする。アプリケーション１１ｎのインストール処理が完了するとＳ１４１０３に進む。Ｓ１４１０３で、アプリ管理フレームワーク３０３はＬｉｂ管理モジュール３０４に、インストールしたアプリケーション１１ｎに対するアプリクラスパス統合ライブラリ９０５の作成処理を命令する。Ｌｉｂ管理モジュール３０４がアプリクラスパス統合ライブラリ９０５の作成処理を完了すると、Ｓ１４１０４に処理を進める。Ｓ１４１０４で、アプリ管理フレームワーク３０２が、インストールしたアプリケーション１１ｎを開始可能な状態にする。アプリケーション１１ｎが開始可能な状態になると、ユーザ管理者はインストールしたアプリケーション１１ｎの開始リクエストを画像形成装置１００に送ることができる。アプリケーション１１ｎが開始可能な状態になった後、Ｓ８１０３に処理を進める。
【００５１】
＜統合ライブラリ作成処理＞
図１４Ｂは、Ｓ１４１０３の詳細フローチャートで、アプリ管理フレームワークにアプリクラスパス統合ライブラリの作成処理を命令された際のＬｉｂ管理モジュールの、本実施例における処理の流れを模式的に表したフローチャートである。
Ｓ１４２０１で、Ｌｉｂ管理モジュール３０４はインストールするアプリケーション１１ｎのアプリ設定ファイル５０２を読み込んで、アプリクラスパス５１４に複数のライブラリが設定されているか否かを判定する。アプリクラスパス５１４にライブラリが複数設定されている場合はＳ１３１２２に処理を進め、複数設定されていない場合、Ｌｉｂ管理モジュール３０４はアプリインストール時のアプリクラスパス統合ライブラリ９０５の作成処理を終了する。Ｓ１３１２２〜Ｓ１３１２５は図１３Ｂに示す処理と同様である。
【００５２】
本実施例におけるクラスローダ３０２、アプリクラスローダ９０１のクラスをロードする際の処理の流れは図１３Ａと同様である。
【００５３】
以上のように、本発明の第三の実施例では、アプリケーション１１ｎをインストールした後に、Ｌｉｂ管理モジュール３０４がアプリクラスパス統合ライブラリ９０５を作成し、アプリクラスパス１１０１に設定する。そして、アプリクラスパス統合ライブラリ作成処理の後に、アプリ管理フレームワーク３０３がインストールしたアプリケーション１１ｎを開始可能な状態にする。その結果、画像形成装置１００を再起動する前に、ユーザ管理者がインストールしたアプリケーション１１ｎを開始しても、アプリクラスローダ９０１がアプリクラスパス統合ライブラリ９０５を利用することができる。すなわち、インストールしたアプリケーション１１ｎのアプリクラスパスに設定されていたライブラリの数に依らず、インストールしたアプリケーションに対するアプリクラスローダ９０１のファイルディスクリプタ消費数を１つにすることができる。
【００５４】
［その他の実施例］
第三実施例は、第二実施例をベースにしているが、第一実施例をベースにしてもよい。その場合には、図１４ＡのＳ８１０１の詳細を図８Ｂとし、Ｓ８１０３の詳細を図８Ｃとする。また、図１４ＢのＳ１３１２２〜Ｓ１３１２５を、図８ＢのＳ８２０５〜Ｓ８２０８で置き換えればよい。
【００５５】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５６】
１００  画像形成装置、１０１  情報処理装置、１２０  ネットワーク、３００  起動モジュール、３０２  クラスローダ、３０３  アプリケーション管理フレームワーク、３０４  Ｌｉｂ管理モジュール、３０５  統合ライブラリ
【図１】
2017126293.tif 000003
【図２】
2017126293.tif 000004
【図３】
2017126293.tif 000005
【図４】
2017126293.tif 000006
【図５】
2017126293.tif 000007
【図６】
2017126293.tif 000008
【図７】
2017126293.tif 000009
【図８Ａ】
2017126293.tif 000010
【図８Ｂ】
2017126293.tif 000011
【図８Ｃ】
2017126293.tif 000012
【図９】
2017126293.tif 000013
【図１０】
2017126293.tif 000014
【図１１】
2017126293.tif 000015
【図１２】
2017126293.tif 000016
【図１３Ａ】
2017126293.tif 000017
【図１３Ｂ】
2017126293.tif 000018
【図１４Ａ】
2017126293.tif 000019
【図１４Ｂ】
2017126293.tif 000020