JP2017157103A - 情報処理装置およびライブラリ管理方法 - Google Patents
情報処理装置およびライブラリ管理方法 Download PDFInfo
- Publication number
- JP2017157103A JP2017157103A JP2016041492A JP2016041492A JP2017157103A JP 2017157103 A JP2017157103 A JP 2017157103A JP 2016041492 A JP2016041492 A JP 2016041492A JP 2016041492 A JP2016041492 A JP 2016041492A JP 2017157103 A JP2017157103 A JP 2017157103A
- Authority
- JP
- Japan
- Prior art keywords
- library
- libraries
- class
- file
- integrated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
Abstract
【課題】ソフトウェアのアップデートや機能拡張により使用するライブラリが増加しても、ファイルディスクリプタの消費を抑制する。【解決手段】装置の起動処理の一部として、またはアプリケーション１１０〜１１２がインストールされた場合に、Ｌｉｂ管理モジュール３０４は、クラスパスの設定にライブラリ３０５が複数あるか否かを判定し、ライブラリ３０５が複数設定されていると判定された場合に、設定されているライブラリ３０５を展開して、新たなライブラリ３０５として統合した後に、新しく作成したライブラリ３０５を、クラスパスとして設定する。また、Ｌｉｂ管理モジュール３０４は、統合後のライブラリ３０５に含めたライブラリ３０５を、直接アクセスされるものを除いて削除する。【選択図】図３
Description
本発明は、クラスパスに設定されているライブラリを管理する情報処理装置およびライブラリ管理方法に関わる。
Ｊａｖａ（登録商標）の実行環境において、クラス（実行に必要なコード）のロードはクラスローダによって行われる。クラスは、ＪＡＲ（Ｊａｖａ Ａｒｃｈｉｖｅ）形式のライブラリの中にあるクラスファイルで定義されている。ライブラリは複数のクラスのクラスファイルから構成されており、特定の機能毎に分けられていることが多い。なお、ライブラリが存在する場所を示すパスはクラスパスとして、あらかじめＪａｖａ（登録商標）の実行環境に設定しておく必要がある。これはクラスのロード時に、クラスローダが、クラスパスに設定されているライブラリから、ロードするクラスを探索するためである。ここで、クラスローダは、ライブラリを参照してクラスを探索するため、ファイルディスクリプタを消費することになる。Ｊａｖａ（登録商標）の実行環境では、パフォーマンスを向上させるため、あるいはライブラリへの参照が切れて動作が不安定になることを防ぐために、一度参照したライブラリは、実行環境上で動作するプログラムが終了するまで参照される。そのため、クラスローダがライブラリを参照するために消費したファイルディスクリプタはプログラムが終了するまで消費され続けることになる。
組込機器において、アプリケーションの実行環境である情報処理装置には、使用可能なリソースに制限がある。ファイルディスクリプタもリソースの一種であり、使用可能なファイルディスクリプタ数に制限がある。そのため、以下のようなことが行われている。まず、開発者はアプリケーションが使用するリソース量について上限値を定める。そして、ユーザ管理者がアプリケーションを開始する際に、その上限値に基づいて、アプリケーション管理フレームワークは情報処理装置の使用可能なリソース量を超えないことを確認する。
従来技術として、全く使用されることのないクラスを検知して、クラスパスから使用されることのないクラスがあるライブラリを削除する技術がある（例えば特許文献１）。
特許文献１は、クラスパスから使用されるクラスがあるライブラリに対しては、そのまま残している。つまり、クラスパスから使用されるクラスがあるライブラリの数が多いと、ファイルディスクリプタを多く消費する。そのため、ファイルディスクリプタの使用可能な数を超えてしまうと、結果として、起動処理に影響を及ぼす。特に、ソフトウェアのアップデートや機能拡張により、ライブラリの増加が重なっていくと、ファイルディスクリプタの消費数が増えることになる。
そこで本願発明の目的は、使用するライブラリが増加したとしても、ファイルディスクリプタの消費を抑制することにある。
上記目的を達成するために本発明は以下の構成を有する。
インストールされたプログラムを実行する際に、前記プログラムで用いられるクラスを含むライブラリを開いて当該クラスをロードするロード手段であって、開いたライブラリの数に応じた量のリソースを消費する前記ロード手段と、
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定手段と、
前記ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数の統合ライブラリに統合する統合手段と、
前記統合ライブラリに含まれたクラスを含む統合前の前記ライブラリを、前記ロード手段を介さずにアクセスされるライブラリを除いて削除する削除手段とを有することを特徴とする情報処理装置。
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定手段と、
前記ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数の統合ライブラリに統合する統合手段と、
前記統合ライブラリに含まれたクラスを含む統合前の前記ライブラリを、前記ロード手段を介さずにアクセスされるライブラリを除いて削除する削除手段とを有することを特徴とする情報処理装置。
本発明によれば、クラスロード時に使用するファイルディスクリプタの消費数を削減でき、ライブラリファイル増加に伴うファイルディスクリプタの問題を緩和することができる。加えて、、直接ライブラリファイルにアクセスするモジュールが存在した場合にも問題なく動作させることができ、かつストレージの使用量の削減も達成できる。
以下、本発明を実施するための形態について図面を用いて説明する。
［第一の実施例］
図１に掲げるのは本発明の第一の実施例のシステム全体の構成を示す図である。
画像形成装置１００は本実施例を実装した情報処理装置の一例であり、例えば多機能周辺装置（ＭＦＰ）である。情報処理装置１０１は画像形成装置１００を管理する。ネットワーク１２０は画像形成装置１００と情報処理装置１０１を接続する。情報処理装置１０１は画像形成装置１００をネットワーク１２０経由で利用するために用いられる。アプリケーションＡ１１０は画像形成装置１００上で動作するアプリケーションの一つの例である。アプリケーションＢ１１１は同様に画像形成装置１００上で動作するアプリケーションのもう一つの例である。さらにアプリケーションＣ１１２は同様に画像形成装置１００上で動作するアプリケーションのさらなる一つの例である。画像形成装置１００上では一つ、あるいは複数のアプリケーションを動作させることが可能である。ここではアプリケーションを三つ例示している。以後、「アプリケーション１１ｎ」という表現は、アプリケーションＡ１１０、アプリケーションＢ１１１、アプリケーションＣ１１２にて代表されるような一つまたは複数のアプリケーションを指す。一般利用者および管理者は画像形成装置１００の基本機能、アプリケーション１１ｎ、および、画像形成装置１００やアプリケーション１１ｎを管理するためのリソース管理装置を利用することが可能である。利用に当たっては、画像形成装置１００を直接操作、もしくはネットワーク１２０経由で情報処理装置１０１から操作することが可能である。
図１に掲げるのは本発明の第一の実施例のシステム全体の構成を示す図である。
画像形成装置１００は本実施例を実装した情報処理装置の一例であり、例えば多機能周辺装置（ＭＦＰ）である。情報処理装置１０１は画像形成装置１００を管理する。ネットワーク１２０は画像形成装置１００と情報処理装置１０１を接続する。情報処理装置１０１は画像形成装置１００をネットワーク１２０経由で利用するために用いられる。アプリケーションＡ１１０は画像形成装置１００上で動作するアプリケーションの一つの例である。アプリケーションＢ１１１は同様に画像形成装置１００上で動作するアプリケーションのもう一つの例である。さらにアプリケーションＣ１１２は同様に画像形成装置１００上で動作するアプリケーションのさらなる一つの例である。画像形成装置１００上では一つ、あるいは複数のアプリケーションを動作させることが可能である。ここではアプリケーションを三つ例示している。以後、「アプリケーション１１ｎ」という表現は、アプリケーションＡ１１０、アプリケーションＢ１１１、アプリケーションＣ１１２にて代表されるような一つまたは複数のアプリケーションを指す。一般利用者および管理者は画像形成装置１００の基本機能、アプリケーション１１ｎ、および、画像形成装置１００やアプリケーション１１ｎを管理するためのリソース管理装置を利用することが可能である。利用に当たっては、画像形成装置１００を直接操作、もしくはネットワーク１２０経由で情報処理装置１０１から操作することが可能である。
＜画像形成装置のハードウェア構成＞
図２は画像形成装置１００のハードウェア構成を図式化したものである。
コア部２００はプロセッサーやメモリなどを含む制御部であり、コア部２００に接続された種々のデバイスを、プロセッサーとメモリとが共働してプログラムを実行することで制御する。また、アプリケーションの実行環境を実現し、インストールされたアプリケーションを実行する。コア部２００には、ユーザインターフェース部２０１、記憶装置２０２、ネットワーク１２０に接続するためのネットワークインターフェース部２０３、スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６などが周辺デバイスとして接続されている。コア部２００はこれらデバイスを制御し、その機能をユーザインターフェース２０１あるいはネットワーク１２０を介してユーザに提供するとともに、アプリケーションに対しても提供している。
図２は画像形成装置１００のハードウェア構成を図式化したものである。
コア部２００はプロセッサーやメモリなどを含む制御部であり、コア部２００に接続された種々のデバイスを、プロセッサーとメモリとが共働してプログラムを実行することで制御する。また、アプリケーションの実行環境を実現し、インストールされたアプリケーションを実行する。コア部２００には、ユーザインターフェース部２０１、記憶装置２０２、ネットワーク１２０に接続するためのネットワークインターフェース部２０３、スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６などが周辺デバイスとして接続されている。コア部２００はこれらデバイスを制御し、その機能をユーザインターフェース２０１あるいはネットワーク１２０を介してユーザに提供するとともに、アプリケーションに対しても提供している。
＜アプリケーション実行環境＞
図３は本実施例における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境である。
起動モジュール３００は、アプリケーション実行環境を立ち上げるためのモジュールである。ユーザが画像形成装置１００の電源を入れると、システムが動き出し、起動モジュール３００が、本実施例のための処理である統合ライブラリの作成処理をＬｉｂ管理モジュール３０４に命令する。Ｌｉｂ管理モジュール３０４は、本実施例を実施するためのモジュールであり、クラスパスに設定されているライブラリを一つの統合ライブラリとして作成し直すモジュールである。統合ライブラリの作成処理が終わった後に、起動モジュール３００はアプリケーション実行基盤３０１を起動する。アプリケーション実行基盤３０１はＪａｖａ（登録商標）の実行環境であり、例えばＪａｖａ（登録商標）ＶＭ（仮想マシン）である。クラスローダ３０２は、クラスをロードするためのモジュールである。アプリケーションやシステムプログラムが実行され、その中でクラスが使用されると、そのクラスは、クラスパスで特定されるそのクラスを含むライブラリからクラスローダ３０２によって動的にロードされる。
図３は本実施例における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境である。
起動モジュール３００は、アプリケーション実行環境を立ち上げるためのモジュールである。ユーザが画像形成装置１００の電源を入れると、システムが動き出し、起動モジュール３００が、本実施例のための処理である統合ライブラリの作成処理をＬｉｂ管理モジュール３０４に命令する。Ｌｉｂ管理モジュール３０４は、本実施例を実施するためのモジュールであり、クラスパスに設定されているライブラリを一つの統合ライブラリとして作成し直すモジュールである。統合ライブラリの作成処理が終わった後に、起動モジュール３００はアプリケーション実行基盤３０１を起動する。アプリケーション実行基盤３０１はＪａｖａ（登録商標）の実行環境であり、例えばＪａｖａ（登録商標）ＶＭ（仮想マシン）である。クラスローダ３０２は、クラスをロードするためのモジュールである。アプリケーションやシステムプログラムが実行され、その中でクラスが使用されると、そのクラスは、クラスパスで特定されるそのクラスを含むライブラリからクラスローダ３０２によって動的にロードされる。
ロードされていないクラスの実行処理を命令された場合、クラスローダ３０２は、クラスパスに設定されているライブラリから、実行処理を命令されているクラスを探索する。クラスはアプリケーション実行基盤３０１が命令を実行するための実行コードになっており、クラスパスはクラスが含まれたライブラリの所在を示すパスの情報である。クラスパスにはシステムに必要なクラスが含まれた第一のクラスパスと、各アプリケーション１１ｎ用のクラスが含まれた第二のクラスパスがある。システムとは狭義にはオペレーティングシステムであるが、本例では、オペレーティングシステムを含む、アプリケーション以外のソフトウェアモジュールを指すこともある。第一のクラスパスは、システムのクラスをロードするために必要なパスであり、ブートクラスパス、システムクラスパスをそれぞれ含む、あるいは少なくともどちらか一方を含むクラスパスのことである。ブートクラスパスはＪａｖａ（登録商標）の実行環境を起動するために必要なクラスを含むライブラリの所在を示すパスである。システムクラスパスはアプリケーション実行基盤３０１、及びアプリ管理フレームワーク３０３を起動するために必要なクラスを含むライブラリの所在を示すパスである。第二のクラスパスは、アプリケーションのクラスを含むライブラリの所在を示すアプリクラスパス（あるいはアプリケーションクラスパス）である。第一のクラスパスは、起動モジュールがアプリケーション実行基盤３０１を起動するときに、起動オプションとしてアプリケーション実行基盤３０１に渡される。アプリケーション実行基盤３０１がその渡された第一のクラスパスを登録する。第二のクラスパスは、アプリ管理フレームワーク３０３がアプリケーション内に含まれるアプリ設定ファイル（例えば図５に示すアプリ設定ファイル５０２）から読み込むクラスパス（図５に示すアプリケーションクラスパス５１４）であり、アプリ管理フレームワーク３０３は読み込んだクラスパスを開始するアプリケーションのためだけ第二のクラスパスとして設定する。そのため、第二のクラスパスといっても、異なるアプリケーション１１ｎそれぞれに対する第二のクラスパスはそれぞれ全く異なったクラスパスとなる。本例ではアプリ設定ファイルとは例えばＪａｖａ（登録商標）のマニフェストファイルである。
クラスローダ３０２がクラスパスに設定されたライブラリからクラスを探索して、ライブラリの中に探索対象のクラスが見つかった場合、クラスローダ３０２はライブラリからクラスをロードする。そして、アプリケーション実行基盤３０１がロードしたクラスを実行する。対象のクラスが見つからなかった場合は、クラスが見つからなかったことをコンソール画面やブラウザの画面などのユーザインターフェース部２０１を通じてユーザに警告する。画像形成装置１００のシステムが動き始めてから、ユーザによって画像形成装置１００の電源が切られるまでに、ロードしていないクラスが実行されると、このようなクラスローダ３０２によるクラスのロード処理が行われる。また、クラスには、同名のクラスが衝突しないように名前空間が開発者によってあらかじめ与えられている。ライブラリは、１つ以上のクラスをＪＡＲ（Ｊａｖａ Ａｒｃｈｉｖｅ）ファイルとして圧縮したファイルになっている。ライブラリの中でもクラスが衝突するのを防ぐために、ＪＡＲファイルには名前空間に対応したディレクトリ階層が構成され、その中にクラスのファイルが配置されていることが一般的である。本実施例でも、ライブラリ内が名前空間のディレクトリ階層で構成されている例を使って説明する。
アプリ管理フレームワーク３０３はアプリケーション１１ｎのインストールおよびアンインストール、実行と停止を管理するフレームワークであり、たとえばＯＳＧｉなどである。アプリケーション実行環境内へアプリケーション１１ｎをインストールして実行するには、アプリ管理フレームワーク３０３を利用する。管理者がアプリケーション１１ｎをインストールして開始するリクエストをアプリ管理フレームワーク３０３に行うことにより、アプリ管理フレームワーク３０３はアプリインストール処理やアプリ開始処理を行う。その際にアプリ管理フレームワーク３０３はそのアプリケーションのアプリ設定ファイル（例えば図５に示すアプリ設定ファイル５０２）を参照して、そこに宣言されているリソース上限値（例えば図５のリソース上限値５１３）が現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。そして、もしも納まらなければアプリケーションの開始を失敗させる。
以降は本実施例を実施するための特別な構成要素の説明である。
以降は本実施例を実施するための特別な構成要素の説明である。
Ｌｉｂ管理モジュール３０４は、統合ライブラリ３０５を作成するためのモジュールである。Ｌｉｂ管理モジュール３０４は起動モジュール３００から統合ライブラリ作成処理を命令される。Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル（例えば図４の起動オプション設定ファイル４００）の第一のクラスパス（例えば図４のクラスパス４０２）に設定されているライブラリ、およびアプリ設定ファイル（例えば図５のアプリ設定ファイル５０２）の第二のクラスパス（例えば図５のクラスパス５１４）に設定されているライブラリを全て展開（あるいは解凍）する。そして、展開されたクラスを新しい統合ライブラリとしてJARファイル形式で圧縮し直す。Ｌｉｂ管理モジュール３０４は、統合ライブラリを作成した後、起動オプション設定ファイル（例えば図４の起動オプション設定ファイル４００）にある第一のクラスパス（例えば図４のクラスパス４０２）の設定を、新しく作成した統合ライブラリのみになるように変更する。また、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル（例えば図５のアプリ設定ファイル５０２）の第二のクラスパス（例えば図５のクラスパス５１４）に設定されたライブラリの記載を削除する。第一のクラスパス、あるいは第二のクラスパスとして設定されていた複数ライブラリ内のクラス群をまとめた統合ライブラリのみを第一のクラスパスに設定し、クラスローダ３０２は統合ライブラリを見るだけで必要なクラスを探索することができる。
また、Ｌｉｂ管理モジュール３０４は、統合前のライブラリ内に存在するアプリケーション設定ファイル５０２やライブラリ設定ファイル６０１から各ライブラリがクラスローダ３０２を介さずに直接アクセスするファイルを特定する。そして、特定したファイルをアクセスファイルリスト３０６に登録する。また、Ｌｉｂ管理モジュール３０４は、統合ライブラリを作成後にアクセスファイルリスト３０６上に登録されていないライブラリのファイルを削除する。これにより、不要なファイルを削除できるためディスクスペースを節約しつつ、クラスローダ３０２を介さずにファイルアクセスされる場合も正しく動作するようになる。なお、クラスローダ３０２を用いずに直接ライブラリにアクセスする場合にはファイルディスクリプタは消費されない。
統合ライブラリ３０５は、クラスローダ３０２によってロードされるライブラリであり、Ｌｉｂ管理モジュール３０４によって作成される統合ライブラリを含む。統合ライブラリは、前述の通り、第一のクラスパス、あるいは第二のクラスパスに設定されていた複数ライブラリのクラス群をJARファイル形式で圧縮したライブラリである。統合ライブラリに含まれるクラスは、一度クラスローダによってロードされると、アプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、アプリケーション１１ｎから実行することができるようになる。
アクセスファイルリスト３０６は、クラスローダ３０２を介さずに直接アクセスされることのあるファイルを管理するためのテーブルであり、Ｌｉｂ管理モジュール３０４により内容の更新が行われる。
＜起動オプション設定ファイルの例＞
図４は本実施例における起動オプション設定を記載する代表的なファイルの内容について解説した図である。
図４（ａ）は、本実施例におけるＬｉｂ管理モジュール３０４によって変更される前の起動オプション設定ファイル４００を示す図である。起動オプション設定ファイル４００は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更する前の起動オプション設定ファイルである。パス４０１は、アプリケーション実行基盤３０１を起動するための実行ファイルの所在を示す所在情報である。パス４０２は、ライブラリの所在を示す所在情報であり、第一のクラスパスに相当する。ライブラリ４０３は、第一のクラスパスとして設定されている各ライブラリの所在情報である。第一のクラスパス４０２に設定されたライブラリ４０３には、アプリケーション実行基盤３０１や、アプリ管理フレームワーク３０３が、処理を実行するのに必要なクラス群を含んでいる。メインプログラム４０４は、アプリケーション実行基盤３０１がアプリ管理フレームワーク３０３を起動するために必要なメインプログラムの所在情報である。
図４（ｂ）は本実施例におけるＬｉｂ管理モジュール３０４によって変更された後の起動オプション設定ファイル４１０を示す図である。起動オプション設定ファイル４１０は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更した後の起動オプション設定ファイルである。起動オプション設定ファイル４１０は、例えば起動オプション設定ファイル４００を変更して得られる。起動モジュール３００は起動オプション設定ファイル４１０の内容を読み込み、読み込んだ内容をアプリケーション実行基盤３０１の起動オプションとして使用する。統合ライブラリ４１１は、第一のクラスパスとして設定されている統合ライブラリの所在情報である。Ｌｉｂ管理モジュール３０４は統合ライブラリを作成した後、起動オプション設定ファイル４００のクラスパス設定に統合ライブラリのパスを追加し、統合ライブラリ以外のライブラリのパスを第一のクラスパス４０２から削除する。
図４は本実施例における起動オプション設定を記載する代表的なファイルの内容について解説した図である。
図４（ａ）は、本実施例におけるＬｉｂ管理モジュール３０４によって変更される前の起動オプション設定ファイル４００を示す図である。起動オプション設定ファイル４００は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更する前の起動オプション設定ファイルである。パス４０１は、アプリケーション実行基盤３０１を起動するための実行ファイルの所在を示す所在情報である。パス４０２は、ライブラリの所在を示す所在情報であり、第一のクラスパスに相当する。ライブラリ４０３は、第一のクラスパスとして設定されている各ライブラリの所在情報である。第一のクラスパス４０２に設定されたライブラリ４０３には、アプリケーション実行基盤３０１や、アプリ管理フレームワーク３０３が、処理を実行するのに必要なクラス群を含んでいる。メインプログラム４０４は、アプリケーション実行基盤３０１がアプリ管理フレームワーク３０３を起動するために必要なメインプログラムの所在情報である。
図４（ｂ）は本実施例におけるＬｉｂ管理モジュール３０４によって変更された後の起動オプション設定ファイル４１０を示す図である。起動オプション設定ファイル４１０は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更した後の起動オプション設定ファイルである。起動オプション設定ファイル４１０は、例えば起動オプション設定ファイル４００を変更して得られる。起動モジュール３００は起動オプション設定ファイル４１０の内容を読み込み、読み込んだ内容をアプリケーション実行基盤３０１の起動オプションとして使用する。統合ライブラリ４１１は、第一のクラスパスとして設定されている統合ライブラリの所在情報である。Ｌｉｂ管理モジュール３０４は統合ライブラリを作成した後、起動オプション設定ファイル４００のクラスパス設定に統合ライブラリのパスを追加し、統合ライブラリ以外のライブラリのパスを第一のクラスパス４０２から削除する。
＜アプリケーションファイルの例＞
図５（ａ）は本実施例におけるアプリケーション１１ｎを構成する代表的なファイルの内容について解説した図である。アプリケーション１１ｎはいくつかの種類のファイルを抱えている。アプリケーション実行コードファイル５００はアプリケーションの実行コード等を含むファイルである。アプリ内包ライブラリ５０１はアプリケーションの処理を実行するのに必要なライブラリである。アプリケーション１１ｎの処理の実行において、第一のクラスパス４０２に設定されているライブラリ４０３では、特定のクラスが足りず、機能を実現できない場合、開発者はアプリ用のライブラリをアプリ内包ライブラリ５０１として用意する。アプリ設定ファイル５０２は、アプリケーションＩＤ等の基本情報や、アプリケーションが使用するリソースの上限値、第二のクラスパスが記載されているファイルである。アプリ設定ファイル５０２は開発者があらかじめ記載しており、アプリ実行コードファイル５００、アプリ内包ライブラリ５０１と一緒にアプリケーション１１ｎに含めるものである。
図５（ａ）は本実施例におけるアプリケーション１１ｎを構成する代表的なファイルの内容について解説した図である。アプリケーション１１ｎはいくつかの種類のファイルを抱えている。アプリケーション実行コードファイル５００はアプリケーションの実行コード等を含むファイルである。アプリ内包ライブラリ５０１はアプリケーションの処理を実行するのに必要なライブラリである。アプリケーション１１ｎの処理の実行において、第一のクラスパス４０２に設定されているライブラリ４０３では、特定のクラスが足りず、機能を実現できない場合、開発者はアプリ用のライブラリをアプリ内包ライブラリ５０１として用意する。アプリ設定ファイル５０２は、アプリケーションＩＤ等の基本情報や、アプリケーションが使用するリソースの上限値、第二のクラスパスが記載されているファイルである。アプリ設定ファイル５０２は開発者があらかじめ記載しており、アプリ実行コードファイル５００、アプリ内包ライブラリ５０１と一緒にアプリケーション１１ｎに含めるものである。
図５（ｂ）は、Ｌｉｂ管理モジュール３０４によって、第二のクラスパス５１４に設定されたライブラリの記載を削除される前に、アプリ設定ファイル５０２に記載されている項目の例を示す図である。アプリ名５１１は、アプリケーション１１ｎの名称である。アプリ名５１１は画像形成装置１００のユーザインターフェース部２０１等で表示される。アプリケーションＩＤ５１２は、アプリ管理フレームワーク３０３が各アプリケーション１１ｎを一意に識別するために付けられている識別情報である。リソース上限値５１３は、アプリケーション１１ｎが使用するリソースの上限値である。リソース上限値５１３はリソースごとに定義される。開発者はあらかじめアプリケーション１１ｎが使用しうるリソースの上限値を計測しておき、アプリ設定ファイル５０２にリソース上限値５１３として宣言する。アプリ管理フレームワーク３０３はアプリケーション１１ｎをインストールして開始する際に、このリソース上限値５１３を参照する。そして、現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定し、納まればアプリを開始して、もしも納まらなければアプリケーション１１ｎの開始を失敗させる。第二のクラスパス５１４は、アプリケーション１１ｎの処理を実行する時に必要なアプリ実行コードファイル５００やアプリ内包ライブラリ５０１の所在を示す情報である。パス５１５は第二のクラスパスに設定されているアプリ実行コードファイル５００やアプリ内包ライブラリ５０１の所在の情報である。
ダイレクトアクセスファイル設定５１６は、このアプリケーションが直接アクセスを行うライブラリファイルの所在の情報であり、Ｌｉｂ管理モジュール３０４が、クラスローダ３０２を経由せず直接アクセスされることのあるライブラリファイルを管理するために使われる。クラスローダ３０２経由でライブラリ内のファイルを扱う場合、読み出せるファイルがクラスパスの探索順に依存するため、複数のライブラリに同名のファイルが含まれる場合に意図しないファイルを読み出してしまう可能性がある。よってアプリケーションは、確実に意図したファイルを読み出したい場合はクラスローダ３０２を介さずに直接ファイルにアクセスすることがある。ダイレクトアクセスファイル設定５１６はそのようなファイルを管理するために用意される。
図５（ｂ）では説明を簡単にするために、アプリ実行コードファイル５００のパスを相対パスで設定しているが、絶対パスで記載されていても良い。また、一般的には、アプリ内包ライブラリ５０１は第一のクラスパス４０２に設定されていないライブラリなので、第二のクラスパス５１４として所在を示す必要がある。
図５（ｃ）は、Ｌｉｂ管理モジュール３０４によって、第二のクラスパス５１４に設定されたライブラリの記載を削除された後の、アプリ設定ファイル５０２に記載されている項目の例を示す図である。起動モジュール３００が統合ライブラリの作成処理をＬｉｂ管理モジュール３０４に命令すると、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４を参照する。そして、そこに設定されているアプリ内包ライブラリ５０１を展開し、第一のクラスパス４０２に設定されたライブラリ内、およびアプリ内包ライブラリ内のクラスを、統合ライブラリとしてＪＡＲファイル形式で圧縮し直す。その後、Ｌｉｂ管理モジュール３０４は第一のクラスパス４０２を、新しく作成した統合ライブラリのみに変更する。変更により第一のクラスパス４１１が得られる。そして、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４に設定されたライブラリの記載を削除する。アプリ設定ファイル５２０は、第二のクラスパス５１４に設定されたライブラリの記載を削除された後のアプリ設定ファイルである。第二のクラスパス５２１は、アプリ実行コードファイル５００のパスのみ設定されている。パス５２２は第二のクラスパスに設定されているアプリ実行コードファイル５００の所在情報である。パス５１５で設定されていたライブラリは、Ｌｉｂ管理モジュール３０４が統合ライブラリ３０５として起動オプション設定ファイルの第一のクラスパス４１１に設定するため、Ｌｉｂ管理モジュール３０４はアプリ設定ファイルからライブラリの設定を削除する。なお、本実施例では、起動オプション設定ファイルとアプリ設定ファイルとをまとめて設定ファイルと呼ぶことがある。
＜ライブラリ配置の一例＞
図６（ａ）は、本実施例における統合される前のライブラリを構成する代表的なファイルの内容について解説した図である。ライブラリはいくつかの種類のファイルを抱えている。ライブラリ実行コードファイル６００はライブラリの実行コード等を含むファイルである。ライブラリ設定ファイル６０１は、ライブラリ名や直接アクセスするファイル情報が記載されたファイルである。ライブラリ設定ファイル６０１は開発者があらかじめ記載（作成）して、ライブラリ実行コードファイル６００と共にライブラリに含めている。
図６（ｂ）は、ライブラリ設定ファイル６０１の一例である。ライブラリ名称６１１は、ライブラリの名前である。ライブラリバージョン６１２はライブラリのバージョンである。ライブラリ名称６１１やライブラリバージョン６１２は操作部上のバージョン表示する際などに使われる。ダイレクトアクセスファイル設定６１３は、ライブラリが直接アクセスを行うライブラリの所在の情報である。ダイレクトアクセスファイル設定６１３は、Ｌｉｂ管理モジュール３０４から参照され、直接アクセスされることのあるライブラリを管理するための情報として使われる。この設定ファイルの例では、Ｃｏｐｙライブラリのバージョン１．０は、ｌｉｂｓｙｓｔｅｍ００１．ｊａｒおよびｌｉｂｓｙｓｔｅｍ００２．ｊａｒの２ファイルを直接アクセスすることがあることを示している。
図６（ａ）は、本実施例における統合される前のライブラリを構成する代表的なファイルの内容について解説した図である。ライブラリはいくつかの種類のファイルを抱えている。ライブラリ実行コードファイル６００はライブラリの実行コード等を含むファイルである。ライブラリ設定ファイル６０１は、ライブラリ名や直接アクセスするファイル情報が記載されたファイルである。ライブラリ設定ファイル６０１は開発者があらかじめ記載（作成）して、ライブラリ実行コードファイル６００と共にライブラリに含めている。
図６（ｂ）は、ライブラリ設定ファイル６０１の一例である。ライブラリ名称６１１は、ライブラリの名前である。ライブラリバージョン６１２はライブラリのバージョンである。ライブラリ名称６１１やライブラリバージョン６１２は操作部上のバージョン表示する際などに使われる。ダイレクトアクセスファイル設定６１３は、ライブラリが直接アクセスを行うライブラリの所在の情報である。ダイレクトアクセスファイル設定６１３は、Ｌｉｂ管理モジュール３０４から参照され、直接アクセスされることのあるライブラリを管理するための情報として使われる。この設定ファイルの例では、Ｃｏｐｙライブラリのバージョン１．０は、ｌｉｂｓｙｓｔｅｍ００１．ｊａｒおよびｌｉｂｓｙｓｔｅｍ００２．ｊａｒの２ファイルを直接アクセスすることがあることを示している。
＜アクセスファイルリストの一例＞
図７は、Ｌｉｂ管理モジュール３０４が管理するアクセスファイルリスト３０６の一例を示す図である。アクセスファイルリスト３０６は、直接アクセスされるファイルのパスから構成される。Ｌｉｂ管理モジュール３０４は、ライブラリ統合処理を行う際に、アプリ設定ファイル５０２やライブラリ設定ファイルに記載されている、直接アクセスを行うファイルの所在情報から情報を取得してアクセスファイルリスト３０６を作成する。その所在情報には、アプリケーションによるダイレクトアクセスファイルの所在を示すダイレクトアクセスファイル設定５１６と、ライブラリによるダイレクトアクセスファイルの所在を示すダイレクトアクセスファイル設定６１３とを含む。また、Ｌｉｂ管理モジュール３０４は、ライブラリ統合後にライブラリファイルを削除する際に、このアクセスファイルリスト３０６に登録されているファイルを削除しないように制御する。
図７は、Ｌｉｂ管理モジュール３０４が管理するアクセスファイルリスト３０６の一例を示す図である。アクセスファイルリスト３０６は、直接アクセスされるファイルのパスから構成される。Ｌｉｂ管理モジュール３０４は、ライブラリ統合処理を行う際に、アプリ設定ファイル５０２やライブラリ設定ファイルに記載されている、直接アクセスを行うファイルの所在情報から情報を取得してアクセスファイルリスト３０６を作成する。その所在情報には、アプリケーションによるダイレクトアクセスファイルの所在を示すダイレクトアクセスファイル設定５１６と、ライブラリによるダイレクトアクセスファイルの所在を示すダイレクトアクセスファイル設定６１３とを含む。また、Ｌｉｂ管理モジュール３０４は、ライブラリ統合後にライブラリファイルを削除する際に、このアクセスファイルリスト３０６に登録されているファイルを削除しないように制御する。
＜ライブラリ配置の一例＞
図８は、画像形成装置１００内にあるライブラリ配置の一例をツリー状で示した構成図である。フォルダ８０１は、第一のクラスパス４０２に設定されているライブラリを配置するためのフォルダである。このフォルダ８０１にはＬｉｂ管理モジュール３０４が作成した統合ライブラリ８０２と直接アクセスされるライブラリ８０４が配置される。直接アクセスされることがあるライブラリ８０４はアクセスファイルリスト３０６で管理される。直接アクセスされることがないライブラリ（ただし統合ライブラリを除く）はストレージ容量の節約のためライブラリ統合後に削除される。統合ライブラリ８０２は、Ｌｉｂ管理モジュール３０４が作成したライブラリである。Ｌｉｂ管理モジュール３０４は統合ライブラリ８０２を作成した後、このライブラリ８０２を第一のクラスパス４１１に設定する。フォルダ８０３は、画像形成装置１００にインストールされたアプリケーション１１ｎを配置するためのフォルダである。アプリ管理フレームワーク３０３は、アプリケーション１１ｎをインストールする際に、アプリ内包ライブラリ５０１をアプリケーション１１ｎから取り出し、アプリ格納用フォルダ８０３に配置する。その後、画像形成装置起動時にＬｉｂ管理モジュール３０４によりライブラリが統合される。その際、直接アクセスされるライブラリ以外は削除される。図５で示したアプリ設定ファイル５０２の場合、直接アクセスされるファイルであるｌｉｂｐａ１．ｊａｒだけが配置されることになる。
図８は、画像形成装置１００内にあるライブラリ配置の一例をツリー状で示した構成図である。フォルダ８０１は、第一のクラスパス４０２に設定されているライブラリを配置するためのフォルダである。このフォルダ８０１にはＬｉｂ管理モジュール３０４が作成した統合ライブラリ８０２と直接アクセスされるライブラリ８０４が配置される。直接アクセスされることがあるライブラリ８０４はアクセスファイルリスト３０６で管理される。直接アクセスされることがないライブラリ（ただし統合ライブラリを除く）はストレージ容量の節約のためライブラリ統合後に削除される。統合ライブラリ８０２は、Ｌｉｂ管理モジュール３０４が作成したライブラリである。Ｌｉｂ管理モジュール３０４は統合ライブラリ８０２を作成した後、このライブラリ８０２を第一のクラスパス４１１に設定する。フォルダ８０３は、画像形成装置１００にインストールされたアプリケーション１１ｎを配置するためのフォルダである。アプリ管理フレームワーク３０３は、アプリケーション１１ｎをインストールする際に、アプリ内包ライブラリ５０１をアプリケーション１１ｎから取り出し、アプリ格納用フォルダ８０３に配置する。その後、画像形成装置起動時にＬｉｂ管理モジュール３０４によりライブラリが統合される。その際、直接アクセスされるライブラリ以外は削除される。図５で示したアプリ設定ファイル５０２の場合、直接アクセスされるファイルであるｌｉｂｐａ１．ｊａｒだけが配置されることになる。
＜クラスファイルの配置の一例＞
図９は本実施例のライブラリ内にあるクラスファイルの配置の一例をツリー状で示した構成図である。
図９（ａ）は、Ｌｉｂ管理モジュール３０４が、クラスファイルを集めて圧縮するために展開するライブラリ内を示した図である。ライブラリ９０１〜９０４は第一のクラスパス４０２に設定されているライブラリであり、その内に含まれたクラスファイルとそのの配置が示されている。ライブラリ９０５〜９０６は第二のクラスパス５１４に設定されているライブラリであり、その内に含まれたクラスファイルとその配置を示す。
図９（ｂ）は、Ｌｉｂ管理モジュール３０４がライブラリを展開した後、全てのクラスファイルを圧縮して作成した統合ライブラリの内部構造を示した図である。ライブラリ９１０は、第一のクラスパス４１１に設定されている統合ライブラリであり、その内に含まれたクラスファイルの配置を示す。図９（ａ）に記載されているクラスファイルは、統合ライブラリ内に全て配置されているため、クラスローダ３０１はこの統合ライブラリからクラスを探索するだけで、処理の実行に必要なクラスを見つけることが出来る。これによりオープンするライブラリ数が削減できファイルディスクリプタ使用数を抑えることができるようになる。
＜画像形成装置によるアプリケーション関連処理＞
図１０Ａは、ユーザに画像形成装置１００の電源を入れられてから、電源を切られるまでの処理の流れを模式的に表した本実施例におけるフローチャートである。図１０Ａの手順は、コア部２００、特にコア部２００に含まれたプロセッサーにより実行される。この手順は例えばオペレーティングシステムによる開始され、各ソフトウェアモジュールが各ステップで動作する。以下の説明ではソフトウェアが主体であるかのように記述することもあるが、ソフトウェアは仮想的な処理主体であって、実体はソフトウェアを実行するプロセッサー或いはプロセッサコアである。
ユーザが画像形成装置１００の電源を入れるとオペレーティングシステムが動き出し、まず起動モジュール３００を起動して、Ｓ１０１０１で、起動モジュール３００がＬｉｂ管理モジュール３０４に、統合ライブラリの作成処理を命令する。この処理については図１０Ｂを参照して説明する。Ｌｉｂ管理モジュール３０４が統合ライブラリ作成処理を完了すると、Ｓ１０１０２で、起動モジュール３００は、起動オプション設定ファイル４１０の内容を起動オプションとしてアプリケーション実行基盤３０１を起動する。アプリケーション実行基盤３０１が起動すると、メインプログラム４０４の処理が実行されて処理が進んでいく。アプリケーション実行基盤３０１の一部であるクラスローダ３０２は、クラスのロードを監視する。Ｓ１０１０３で、クラスローダ３０２は、クラス生成時にクラスがロードされたか否かを判定する。Ｓ１０１０３で、クラスローダ３０２が、メインプログラムの実行中にアプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、あるいはアプリケーション１１ｎがクラスの生成処理を実行したと判定すると、Ｓ１０１０４に処理が進み、実行しなかった場合はＳ１０１０６に処理が進む。Ｓ１０１０４で、クラスローダ３０２はクラスロード処理を行う。クラスロード処理が終了すると、Ｓ１０１０５で、アプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、あるいはアプリケーション１１ｎがクラスを生成し、Ｓ１０１０６に処理が進む。Ｓ１０１０６で、アプリケーション実行基盤３０１は、メインプログラムの起動後に、ユーザによって画像形成装置１００の電源が切られたか否かを、例えばオペレーティングシステムからの通知などに基づいて判定する。電源が切られたと判定した場合は、アプリケーション実行基盤３０１が画像形成装置１００の電源を切るための処理を行って、画像形成装置１００のシステムは終了する。電源が切られていない場合は、Ｓ１０１０３に戻り、アプリケーション実行基盤３０１はメインプログラムを続けて実行する。
図９は本実施例のライブラリ内にあるクラスファイルの配置の一例をツリー状で示した構成図である。
図９（ａ）は、Ｌｉｂ管理モジュール３０４が、クラスファイルを集めて圧縮するために展開するライブラリ内を示した図である。ライブラリ９０１〜９０４は第一のクラスパス４０２に設定されているライブラリであり、その内に含まれたクラスファイルとそのの配置が示されている。ライブラリ９０５〜９０６は第二のクラスパス５１４に設定されているライブラリであり、その内に含まれたクラスファイルとその配置を示す。
図９（ｂ）は、Ｌｉｂ管理モジュール３０４がライブラリを展開した後、全てのクラスファイルを圧縮して作成した統合ライブラリの内部構造を示した図である。ライブラリ９１０は、第一のクラスパス４１１に設定されている統合ライブラリであり、その内に含まれたクラスファイルの配置を示す。図９（ａ）に記載されているクラスファイルは、統合ライブラリ内に全て配置されているため、クラスローダ３０１はこの統合ライブラリからクラスを探索するだけで、処理の実行に必要なクラスを見つけることが出来る。これによりオープンするライブラリ数が削減できファイルディスクリプタ使用数を抑えることができるようになる。
＜画像形成装置によるアプリケーション関連処理＞
図１０Ａは、ユーザに画像形成装置１００の電源を入れられてから、電源を切られるまでの処理の流れを模式的に表した本実施例におけるフローチャートである。図１０Ａの手順は、コア部２００、特にコア部２００に含まれたプロセッサーにより実行される。この手順は例えばオペレーティングシステムによる開始され、各ソフトウェアモジュールが各ステップで動作する。以下の説明ではソフトウェアが主体であるかのように記述することもあるが、ソフトウェアは仮想的な処理主体であって、実体はソフトウェアを実行するプロセッサー或いはプロセッサコアである。
ユーザが画像形成装置１００の電源を入れるとオペレーティングシステムが動き出し、まず起動モジュール３００を起動して、Ｓ１０１０１で、起動モジュール３００がＬｉｂ管理モジュール３０４に、統合ライブラリの作成処理を命令する。この処理については図１０Ｂを参照して説明する。Ｌｉｂ管理モジュール３０４が統合ライブラリ作成処理を完了すると、Ｓ１０１０２で、起動モジュール３００は、起動オプション設定ファイル４１０の内容を起動オプションとしてアプリケーション実行基盤３０１を起動する。アプリケーション実行基盤３０１が起動すると、メインプログラム４０４の処理が実行されて処理が進んでいく。アプリケーション実行基盤３０１の一部であるクラスローダ３０２は、クラスのロードを監視する。Ｓ１０１０３で、クラスローダ３０２は、クラス生成時にクラスがロードされたか否かを判定する。Ｓ１０１０３で、クラスローダ３０２が、メインプログラムの実行中にアプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、あるいはアプリケーション１１ｎがクラスの生成処理を実行したと判定すると、Ｓ１０１０４に処理が進み、実行しなかった場合はＳ１０１０６に処理が進む。Ｓ１０１０４で、クラスローダ３０２はクラスロード処理を行う。クラスロード処理が終了すると、Ｓ１０１０５で、アプリケーション実行基盤３０１、アプリ管理フレームワーク３０３、あるいはアプリケーション１１ｎがクラスを生成し、Ｓ１０１０６に処理が進む。Ｓ１０１０６で、アプリケーション実行基盤３０１は、メインプログラムの起動後に、ユーザによって画像形成装置１００の電源が切られたか否かを、例えばオペレーティングシステムからの通知などに基づいて判定する。電源が切られたと判定した場合は、アプリケーション実行基盤３０１が画像形成装置１００の電源を切るための処理を行って、画像形成装置１００のシステムは終了する。電源が切られていない場合は、Ｓ１０１０３に戻り、アプリケーション実行基盤３０１はメインプログラムを続けて実行する。
このように、アプリケーション実行基盤３０１は、いったん起動されるとステップＳ１０１０３〜Ｓ１０１０６のループでクラスの生成と電源断とを監視する。そしてクラスが生成されるとクラスをロードし、電源がオフにされると電源オフ処理を行う。
＜統合ライブラリの作成および個別ファイルの削除処理＞
図１０Ｂは、Ｓ１０１０１の詳細フローチャートで、起動モジュール３００に統合ライブラリの作成処理を命令された際のＬＩｂ管理モジュール３０４の処理の流れを示したフローチャートである。
Ｓ１０２０１で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２および第二のクラスパス５１４に複数のライブラリが設定されているかどうかを判定する。設定されているライブラリが１つであると判定した場合は、Ｌｉｂ管理モジュール３０４は統合ライブラリの作成処理を行わずに、処理を終了する。一方、設定されているライブラリが複数あると判定した場合は、Ｓ１０２０２に進む。
Ｓ１０２０２で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２および第二のクラスパス５１４に設定されているライブラリを全て記憶する。これは、第一のクラスパス４０２および第二のクラスパス５１４を変更した後に、変更前のクラスパスの設定情報を参照することが目的であるため、この目的が達成できればメモリ上に記憶しておいても良いし別のファイルに記憶するようにしても良い。クラスパスに設定されているライブラリ情報を記憶したらＳ１０２０３に進む。
Ｓ１０２０３で、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６の情報を作り直すために、アクセスファイルリスト３０６に登録されている情報をクリアする。
図１０Ｂは、Ｓ１０１０１の詳細フローチャートで、起動モジュール３００に統合ライブラリの作成処理を命令された際のＬＩｂ管理モジュール３０４の処理の流れを示したフローチャートである。
Ｓ１０２０１で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２および第二のクラスパス５１４に複数のライブラリが設定されているかどうかを判定する。設定されているライブラリが１つであると判定した場合は、Ｌｉｂ管理モジュール３０４は統合ライブラリの作成処理を行わずに、処理を終了する。一方、設定されているライブラリが複数あると判定した場合は、Ｓ１０２０２に進む。
Ｓ１０２０２で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２および第二のクラスパス５１４に設定されているライブラリを全て記憶する。これは、第一のクラスパス４０２および第二のクラスパス５１４を変更した後に、変更前のクラスパスの設定情報を参照することが目的であるため、この目的が達成できればメモリ上に記憶しておいても良いし別のファイルに記憶するようにしても良い。クラスパスに設定されているライブラリ情報を記憶したらＳ１０２０３に進む。
Ｓ１０２０３で、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６の情報を作り直すために、アクセスファイルリスト３０６に登録されている情報をクリアする。
次にＳ１０２０４で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２に記載されているライブラリおよびインストールされているアプリケーションに対してＳ１０２０７までのループ処理を開始する。
次にＳ１０２０５で、Ｌｉｂ管理モジュール３０４は、設定ファイル６０１もしくは設定ファイル５０２をよみ出し、それぞれの設定ファイル内にダイレクトアクセスファイル設定６１３もしくは５１６がそれぞれ存在するか否かを判定する。もしダイレクトアクセスファイル設定が存在すると判定した場合はＳ１０２０６に進み、存在しないと判定した場合はＳ１０２０７に進む。
Ｓ１０２０６では、Ｌｉｂ管理モジュールは３０４は、ダイレクトアクセスファイル設定６１３の情報をアクセスファイルリスト３０６に追加し、Ｓ１０２０７に進む。
Ｓ１０２０７では、Ｌｉｂ管理モジュール３０４は、全てのライブラリおよびアプリケーションに対してループ処理を実行したかを判定する。全てのライブラリおよびアプリケーションに対してループ処理を実行していない場合はＳ１０２０４に戻り、全てに対してループ処理を実行した場合はＳ１０２０８に進む。
次にＳ１０２０５で、Ｌｉｂ管理モジュール３０４は、設定ファイル６０１もしくは設定ファイル５０２をよみ出し、それぞれの設定ファイル内にダイレクトアクセスファイル設定６１３もしくは５１６がそれぞれ存在するか否かを判定する。もしダイレクトアクセスファイル設定が存在すると判定した場合はＳ１０２０６に進み、存在しないと判定した場合はＳ１０２０７に進む。
Ｓ１０２０６では、Ｌｉｂ管理モジュールは３０４は、ダイレクトアクセスファイル設定６１３の情報をアクセスファイルリスト３０６に追加し、Ｓ１０２０７に進む。
Ｓ１０２０７では、Ｌｉｂ管理モジュール３０４は、全てのライブラリおよびアプリケーションに対してループ処理を実行したかを判定する。全てのライブラリおよびアプリケーションに対してループ処理を実行していない場合はＳ１０２０４に戻り、全てに対してループ処理を実行した場合はＳ１０２０８に進む。
Ｓ１０２０８では、Ｌｉｂ管理モジュール３０４は、ライブラリ統合処理およびクラスパス変更処理を行う。この処理の詳細は図１０Ｃを用いて後述する。Ｌｉｂ管理モジュール３０４はこの処理を終えるとＳ１０２０９に進む。
Ｓ１０２０９では、Ｌｉｂ管理モジュール３０４は、Ｓ１０２０２で記憶したライブラリに対してＳ１０２１２までの処理のループ処理を開始する。
Ｓ１０２１０では、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６に該当するライブラリが登録されているかを判定する。登録されていると判定した場合はＳ１０２１２に進み、登録されていないと判定した場合はＳ１０２１１に進む。
Ｓ１０２１１では、Ｌｉｂ管理モジュール３０４は、該当するライブラリのファイルを削除してＳ１０２１２に進む。
Ｓ１０２１２では、Ｌｉｂ管理モジュール３０４は、Ｓ１０２０２で記憶した全てのライブラリに対して処理を実行したかを判定する。全てのライブラリに対して処理を実行していない場合はＳ１０２０９に戻り、全てに対して処理を実行した場合はループを抜けてＬｉｂ管理モジュールの処理を終了する。
Ｓ１０２１０では、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６に該当するライブラリが登録されているかを判定する。登録されていると判定した場合はＳ１０２１２に進み、登録されていないと判定した場合はＳ１０２１１に進む。
Ｓ１０２１１では、Ｌｉｂ管理モジュール３０４は、該当するライブラリのファイルを削除してＳ１０２１２に進む。
Ｓ１０２１２では、Ｌｉｂ管理モジュール３０４は、Ｓ１０２０２で記憶した全てのライブラリに対して処理を実行したかを判定する。全てのライブラリに対して処理を実行していない場合はＳ１０２０９に戻り、全てに対して処理を実行した場合はループを抜けてＬｉｂ管理モジュールの処理を終了する。
以上の処理によって、起動オプション設定ファイル４００及びアプリ設定ファイル５０２に記述された、起動時及びアプリケーションにより使用されるライブラリを統合することで、ライブラリの数を減らして消費されるファイルディスクリプタなどの資源を減らすことができる。さらに、アプリケーションまたはライブラリにより、Ｌｉｂ管理モジュール３０４を介さずにアクセスされるクラスファイルについては、削除することなく残し、該当しないクラスファイルを削除することで、ストレージやメモリなどの震源の消費を抑制できる。
＜ライブラリ統合処理およびクラスパス変更処理＞
図１０Ｃは、Ｓ１０２０８の詳細フローチャートで、ＬＩｂ管理モジュール３０４がライブラリファイルを統合しクラスパス４０２，５１４を書き換える処理の流れを示したフローチャートである。
Ｓ１０３０１で、Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル４００を読み込んで、第一のクラスパス４０２に設定されているライブラリ４０３を全て展開する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。例えば、図４（ａ）の記載内容の場合、Ｌｉｂ管理モジュール３０４はｌｉｂｓｙｓｔｅｍ００４．ｊａｒ（不図示）、ｌｉｂｓｙｓｔｅｍ００３．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００２．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００１．ｊａｒの順にライブラリを展開する。このように、後に記載されたライブラリから順に展開することで、同じ名前空間に同じクラス名が万が一存在して衝突した場合に、先に展開されたクラスファイルを、後から展開されたクラスファイルすなわち先に記載されたクラスファイルで上書きすることができる。一般的に、同じ名前空間、同じクラス名のものが衝突した場合、クラスパスが先に設定されているクラスファイルをロードする。したがって、クラスの衝突が起きた場合、記載が先にあるライブラリのクラスファイル、すなわち後から展開されるクラスファイルで上書きすることで、本来、一般的な環境でロードされるはずのクラスの方を残すことができる。
次にＳ１０３０２に処理を進め、Ｌｉｂ管理モジュール３０４はインストールされているアプリケーションについて第二のクラスパス５１４に設定されているアプリ内包ライブラリ５０１を全て展開する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。アプリ内包ライブラリ５０１の展開処理が終わったら、Ｓ１０３０３に処理を進める。Ｓ１０３０３で、Ｌｉｂ管理モジュール３０４はＳ１０３０１、およびＳ１０３０２で展開した全てのクラスファイルを統合ライブラリ（ここではｌｉｂｉｎｔｅｇ．ｊａｒとする）として１つのＪＡＲファイル形式に圧縮する。統合ライブラリは、例えば図９（ｂ）に示したように、統合前のライブラリをひとつのツリー構造に統合した構造を持つ。すなわち、ライブラリの統合の前後の、統合前のライブラリにおける相対的なクラスの構成が、統合後のライブラリにおいても維持されるようライブラリが統合される。このクラスファイルは、統合対象となったクラスファイルと同じフォルダに格納されてよい。
そして、Ｓ１０３０４で、Ｌｉｂ管理モジュール３０４はＳ１０３０３で圧縮して作成した統合ライブラリを、第一のクラスパス４０２の設定に追加し、統合ライブラリ以外のライブラリの記載を削除する。これにより、起動オプション設定ファイル４００は、起動オプション設定ファイル４１０のような記載内容にされる。
次にＳ１０３０５に処理を進め、Ｌｉｂ管理モジュール３０４は、第二のクラスパス５１４の設定からライブラリファイルの設定を削除する。これにより、アプリ設定ファイル５０２は、アプリ設定ファイル５２０のような記載内容にされる。第二のクラスパス５１４の設定削除処理が完了したらＳ１０３０６に処理を進める。Ｓ１０３０６で、Ｌｉｂ管理モジュール３０４はＳ１０３０１およびＳ１０３０２で展開したファイルを削除して、ライブラリ統合処理およびクラスパス変更処理を終了する。
図１０Ｃは、Ｓ１０２０８の詳細フローチャートで、ＬＩｂ管理モジュール３０４がライブラリファイルを統合しクラスパス４０２，５１４を書き換える処理の流れを示したフローチャートである。
Ｓ１０３０１で、Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル４００を読み込んで、第一のクラスパス４０２に設定されているライブラリ４０３を全て展開する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。例えば、図４（ａ）の記載内容の場合、Ｌｉｂ管理モジュール３０４はｌｉｂｓｙｓｔｅｍ００４．ｊａｒ（不図示）、ｌｉｂｓｙｓｔｅｍ００３．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００２．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００１．ｊａｒの順にライブラリを展開する。このように、後に記載されたライブラリから順に展開することで、同じ名前空間に同じクラス名が万が一存在して衝突した場合に、先に展開されたクラスファイルを、後から展開されたクラスファイルすなわち先に記載されたクラスファイルで上書きすることができる。一般的に、同じ名前空間、同じクラス名のものが衝突した場合、クラスパスが先に設定されているクラスファイルをロードする。したがって、クラスの衝突が起きた場合、記載が先にあるライブラリのクラスファイル、すなわち後から展開されるクラスファイルで上書きすることで、本来、一般的な環境でロードされるはずのクラスの方を残すことができる。
次にＳ１０３０２に処理を進め、Ｌｉｂ管理モジュール３０４はインストールされているアプリケーションについて第二のクラスパス５１４に設定されているアプリ内包ライブラリ５０１を全て展開する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。アプリ内包ライブラリ５０１の展開処理が終わったら、Ｓ１０３０３に処理を進める。Ｓ１０３０３で、Ｌｉｂ管理モジュール３０４はＳ１０３０１、およびＳ１０３０２で展開した全てのクラスファイルを統合ライブラリ（ここではｌｉｂｉｎｔｅｇ．ｊａｒとする）として１つのＪＡＲファイル形式に圧縮する。統合ライブラリは、例えば図９（ｂ）に示したように、統合前のライブラリをひとつのツリー構造に統合した構造を持つ。すなわち、ライブラリの統合の前後の、統合前のライブラリにおける相対的なクラスの構成が、統合後のライブラリにおいても維持されるようライブラリが統合される。このクラスファイルは、統合対象となったクラスファイルと同じフォルダに格納されてよい。
そして、Ｓ１０３０４で、Ｌｉｂ管理モジュール３０４はＳ１０３０３で圧縮して作成した統合ライブラリを、第一のクラスパス４０２の設定に追加し、統合ライブラリ以外のライブラリの記載を削除する。これにより、起動オプション設定ファイル４００は、起動オプション設定ファイル４１０のような記載内容にされる。
次にＳ１０３０５に処理を進め、Ｌｉｂ管理モジュール３０４は、第二のクラスパス５１４の設定からライブラリファイルの設定を削除する。これにより、アプリ設定ファイル５０２は、アプリ設定ファイル５２０のような記載内容にされる。第二のクラスパス５１４の設定削除処理が完了したらＳ１０３０６に処理を進める。Ｓ１０３０６で、Ｌｉｂ管理モジュール３０４はＳ１０３０１およびＳ１０３０２で展開したファイルを削除して、ライブラリ統合処理およびクラスパス変更処理を終了する。
以上の処理によって、起動オプション設定ファイル４００およびアプリ設定ファイルに記述されたライブラリが統合される。
＜クラス生成時のクラスローダ３０２による処理＞
図１０Ｄは、Ｓ１０１０４の詳細フローチャートで、メインプログラム実行中にクラスが生成された時のクラスローダ３０２の処理の流れを示したフローチャートである。
Ｓ１０４０１でクラスローダ３０２は、実行中のメインプログラムでロードされていないクラスが実行されたか否かを判定する。クラスがロード済みであった場合はクラスロードの処理は終了し、引き続きメインプログラムの処理を進める。ロードされていなかった場合は、Ｓ１０４０２に処理を進める。Ｓ１０４０２でクラスローダは、クラスパスに記載されているライブラリを開いているか否かを判定する。ライブラリが開かれている場合はＳ１０４０４に処理を進め、開かれていない場合はＳ１０４０３に処理を進める。Ｓ１０４０３で、クラスローダ３０２は第一のクラスパス４１１に設定されているライブラリを開く。この時、ファイルを開くのでクラスローダ３０２がファイルディスクリプタを１つ消費する。そしてＳ１０４０４に処理を進める。Ｓ１０４０４で、クラスローダ３０２はライブラリにロードしたいクラスがあるか否かを判定する。ロードしたいクラスが見つかった場合、Ｓ１０４０５で、クラスローダ３０２はライブラリからクラスをロードし、クラスロード処理を終了する。ロードしたいクラスが見つからなかった場合、Ｓ１０４０６でクラスローダ３０２はクラスパスに記載されている全てのライブラリを探索したかを判定する。全てのライブラリを探索していないと判定した場合は、Ｓ１０４０２に戻り、次のライブラリについて判定処理を行う。ただし、本実施例においては全てのライブラリファイルを一つに統合しており、第一のクラスパスには統合ライブラリしか存在しないため、Ｓ１０４０２に処理が戻ることはない。よって、Ｓ１０４０３でのファイルオープン処理も統合ライブラリに対して一回行われるだけになるため、クラスロードに関わるファイルディスクリタ使用数は一つだけになる。すなわち、機能拡張等によりライブラリファイルが増えたとしてもファイルディスクリプタの使用数が増えることはなくなる。
一方、Ｓ１０４０６で全てのライブラリを探索したと判定した場合はＳ１０４０７に進む。Ｓ１０４０７でクラスローダ３０２はクラスが見つからなかったことを示すエラーを返しクラスロード処理を終了する。
なお本実施例では一般的なクラスローダを利用する想定であるため、Ｓ１０４０６の判定が常に同じ結果（全てのライブラリを探索したという判定）になり、無駄な判定処理を行うことになっている。しかし本発明はこの構成に限られることはなく、このＳ１０４０６の判定処理を省略した（すなわちＳ１０４０４からＳ１０４０７に直接処理を進める）特別なクラスローダを利用するようにしても良い。
図１０Ｄは、Ｓ１０１０４の詳細フローチャートで、メインプログラム実行中にクラスが生成された時のクラスローダ３０２の処理の流れを示したフローチャートである。
Ｓ１０４０１でクラスローダ３０２は、実行中のメインプログラムでロードされていないクラスが実行されたか否かを判定する。クラスがロード済みであった場合はクラスロードの処理は終了し、引き続きメインプログラムの処理を進める。ロードされていなかった場合は、Ｓ１０４０２に処理を進める。Ｓ１０４０２でクラスローダは、クラスパスに記載されているライブラリを開いているか否かを判定する。ライブラリが開かれている場合はＳ１０４０４に処理を進め、開かれていない場合はＳ１０４０３に処理を進める。Ｓ１０４０３で、クラスローダ３０２は第一のクラスパス４１１に設定されているライブラリを開く。この時、ファイルを開くのでクラスローダ３０２がファイルディスクリプタを１つ消費する。そしてＳ１０４０４に処理を進める。Ｓ１０４０４で、クラスローダ３０２はライブラリにロードしたいクラスがあるか否かを判定する。ロードしたいクラスが見つかった場合、Ｓ１０４０５で、クラスローダ３０２はライブラリからクラスをロードし、クラスロード処理を終了する。ロードしたいクラスが見つからなかった場合、Ｓ１０４０６でクラスローダ３０２はクラスパスに記載されている全てのライブラリを探索したかを判定する。全てのライブラリを探索していないと判定した場合は、Ｓ１０４０２に戻り、次のライブラリについて判定処理を行う。ただし、本実施例においては全てのライブラリファイルを一つに統合しており、第一のクラスパスには統合ライブラリしか存在しないため、Ｓ１０４０２に処理が戻ることはない。よって、Ｓ１０４０３でのファイルオープン処理も統合ライブラリに対して一回行われるだけになるため、クラスロードに関わるファイルディスクリタ使用数は一つだけになる。すなわち、機能拡張等によりライブラリファイルが増えたとしてもファイルディスクリプタの使用数が増えることはなくなる。
一方、Ｓ１０４０６で全てのライブラリを探索したと判定した場合はＳ１０４０７に進む。Ｓ１０４０７でクラスローダ３０２はクラスが見つからなかったことを示すエラーを返しクラスロード処理を終了する。
なお本実施例では一般的なクラスローダを利用する想定であるため、Ｓ１０４０６の判定が常に同じ結果（全てのライブラリを探索したという判定）になり、無駄な判定処理を行うことになっている。しかし本発明はこの構成に限られることはなく、このＳ１０４０６の判定処理を省略した（すなわちＳ１０４０４からＳ１０４０７に直接処理を進める）特別なクラスローダを利用するようにしても良い。
以上説明したように、本発明の第一の実施例では、アプリケーション実行基盤３０１の起動前、たとえば画像形成装置の起動時に、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成し、その統合ライブラリのみを第一のクラスパス４１１に設定する。その結果、クラスファイルが全て統合ライブラリに含まれるので、アプリケーション実行基盤３０１を起動した後に、クラスローダがクラスを探索する場合、クラスローダ３０２は統合ライブラリ内のみを探索することでクラスを見つけることができる。すなわち、クラスローダ３０２が開くライブラリは１つのみになるので、使用するファイルディスクリプタの数も１つにすることができる。従って、第一のクラスパス４０２に設定されていたライブラリ数や、第二のクラスパス５１４に設定されていたライブラリ数に依らず、クラスローダがライブラリを開くために使用するファイルディスクリプタの数を１つにできる。
また、統合ライブラリを作成した後に統合前のライブラリファイルを削除するような構成とすることでストレージの使用量を抑えることができる。またその際、クラスローダを介さずに直接アクセスされることがあるライブラリファイルを削除せずに残すような構成とした。このため、直接ライブラリファイル内にアクセスするような処理が存在したとしてもエラーを起こすことなく動作することができる。
なお、本実施例では画像形成装置の起動時にＬｉｂ管理モジュールが統合ライブラリの作成処理等を行う構成であったが、このような構成に限定されるものではなく、ファームウェアアップデート時に行うような構成でもよい。
［第二の実施例］
次に本発明の第二の実施例について図を用いて解説する。
第一の実施例では、第一のクラスパス４０２と第二のクラスパス５１４に設定されるライブラリ内の全てのクラスを１つの統合ライブラリとして圧縮した。この構成ではファイルディスクリプタの使用数は大幅に削減できるが、直接アクセスされるライブラリファイルが増えるとストレージの使用量が多くなってしまう。そのためストレージ容量の小さいデバイスでは問題になることがある。第二の実施例では、Ｌｉｂ管理モジュール３０４がライブラリを統合する際に、直接アクセスされることがないライブラリのみを統合して、直接アクセスされるライブラリファイルは個々のライブラリファイルからクラスロードする構成を説明する。
次に本発明の第二の実施例について図を用いて解説する。
第一の実施例では、第一のクラスパス４０２と第二のクラスパス５１４に設定されるライブラリ内の全てのクラスを１つの統合ライブラリとして圧縮した。この構成ではファイルディスクリプタの使用数は大幅に削減できるが、直接アクセスされるライブラリファイルが増えるとストレージの使用量が多くなってしまう。そのためストレージ容量の小さいデバイスでは問題になることがある。第二の実施例では、Ｌｉｂ管理モジュール３０４がライブラリを統合する際に、直接アクセスされることがないライブラリのみを統合して、直接アクセスされるライブラリファイルは個々のライブラリファイルからクラスロードする構成を説明する。
第二の実施例において、図１、図２、図６、図７、図８は、第一の実施例と共通であるため説明を割愛し、差分がある部分のみを以降で説明する。
画像形成装置１００の上でアプリケーションを実行するためのアプリケーション実行環境の構成は図３と同様である。ただし、Ｌｉｂ管理モジュール３０４がライブラリを統合し、クラスパス設定を変更する処理が異なる。具体的には、Ｌｉｂ管理モジュール３０４がライブラリを統合する際に直接アクセスされるライブラリファイルを統合しないように制御する。そのため、直接アクセスされるライブラリ以外のファイルを第一の実施例と同様に削除すると、Ｌｉｂ管理モジュール３０４が処理を行った後の合計のストレージ使用量はライブラリ統合処理を行う前と変わらなくなる。これによりストレージ容量の小さなデバイスでストレージが足りなくなるという状況を回避できるようになる。
＜起動オプション設定ファイルの例＞
図１１は、本実施例におけるＬｉｂ管理モジュール３０４によって変更された後の起動オプション設定ファイル１１００を示す図である。なお、変更される前の起動オプション設定ファイルは実施例１の図４（ａ）と同様である。図１１において、起動オプション設定ファイル１１００は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更した後の起動オプション設定ファイルである。起動モジュール３００は起動オプション設定ファイル４００の内容を読み込み、読み込んだ内容をアプリケーション実行基盤３０１の起動オプションとして使用する。ライブラリ１１０１は、第一のクラスパスとして設定されているライブラリである。Ｌｉｂ管理モジュール３０４は統合ライブラリを作成した後、起動オプション設定ファイル４００のクラスパス設定に統合ライブラリを追加し、アクセスファイルリストに存在しないライブラリを削除する。ここで統合ライブラリはアクセスファイルリストに存在しないライブラリを統合したものであるため、この設定内容で統合前と同等のクラスを利用可能となる。
図１１は、本実施例におけるＬｉｂ管理モジュール３０４によって変更された後の起動オプション設定ファイル１１００を示す図である。なお、変更される前の起動オプション設定ファイルは実施例１の図４（ａ）と同様である。図１１において、起動オプション設定ファイル１１００は、Ｌｉｂ管理モジュール３０４が統合ライブラリを作成して、ファイルの内容を変更した後の起動オプション設定ファイルである。起動モジュール３００は起動オプション設定ファイル４００の内容を読み込み、読み込んだ内容をアプリケーション実行基盤３０１の起動オプションとして使用する。ライブラリ１１０１は、第一のクラスパスとして設定されているライブラリである。Ｌｉｂ管理モジュール３０４は統合ライブラリを作成した後、起動オプション設定ファイル４００のクラスパス設定に統合ライブラリを追加し、アクセスファイルリストに存在しないライブラリを削除する。ここで統合ライブラリはアクセスファイルリストに存在しないライブラリを統合したものであるため、この設定内容で統合前と同等のクラスを利用可能となる。
＜アプリ設定ファイルの例＞
図１２は、第二の実施例においてＬｉｂ管理モジュール３０４によって、第二のクラスパス５１４に設定されたライブラリの記載を削除された後の、アプリ設定ファイルに記載されている項目の例を示す図である。アプリケーション構成やＬｉｂ管理モジュール３０４により削除される前のアプリ設定ファイル５０２は第一の実施例と同様であるため説明を割愛する。
起動モジュール３００が統合ライブラリの作成処理をＬｉｂ管理モジュール３０４に命令すると、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４およびアクセスファイルリストを参照する。そして第二のクラスパスに存在し、アクセスファイルリストに存在しないアプリ内包ライブラリを展開する。その後、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２に設定されたライブラリのうちアクセスファイルリストに存在しないクラスを統合して統合ライブラリとしてＪＡＲファイル形式で圧縮し直す。その後、Ｌｉｂ管理モジュール３０４は第一のクラスパス４０２を、新しく作成した統合ライブラリを追加し、アクセスファイルリストに存在しないライブラリの記述を削除する。そして、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４に設定されたライブラリのうちアクセスファイルリストに存在しないライブラリの記載を削除する。１２００は、第二のクラスパス５１４に設定されたライブラリの記載を削除された後のアプリ設定ファイルである。１２０１は、第二のクラスパスであり、アプリ実行コードファイル５００のパスおよびアクセスファイルリストに存在するライブラリのみの設定が記載される。
図１２は、第二の実施例においてＬｉｂ管理モジュール３０４によって、第二のクラスパス５１４に設定されたライブラリの記載を削除された後の、アプリ設定ファイルに記載されている項目の例を示す図である。アプリケーション構成やＬｉｂ管理モジュール３０４により削除される前のアプリ設定ファイル５０２は第一の実施例と同様であるため説明を割愛する。
起動モジュール３００が統合ライブラリの作成処理をＬｉｂ管理モジュール３０４に命令すると、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４およびアクセスファイルリストを参照する。そして第二のクラスパスに存在し、アクセスファイルリストに存在しないアプリ内包ライブラリを展開する。その後、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２に設定されたライブラリのうちアクセスファイルリストに存在しないクラスを統合して統合ライブラリとしてＪＡＲファイル形式で圧縮し直す。その後、Ｌｉｂ管理モジュール３０４は第一のクラスパス４０２を、新しく作成した統合ライブラリを追加し、アクセスファイルリストに存在しないライブラリの記述を削除する。そして、Ｌｉｂ管理モジュール３０４はアプリ設定ファイル５０２の第二のクラスパス５１４に設定されたライブラリのうちアクセスファイルリストに存在しないライブラリの記載を削除する。１２００は、第二のクラスパス５１４に設定されたライブラリの記載を削除された後のアプリ設定ファイルである。１２０１は、第二のクラスパスであり、アプリ実行コードファイル５００のパスおよびアクセスファイルリストに存在するライブラリのみの設定が記載される。
＜クラスファイルの配置例＞
図１３は第二の実施例のライブラリ内にあるクラスファイルの配置の一例をツリー状で示した構成図である。
図１３（ａ）は、Ｌｉｂ管理モジュール３０４が、クラスファイルを集めて圧縮するために展開するライブラリ内を示した図である。ツリー１３０１〜１３０２は第一のクラスパス４０２に設定されているライブラリの中でアクセスファイルリストに存在しないライブラリ内のクラスファイルの配置である。ツリー１３０３〜１３０４は第二のクラスパス５１４に設定されているライブラリの中でアクセスファイルリストに存在しないライブラリ内のクラスファイルである。
図１３（ｂ）は、Ｌｉｂ管理モジュール３０４がライブラリを展開した後、展開した全てのクラスファイルを圧縮して作成した統合ライブラリ内を示した図である。ツリー１３１０は、第一のクラスパス４１１に設定されている統合ライブラリ内のクラスファイルの配置である。図９（ｂ）と比較すると、アクセスファイルリストに記録されたファイルであるｌｉｂｓｙｓｔｅｍ００１．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００２．ｊａｒのクラスファイルは統合されていない。ライブラリ配置のみに着目すれば、本実施例のものも図８であり、第一実施例と共通である。しかしながら、統合ライブラリには、アクセスファイルリストに記載されたクラスファイルが含まれていない点で第一実施例と相違する。
図１３は第二の実施例のライブラリ内にあるクラスファイルの配置の一例をツリー状で示した構成図である。
図１３（ａ）は、Ｌｉｂ管理モジュール３０４が、クラスファイルを集めて圧縮するために展開するライブラリ内を示した図である。ツリー１３０１〜１３０２は第一のクラスパス４０２に設定されているライブラリの中でアクセスファイルリストに存在しないライブラリ内のクラスファイルの配置である。ツリー１３０３〜１３０４は第二のクラスパス５１４に設定されているライブラリの中でアクセスファイルリストに存在しないライブラリ内のクラスファイルである。
図１３（ｂ）は、Ｌｉｂ管理モジュール３０４がライブラリを展開した後、展開した全てのクラスファイルを圧縮して作成した統合ライブラリ内を示した図である。ツリー１３１０は、第一のクラスパス４１１に設定されている統合ライブラリ内のクラスファイルの配置である。図９（ｂ）と比較すると、アクセスファイルリストに記録されたファイルであるｌｉｂｓｙｓｔｅｍ００１．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００２．ｊａｒのクラスファイルは統合されていない。ライブラリ配置のみに着目すれば、本実施例のものも図８であり、第一実施例と共通である。しかしながら、統合ライブラリには、アクセスファイルリストに記載されたクラスファイルが含まれていない点で第一実施例と相違する。
このように第二の実施例における統合ライブラリは直接アクセスされることのないライブラリだけを統合する構成であるため統合ライブラリのファイルサイズは第一の実施例と比べて小さくなる。また、統合ライブラリに含まれていないライブラリについては、第一のクラスパスおよび第二のクラスパスに、統合していないライブラリの設定を残す構成であるため、処理の実行に必要なクラスが不足することはない。
＜ライブラリ統合処理＞
図１４は、第二の実施例におけるＳ１０２０８の詳細フローチャートで、ＬＩｂ管理モジュール３０４がライブラリファイルを統合し、クラスパス４０２，５１４を書き換える処理の流れを示したフローチャートである。なおＳ１０２０８の時点で、Ｓ１０２０４〜Ｓ１０２０７のループによりアクセスファイルリストは作成済みである。
Ｓ１４１０１で、Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル４００を読み込んで、第一のクラスパス４０２に設定されているライブラリ４０３のうち、アクセスファイルリスト３０６に登録されていないライブラリを展開する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。例えば、第一のクラスパスが図４（ａ）で、アクセスファイルリストが図７の内容である場合、Ｌｉｂ管理モジュール３０４はｌｉｂｓｙｓｔｅｍ００４．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００３．ｊａｒの順にライブラリを展開する。また、ｌｉｂｓｙｓｔｅｍ００１．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００２．ｊａｒはアクセスファイルリストに登録されているため展開しない。次にＳ１４１０２に処理を進める。
Ｓ１４１０２で、Ｌｉｂ管理モジュール３０４は、インストールされているアプリケーションのアプリ設定ファイル５０２を読み込んで、第二のクラスパス５１４に設定されているアプリ内包ライブラリ５０１のうちアクセスファイルリスト３０６に登録されていないライブラリを展開する。この時、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。アプリ内包ライブラリ５０１の展開処理が終わったら、Ｓ１４１０３に処理を進める。Ｓ１４１０３で、Ｌｉｂ管理モジュール３０４はＳ１４１０１、およびＳ１４１０２で展開したクラスファイルを統合ライブラリとして１つのＪＡＲファイル形式に圧縮する。この結果、例えば図１３（ｂ）に示した統合ライブラリ１３１０が生成される。
そして、Ｓ１４１０４で、Ｌｉｂ管理モジュール３０４はＳ１４１０３で圧縮して作成した統合ライブラリを、起動オプション設定ファイル４００の第一のクラスパス４０２の設定に追加し、アクセスファイルリストに登録されていないライブラリファイルの設定を削除する。これにより例えば起動オプション設定ファイル４００を、図１１に示した起動オプション設定ファイル１１００のような記載内容にする。
次にＳ１４１０５に処理を進め、Ｌｉｂ管理モジュール３０４は、アプリ設定ファイル５０２の第二のクラスパス５１４の設定からアクセスファイルリストに登録されていないライブラリファイルの設定を削除する。これにより例えばアプリ設定ファイル５０２を、図１２に示したアプリ設定ファイル１２００のような記載内容にする。第二のクラスパス５１４の設定削除処理が完了したらＳ１４１０６に処理を進める。
Ｓ１４１０６で、Ｌｉｂ管理モジュール３０４はＳ１４１０１およびＳ１４１０２で展開したファイルを削除して、ライブラリ統合処理およびクラスパス変更処理を終了する。
図１４は、第二の実施例におけるＳ１０２０８の詳細フローチャートで、ＬＩｂ管理モジュール３０４がライブラリファイルを統合し、クラスパス４０２，５１４を書き換える処理の流れを示したフローチャートである。なおＳ１０２０８の時点で、Ｓ１０２０４〜Ｓ１０２０７のループによりアクセスファイルリストは作成済みである。
Ｓ１４１０１で、Ｌｉｂ管理モジュール３０４は起動オプション設定ファイル４００を読み込んで、第一のクラスパス４０２に設定されているライブラリ４０３のうち、アクセスファイルリスト３０６に登録されていないライブラリを展開する。この時に、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。例えば、第一のクラスパスが図４（ａ）で、アクセスファイルリストが図７の内容である場合、Ｌｉｂ管理モジュール３０４はｌｉｂｓｙｓｔｅｍ００４．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００３．ｊａｒの順にライブラリを展開する。また、ｌｉｂｓｙｓｔｅｍ００１．ｊａｒ、ｌｉｂｓｙｓｔｅｍ００２．ｊａｒはアクセスファイルリストに登録されているため展開しない。次にＳ１４１０２に処理を進める。
Ｓ１４１０２で、Ｌｉｂ管理モジュール３０４は、インストールされているアプリケーションのアプリ設定ファイル５０２を読み込んで、第二のクラスパス５１４に設定されているアプリ内包ライブラリ５０１のうちアクセスファイルリスト３０６に登録されていないライブラリを展開する。この時、Ｌｉｂ管理モジュール３０４は、記載順が後に記載されているライブラリから順にライブラリの展開を行う。アプリ内包ライブラリ５０１の展開処理が終わったら、Ｓ１４１０３に処理を進める。Ｓ１４１０３で、Ｌｉｂ管理モジュール３０４はＳ１４１０１、およびＳ１４１０２で展開したクラスファイルを統合ライブラリとして１つのＪＡＲファイル形式に圧縮する。この結果、例えば図１３（ｂ）に示した統合ライブラリ１３１０が生成される。
そして、Ｓ１４１０４で、Ｌｉｂ管理モジュール３０４はＳ１４１０３で圧縮して作成した統合ライブラリを、起動オプション設定ファイル４００の第一のクラスパス４０２の設定に追加し、アクセスファイルリストに登録されていないライブラリファイルの設定を削除する。これにより例えば起動オプション設定ファイル４００を、図１１に示した起動オプション設定ファイル１１００のような記載内容にする。
次にＳ１４１０５に処理を進め、Ｌｉｂ管理モジュール３０４は、アプリ設定ファイル５０２の第二のクラスパス５１４の設定からアクセスファイルリストに登録されていないライブラリファイルの設定を削除する。これにより例えばアプリ設定ファイル５０２を、図１２に示したアプリ設定ファイル１２００のような記載内容にする。第二のクラスパス５１４の設定削除処理が完了したらＳ１４１０６に処理を進める。
Ｓ１４１０６で、Ｌｉｂ管理モジュール３０４はＳ１４１０１およびＳ１４１０２で展開したファイルを削除して、ライブラリ統合処理およびクラスパス変更処理を終了する。
以上説明したように、本発明の第二の実施例では、Ｌｉｂ管理モジュール３０４が、クラスパスに設定された各ライブラリを統合する際に、直接アクセスされることがないライブラリだけを対象として統合を行う。そのため、統合ライブラリのファイルサイズは、直接アクセスされるファイルが統合ライブラリと重複しない分だけ第一の実施例と比べて小さくなる。これによりＬｉｂ管理モジュールの処理完了後のストレージ使用量を処理前と同様に抑えることが可能となる。
また、直接アクセスされるライブラリについてはクラスパスに設定を残し、個々のライブラリからクラスをロードする構成とした。そのため、これらのライブラリからクラスローダ３０２がライブラリをオープンする際にはファイルディスクリプタを消費することになり、第一の実施例と比べるとファイルディスクリプタの使用数は多くなる。しかし、統合ライブラリにまとめた分のライブラリの数だけはファイルディスクリプタ使用数を削減できるため、ストレージ容量の小さなデバイスでもストレージ不足を起こすことなくファイルディスクリプタ使用数の削減を達成可能となる。
［第三の実施例］
次に本発明の第三の実施例について図を用いて解説する。第一の実施例は使用するファイルディスクリプタを大幅に削減できる半面、ファイルサイズの大きなライブラリが直接アクセスされる場合にはストレージの使用量が多くなることがあった。一方、第二の実施例はストレージの使用量を抑えることが出来る半面、ファイルサイズの小さな多数のライブラリが直接アクセスされる場合には消費されるファイルディスクリプタを削減できないことがあった。第三の実施例は、状況に応じて第一の実施例の方法か第二の実施例の方法か処理を切り分ける例を説明する。
次に本発明の第三の実施例について図を用いて解説する。第一の実施例は使用するファイルディスクリプタを大幅に削減できる半面、ファイルサイズの大きなライブラリが直接アクセスされる場合にはストレージの使用量が多くなることがあった。一方、第二の実施例はストレージの使用量を抑えることが出来る半面、ファイルサイズの小さな多数のライブラリが直接アクセスされる場合には消費されるファイルディスクリプタを削減できないことがあった。第三の実施例は、状況に応じて第一の実施例の方法か第二の実施例の方法か処理を切り分ける例を説明する。
第三の実施例では図１０Ｂ以外の図に関しては実施例１および実施例２で説明した内容と共通であるため説明を割愛し、差分のみを説明する。図１５は、本実施例における図１０ＡのＳ１０１０１の処理の詳細であり、起動モジュール３００に統合ライブラリの作成処理を命令された際のＬｉｂ管理モジュール３０４の処理の流れを示したフローチャートである。すなわち、本実施形態においては、第一の実施例における図１０Ｂに代わって図１５が実行される。
Ｓ１５１０１で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２および第二のクラスパス５１４に複数のライブラリが設定されているかどうかを判定する。設定されているライブラリが１つであると判定した場合は、Ｌｉｂ管理モジュール３０４は統合ライブラリの作成処理を行わずに、処理を終了する。一方、設定されているライブラリが複数あると判定した場合は、Ｓ１５１０２に進む。
Ｓ１５１０２で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２および第二のクラスパス５１４に設定されているライブラリを全て記憶する。これは、第一のクラスパス４０２および第二のクラスパス５１４を変更した後に、変更前のクラスパスの設定情報を参照することが目的であるため、この目的が達成できればメモリ上に記憶しておいても良いし別のファイルに記憶するようにしても良い。クラスパスに設定されているライブラリ情報を記憶したらＳ１５１０３に進む。
Ｓ１５１０３で、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６の情報を作り直すために、アクセスファイルリスト３０６に登録されている情報をクリアする。
次にＳ１５１０４で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２に記載されているライブラリおよびインストールされているアプリケーションに対してＳ１５１０７までのループ処理を開始する。
次にＳ１５１０５で、Ｌｉｂ管理モジュール３０４は、設定ファイル６０１もしくは設定ファイル５０２をよみ出し、それぞれの設定ファイル内にダイレクトアクセスファイル設定６１３もしくは５１６がそれぞれ存在するか否かを判定する。もしダイレクトアクセスファイル設定が存在すると判定した場合はＳ１５１０６に進み、存在しないと判定した場合はＳ１５１０７に進む。
Ｓ１５１０６では、Ｌｉｂ管理モジュールは３０４は、ダイレクトアクセスファイル設定６１３の情報をアクセスファイルリスト３０６に追加し、Ｓ１５１０７に進む。
Ｓ１５１０７では、Ｌｉｂ管理モジュール３０４は、全てのライブラリおよびアプリケーションに対してループ処理を実行したかを判定する。全てのライブラリおよびアプリケーションに対してループ処理を実行していない場合はＳ１５１０４に戻り、全てに対してループ処理を実行した場合はＳ１５１０８に進む。
Ｓ１５１０８では、Ｌｉｂ管理モジュール３０４は、アクセスファイルリストに登録されているライブラリファイルのファイルサイズの合計を算出し、Ｓ１５１０９に進む
Ｓ１５１０９では、Ｌｉｂ管理モジュール３０４は、Ｓ１５１０８で算出したファイルサイズの合計が所定サイズ以上かどうかを判定する。Ｓ１５１０９において所定サイズ以上であると判定した場合はＳ１５１１１に進み、所定サイズ未満であると判定した場合はＳ１５１１０に進む。ここでは説明を簡単にするために、固定的な閾値で比較するようなフローチャートになっているが、例えば、画像形成装置の空き容量を取得して動的に閾値を決定しても構わない。
Ｓ１５１１０では、Ｌｉｂ管理モジュール３０４は、図１０Ｃの処理によりライブラリ統合処理およびクラスパス変更処理を行い、Ｓ１５１１２に進む。すなわち、第一実施例のように、起動オプション設定ファイル４００及びアプリ設定ファイル５０２に記述されたライブラリを統合する。
Ｓ１５１１１では、Ｌｉｂ管理モジュール３０４は、図１４の処理によりライブラリ統合処理およびクラスパス変更処理を行い、Ｓ１５１１２に進む。すなわち、第二実施例のように、起動オプション設定ファイル４００及びアプリ設定ファイル５０２に記述されたライブラリのうち、直接アクセスされないものを統合する。
Ｓ１５１１２では、Ｌｉｂ管理モジュール３０４は、Ｓ１５１０２で記憶したライブラリに対してＳ１５１１５までの処理のループ処理を開始する。
Ｓ１５１１３では、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６に該当するライブラリが登録されているかを判定する。登録されていると判定した場合はＳ１５１１５に進み、登録されていないと判定した場合はＳ１５１１４に進む。
Ｓ１５１１４では、Ｌｉｂ管理モジュール３０４は、該当するライブラリのファイルを削除してＳ１５１１５に進む。
Ｓ１５１１５では、Ｌｉｂ管理モジュール３０４は、Ｓ１５１０２で記憶した全てのライブラリに対して処理を実行したかを判定する。全てのライブラリに対して処理を実行していない場合はＳ１５１１２に戻り、全てに対して処理を実行した場合はループを抜けてＬｉｂ管理モジュールの処理を終了する。
Ｓ１５１０２で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２および第二のクラスパス５１４に設定されているライブラリを全て記憶する。これは、第一のクラスパス４０２および第二のクラスパス５１４を変更した後に、変更前のクラスパスの設定情報を参照することが目的であるため、この目的が達成できればメモリ上に記憶しておいても良いし別のファイルに記憶するようにしても良い。クラスパスに設定されているライブラリ情報を記憶したらＳ１５１０３に進む。
Ｓ１５１０３で、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６の情報を作り直すために、アクセスファイルリスト３０６に登録されている情報をクリアする。
次にＳ１５１０４で、Ｌｉｂ管理モジュール３０４は、第一のクラスパス４０２に記載されているライブラリおよびインストールされているアプリケーションに対してＳ１５１０７までのループ処理を開始する。
次にＳ１５１０５で、Ｌｉｂ管理モジュール３０４は、設定ファイル６０１もしくは設定ファイル５０２をよみ出し、それぞれの設定ファイル内にダイレクトアクセスファイル設定６１３もしくは５１６がそれぞれ存在するか否かを判定する。もしダイレクトアクセスファイル設定が存在すると判定した場合はＳ１５１０６に進み、存在しないと判定した場合はＳ１５１０７に進む。
Ｓ１５１０６では、Ｌｉｂ管理モジュールは３０４は、ダイレクトアクセスファイル設定６１３の情報をアクセスファイルリスト３０６に追加し、Ｓ１５１０７に進む。
Ｓ１５１０７では、Ｌｉｂ管理モジュール３０４は、全てのライブラリおよびアプリケーションに対してループ処理を実行したかを判定する。全てのライブラリおよびアプリケーションに対してループ処理を実行していない場合はＳ１５１０４に戻り、全てに対してループ処理を実行した場合はＳ１５１０８に進む。
Ｓ１５１０８では、Ｌｉｂ管理モジュール３０４は、アクセスファイルリストに登録されているライブラリファイルのファイルサイズの合計を算出し、Ｓ１５１０９に進む
Ｓ１５１０９では、Ｌｉｂ管理モジュール３０４は、Ｓ１５１０８で算出したファイルサイズの合計が所定サイズ以上かどうかを判定する。Ｓ１５１０９において所定サイズ以上であると判定した場合はＳ１５１１１に進み、所定サイズ未満であると判定した場合はＳ１５１１０に進む。ここでは説明を簡単にするために、固定的な閾値で比較するようなフローチャートになっているが、例えば、画像形成装置の空き容量を取得して動的に閾値を決定しても構わない。
Ｓ１５１１０では、Ｌｉｂ管理モジュール３０４は、図１０Ｃの処理によりライブラリ統合処理およびクラスパス変更処理を行い、Ｓ１５１１２に進む。すなわち、第一実施例のように、起動オプション設定ファイル４００及びアプリ設定ファイル５０２に記述されたライブラリを統合する。
Ｓ１５１１１では、Ｌｉｂ管理モジュール３０４は、図１４の処理によりライブラリ統合処理およびクラスパス変更処理を行い、Ｓ１５１１２に進む。すなわち、第二実施例のように、起動オプション設定ファイル４００及びアプリ設定ファイル５０２に記述されたライブラリのうち、直接アクセスされないものを統合する。
Ｓ１５１１２では、Ｌｉｂ管理モジュール３０４は、Ｓ１５１０２で記憶したライブラリに対してＳ１５１１５までの処理のループ処理を開始する。
Ｓ１５１１３では、Ｌｉｂ管理モジュール３０４は、アクセスファイルリスト３０６に該当するライブラリが登録されているかを判定する。登録されていると判定した場合はＳ１５１１５に進み、登録されていないと判定した場合はＳ１５１１４に進む。
Ｓ１５１１４では、Ｌｉｂ管理モジュール３０４は、該当するライブラリのファイルを削除してＳ１５１１５に進む。
Ｓ１５１１５では、Ｌｉｂ管理モジュール３０４は、Ｓ１５１０２で記憶した全てのライブラリに対して処理を実行したかを判定する。全てのライブラリに対して処理を実行していない場合はＳ１５１１２に戻り、全てに対して処理を実行した場合はループを抜けてＬｉｂ管理モジュールの処理を終了する。
以上説明したように、本発明の第三の実施例では、直接アクセスされることのあるライブラリのファイルサイズ合計に応じてライブラリ統合およびクラスパス変更の処理内容を切り替える構成とした。これにより、直接アクセスされるライブラリの合計ファイルサイズが閾値以下の状況では第一実施例の方式が採られるため、ファイルディスクリプタ使用数は最小に抑えつつストレージ使用量も抑えることができるようになる。また、直接アクセスされるライブラリの合計ファイルサイズが閾値よりも大きい状況では第二実施例の方式が採られるため、ストレージ使用量を最低限に抑えつつファイルディスクリプタの使用量も抑えることができるようになる。このようにストレージ容量の状況に応じて適切な方法が採られるようになるため、ストレージ容量が小さなデバイスについてもファイルディスクリプタの使用数の削減を行いやすくなる。
［変形例］
第三の実施例では、Ｓ１５１０９において、直接アクセスされるライブラリの合計ファイルサイズと閾値とを比較し、その結果に応じて、直接アクセスされるライブラリを統合するか否かを決定している。それに対して、ファイルディスクリプタか、或いはストレージか、いずれの消費量の抑制を優先するか例えば管理者に指定させ、その指定に応じて判定の基準を変更してもよい。この場合には図１５のＳ１５１０８は不要であり、Ｓ１５１０９において優先する資源を判定し、ファイルディスクリプタを優先するのであればＳ１５１１０に分岐し、そうでなければ、すなわちストレージ容量を優先するであればＳ１５１１１に分岐する。
第三の実施例では、Ｓ１５１０９において、直接アクセスされるライブラリの合計ファイルサイズと閾値とを比較し、その結果に応じて、直接アクセスされるライブラリを統合するか否かを決定している。それに対して、ファイルディスクリプタか、或いはストレージか、いずれの消費量の抑制を優先するか例えば管理者に指定させ、その指定に応じて判定の基準を変更してもよい。この場合には図１５のＳ１５１０８は不要であり、Ｓ１５１０９において優先する資源を判定し、ファイルディスクリプタを優先するのであればＳ１５１１０に分岐し、そうでなければ、すなわちストレージ容量を優先するであればＳ１５１１１に分岐する。
あるいはまた、アクセスファイルリストに記載されたファイルの数と所定の閾値（たとえばファイルディスクリプタの上限値から統合ライブラリの数である１を減じた値）とをＳ１５１０９で比較し、その結果に応じて分岐させてもよい。たとえばアクセスファイルリストに記載されたファイルの数が閾値以下であればＳ１５１１１に分岐し、閾値を超えていればＳ１５１１０に分岐してもよい。また、アクセスファイルリストに記載されたファイルの数が閾値を超えている場合には、アクセスファイルリストに記載されたファイルの一部を統合ライブラリとして統合し、残りを統合しないようにしてもよい。こうすることで、ファイルディスクリプタの消費量を抑制と、ストレージの消費の抑制とを両立できる。
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
１００ 画像形成装置、１０１ 情報処理装置、１２０ ネットワーク、３００ 起動モジュール、３０２ クラスローダ、３０３ アプリケーション管理フレームワーク、３０４ Ｌｉｂ管理モジュール、３０６ アクセスファイルリスト
Claims (17)
- インストールされたプログラムを実行する際に、前記プログラムで用いられるクラスを含むライブラリを開いて当該クラスをロードするロード手段であって、開いたライブラリの数に応じた量のリソースを消費する前記ロード手段と、
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定手段と、
前記ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数の統合ライブラリに統合する統合手段と、
前記統合ライブラリに含まれたクラスを含む統合前の前記ライブラリを、前記ロード手段を介さずにアクセスされるライブラリを除いて削除する削除手段と
を有することを特徴とする情報処理装置。 - 前記統合手段は、前記ライブラリに含まれたクラスのすべてを前記統合ライブラリに統合することを特徴とする請求項１に記載の情報処理装置。
- 前記統合手段は、前記ライブラリのうち、前記ロード手段を用いることなくアクセスされるライブラリを除いたライブラリに含まれたクラスを前記統合ライブラリに統合することを特徴とする請求項１に記載の情報処理装置。
- 前記統合手段は、前記ロード手段を用いることなくアクセスされる前記ライブラリを合計したストレージ容量が所定の閾値よりも大きい場合には、前記ライブラリのうち、前記ロード手段を用いることなくアクセスされるライブラリを除いたライブラリに含まれたクラスを前記統合ライブラリに統合し、所定の閾値以下の場合には、前記ライブラリに含まれたクラスのすべてを前記統合ライブラリに統合することを特徴とする請求項１に記載の情報処理装置。
- 前記統合手段は、前記ロード手段を用いることなくアクセスされる前記ライブラリの数が所定の閾値以下の場合には、前記ライブラリのうち、前記ロード手段を用いることなくアクセスされるライブラリを除いたライブラリに含まれたクラスを前記統合ライブラリに統合し、所定の閾値より大きい場合には、前記ライブラリに含まれたクラスのすべてを前記統合ライブラリに統合することを特徴とする請求項１に記載の情報処理装置。
- 前記ライブラリは１つ以上のクラスを圧縮したファイルであり、
前記統合手段は、前記判定手段でライブラリの数が複数であると判定された場合に、前記ライブラリを展開し、前記ライブラリの数より少ない数のライブラリに圧縮して統合することを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。 - 前記統合手段は、前記情報処理装置が起動された際に、前記ライブラリを統合することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
- 前記統合手段は、前記プログラムとしてアプリケーションがインストールされた際に、前記ライブラリを統合することを特徴とする請求項１乃至７のいずれか一項に記載の情報処理装置。
- 前記判定手段は、前記インストールされたプログラムの設定ファイルに記述された、クラスの所在を示すクラスパスを参照して、前記プログラムについて設定されたクラスを含むライブラリを特定することを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
- 前記統合手段は、前記ライブラリに含まれたクラスを１つのライブラリに統合することを特徴とする請求項１乃至９のいずれか一項に記載の情報処理装置。
- 前記統合手段は、統合されるクラスを含むライブラリを生成することで、前記ライブラリを統合することを特徴とする請求項１乃至１０のいずれか一項に記載の情報処理装置。
- 前記統合手段は、ライブラリの統合の前後の、統合前のライブラリにおける相対的なクラスの構成を、統合後のライブラリにおいても維持するよう前記ライブラリを統合することを特徴とする請求項１乃至１１のいずれか一項に記載の情報処理装置。
- 前記リソースにはファイルディスクリプタが含まれることを特徴とする請求項１乃至１２のいずれか一項に記載の情報処理装置。
- インストールされたプログラムを実行する際に、前記プログラムで用いられるクラスを含むライブラリを開いて当該クラスをロードするロード手段であって、開いたライブラリの数に応じた量のリソースを消費する前記ロード手段を有する情報処理装置によるライブラリ管理方法であって、
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定工程と、
前記ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数の統合ライブラリに統合する統合工程と、
前記統合ライブラリに含まれたクラスを含む統合前の前記ライブラリを、前記ロード手段を介さずにアクセスされるライブラリを除いて削除する削除工程と
を有することを特徴とするライブラリ管理方法。 - 前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
前記統合工程は、前記判定工程でライブラリの数が複数であると判定された場合に、前記ライブラリを展開し、前記ライブラリの数より少ない数のライブラリに圧縮して統合することを特徴とする請求項１４に記載のライブラリ管理方法。 - コンピューターを、
インストールされたプログラムを実行する際に、前記プログラムで用いられるクラスを含むライブラリを開いて当該クラスをロードするロード手段であって、開いたライブラリの数に応じた量のリソースを消費する前記ロード手段と、
インストールされたプログラムについて設定されたクラスを含むライブラリの数が複数であるか判定する判定手段と、
前記ライブラリの数が複数であると判定された場合には、前記ライブラリに含まれたクラスを、前記ライブラリの数より少ない数の統合ライブラリに統合する統合手段と、
前記統合ライブラリに含まれたクラスを含む統合前の前記ライブラリを、前記ロード手段を介さずにアクセスされるライブラリを除いて削除する削除手段と
して機能させるためのプログラム。 - 前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
前記統合手段は、前記判定手段でライブラリの数が複数であると判定された場合に、前記ライブラリを展開し、前記ライブラリの数より少ない数のライブラリに圧縮して統合することを特徴とする請求項１６に記載のプログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016041492A JP2017157103A (ja) | 2016-03-03 | 2016-03-03 | 情報処理装置およびライブラリ管理方法 |
| CN201710089661.XA CN107153554B (zh) | 2016-03-03 | 2017-02-20 | 信息处理装置和库管理方法 |
| US15/444,555 US10387168B2 (en) | 2016-03-03 | 2017-02-28 | Information processing apparatus and library management method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016041492A JP2017157103A (ja) | 2016-03-03 | 2016-03-03 | 情報処理装置およびライブラリ管理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2017157103A true JP2017157103A (ja) | 2017-09-07 |
Family
ID=59724105
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016041492A Pending JP2017157103A (ja) | 2016-03-03 | 2016-03-03 | 情報処理装置およびライブラリ管理方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US10387168B2 (ja) |
| JP (1) | JP2017157103A (ja) |
| CN (1) | CN107153554B (ja) |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7426048B2 (en) | 2002-01-21 | 2008-09-16 | Canon Kabushiki Kaisha | Image forming apparatus, controlling method, and control program |
| US7539579B2 (en) * | 2002-04-09 | 2009-05-26 | Beattie Kenneth L | Oligonucleotide probes for genosensor chips |
| US7150003B2 (en) * | 2002-11-25 | 2006-12-12 | Matsushita Electric Industrial Co., Ltd. | Class coalescence for obfuscation of object-oriented software |
| JP4168962B2 (ja) | 2004-03-31 | 2008-10-22 | 日本電気株式会社 | Ｊａｖａクラスパスの最適化方式 |
| US20080154897A1 (en) * | 2006-11-20 | 2008-06-26 | Siemens Medical Solution Usa, Inc. | Automated Interpretation and Replacement of Date References in Unstructured Text |
| CN100478897C (zh) * | 2007-12-04 | 2009-04-15 | 腾讯科技（深圳）有限公司 | 实现在游戏运行过程中自动验证支付的方法、装置和系统 |
| US8875115B2 (en) * | 2008-11-29 | 2014-10-28 | International Business Machines Corporation | Type merging technique to reduce class loading during Java verification |
| JP6409514B2 (ja) * | 2014-11-10 | 2018-10-24 | 日本電気株式会社 | 情報処理装置およびライブラリロード方法、並びにコンピュータ・プログラム |
| JP6518087B2 (ja) | 2015-03-09 | 2019-05-22 | キヤノン株式会社 | プログラム処理装置 |
| US11225689B2 (en) * | 2016-08-17 | 2022-01-18 | The Broad Institute, Inc. | Method for determination and identification of cell signatures and cell markers |
-
2016
- 2016-03-03 JP JP2016041492A patent/JP2017157103A/ja active Pending
-
2017
- 2017-02-20 CN CN201710089661.XA patent/CN107153554B/zh active Active
- 2017-02-28 US US15/444,555 patent/US10387168B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN107153554A (zh) | 2017-09-12 |
| US20170255480A1 (en) | 2017-09-07 |
| CN107153554B (zh) | 2021-03-30 |
| US10387168B2 (en) | 2019-08-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106227579B (zh) | 一种Docker容器构建方法及Docker管理控制台 | |
| US8752039B1 (en) | Dynamic upgrade of operating system in a network device | |
| US8112745B2 (en) | Apparatus and method for capabilities verification and restriction of managed applications in an execution environment | |
| US8285978B2 (en) | Storage medium storing master boot record, computer system having the same and booting method of the computer system | |
| US20150012732A1 (en) | Method and device for recombining runtime instruction | |
| WO2011066261A1 (en) | Fast restart on a virtual machine | |
| US9086938B2 (en) | Information processing apparatus, control method thereof, and storage medium | |
| CN114270315A (zh) | 应用的水合 | |
| KR102090977B1 (ko) | 정보 처리장치 및 리소스 관리방법 | |
| JP2017157103A (ja) | 情報処理装置およびライブラリ管理方法 | |
| JP2016051395A (ja) | 画像形成装置およびリソース管理方法 | |
| JP5428455B2 (ja) | 仮想マシンサーバ、仮想マシン制御方法及び仮想マシン制御プログラム | |
| CN113924548A (zh) | 特征文件批的自动水合 | |
| JP2012141887A (ja) | 情報処理装置、情報処理方法、及びプログラム | |
| JP2008059482A (ja) | 情報処理装置、情報処理方法 | |
| JP2017157175A (ja) | 情報処理装置及びライブラリ管理方法 | |
| US11586723B2 (en) | Information processing apparatus, control method for information processing apparatus, and storage medium | |
| CN117707551A (zh) | 一种目标软件包的安装方法及装置 | |
| CN113986284A (zh) | 系统应用的升级方法、装置、存储介质及电子设备 | |
| JP2003256219A (ja) | 組込み機器におけるプログラム実行方法 | |
| CN115857968A (zh) | 操作系统安装方法及装置 | |
| JP2021184208A (ja) | 情報処理装置、情報処理方法、及びプログラム | |
| CN116302349A (zh) | 加快Java应用程序启动速度的方法及其相关组件 | |
| JP2019152911A (ja) | 情報処理装置、情報処理方法およびコンピュータプログラム | |
| JP2009301472A (ja) | 情報端末、アプリケーション管理システム、端末アプリケーション管理方法及びアプリケーション管理方法 |