JP2007206965A - 情報処理装置及び当該装置におけるオブジェクト指向プログラムの実行方法とそのプログラム - Google Patents

Abstract

【課題】 クラスをロードするライブラリを決定する際、アプリケーションに同梱されてきたライブラリよりシステム内部にあるライブラリを優先するため、システムライブラリが更新されると、アプリケーションの安定動作が損なわれる危険性があった。
【解決手段】 アプリケーションの実行時、要求されるクラスをロードする際、その要求されたクラスが所定の条件を満たすかどうかを判定し、所定の条件を満たす場合は、アプリケーションが提供するクラスライブラリ１０８からのクラスをロードし、それ以外の場合には、装置が記録しているシステムライブラリ１０４からクラスをロードする。
【選択図】 図１

Description

本発明は、オブジェクト指向言語で作成されたプログラムをロードして実行する情報処理及び当該装置におけるオブジェクト指向プログラムの実行方法とそのプログラムに関するものである。

アプリケーションプログラムを実行する装置において、実行しようとしている機能のプログラムがロードされていない場合、その機能を実装したプログラムを外部からロードし、そのプログラムを実行することによって機能を実現する装置が存在する。

ＪａｖａＶＭ（Java Virtual Machine：Ｊａｖａ仮想マシン）（Javaは米国Sun Microsystems Inc.の米国及びその他の国における商標又は登録商標である）を備えた装置はその一例である。このＪａｖａＶＭを備えた装置では、Ｊａｖａアプリケーションを実行するとき、必要とするクラスを装置内、或は装置外に存在するクラスライブラリからロード（クラスロード）することができる。このＪａｖａＶＭ内の、クラスロードに関わる部分はクラスローダと呼ばれる。クラスローダがどこからクラスをロードするかは、クラスパスの設定及びクラスローダ自体の振る舞いによって決定される。

まず、使用するクラスローダを指定しない時は、ＪａｖａＶＭに内蔵されるシステムクラスローダが使われる。このシステムクラスローダは、クラスパスの設定に従ってクラスをロードする。このクラスパスには、クラスをロードしてくる場所（パス）が１乃至複数個列挙される。これらパスの列挙順位が上位にあるパスから優先してシステムクラスローダはクラスの検索を実行する。また、使用するクラスローダを指定することもでき、その場合は、指定されたクラスローダの定義に従ってクラスの検索及びロードを行う。

クラスローダがクラスをロードする際、ロードしようとしているクラスがＪａｖａＶＭ内或はＪａｖａＶＭと共に提供されているライブラリ内（以下、Ｊａｖａシステムと呼ぶ）に存在するかどうかを最初に確認する。そしてもし、そのクラスがＪａｖａシステム内に存在すればそこからロードする。つまり、必要とするクラスがアプリケーションと共に外部にあることが分かっていたとしても、Ｊａｖａシステム内からのロードを優先する。これは必要な動作である。その理由は、第一に、Ｊａｖａシステム内のクラスはＪａｖａ機能の提供を保証しているため、それが保証されていない第三者によって作成されたクラスを使うことはＪａｖａ機能の互換性を保てない虞がある。第二に、Ｊａｖａシステム内のクラスは、Ｊａｖａシステム内のクラスセキュリティが考慮された堅牢なクラスであるのに対し、第三者によって作成されたクラスを使うことは、セキュリティの欠如に繋がる虞がある。

このクラスローディングに係る従来技術として、以下に示す特許文献が挙げられる。
特開平１０−９１４４６号公報 特公表２００３−５０４７５４号公報

しかしながら、上記従来の技術には以下のような課題が存在する。

即ち、アプリケーションと共に提供されてきたクラスライブラリを、ある時点からＪａｖａシステム内に置くようにした場合、上記従来技術を用いると、Ｊａｖａシステム内に置かれたクラスライブラリの方が使用されるようになる。これにより、これ以降、アプリケーションにクラスライブラリを同梱する必要がなくなる。通常、これは望ましい動作である。しかし、アプリケーションに同梱されたクラスライブラリと、Ｊａｖａシステム内のクラスライブラリのバージョンが異なる場合は、以下のような問題が生じる。

アプリケーションに同梱されたクラスライブラリは、そのアプリケーションと共に動作することが保証されている。しかし、これと異なるバージョンであるＪａｖａシステム内のクラスライブラリを使用しようとすると、共に動作することが保証されているわけではないので障害が発生する可能性がある。このような事態は、例えば、古いクラスライブラリが同梱された既存のアプリケーションを、新しいクラスライブラリを備えた新しいＪａｖａシステムにインストールする場合に生じる。このような場合、障害が発生しないように、既存のアプリケーションを変更するのは手間である。また、アプリケーションに同梱されたクラスを必ず使うという方法も、セキュリティの観点から望ましくない。

本発明の目的は上記従来技術の問題点を解決することにある。

本願発明の特徴は、要求されるクラスに応じて、アプリケーションが提供するクラス、或は装置が記憶しているクラスを使用できるようにして、オブジェクト指向プログラムのセキュリティの維持及び安定動作を保証する技術を提供することにある。

上記目的を達成するために本発明の一態様に係る情報処理装置は以下のような構成を備える。即ち、
オブジェクト指向プログラムを実行する情報処理装置であって、
ライブラリクラスを蓄積するクラス蓄積手段と、
実行中のアプリケーションで使用されるクラスが、予め定められた条件を満たすか否かを判定する判定手段と、
前記判定手段により前記条件を満たすと判定されると、前記アプリケーションが提供するクラスライブラリから前記使用されるクラスをロードし、前記条件を満たさないと判定した場合には、前記クラス蓄積手段から、対応するクラスをロードするように制御するロード制御手段と、を有することを特徴とする。

上記目的を達成するために本発明の一態様に係る情報処理装置におけるオブジェクト指向プログラムの実行方法は以下のような工程を備える。即ち、
オブジェクト指向プログラムを実行する情報処理装置におけるオブジェクト指向プログラムの実行方法であって、
実行中のアプリケーションで使用されるクラスが、予め定められた条件を満たすか否かを判定する判定工程と、
前記判定工程で前記条件を満たすと判定されると、前記アプリケーションが提供するクラスライブラリから前記使用されるクラスをロードし、前記条件を満たさないと判定した場合には、クラスライブラリを蓄積するシステムライブラリから、対応するクラスをロードするように制御するロード制御工程と、
を有することを特徴とする。

尚、この課題を解決するための手段は、本願発明の特徴の全てを列挙しているものではなく、特許請求の範囲に記載された他の請求項及びそれら特徴群の組み合わせも発明になり得る。

本発明によれば、オブジェクト指向プログラムのアプリケーションの実行時のセキュリティ維持及び、安定動作が保証できる。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

図１は、本発明の実施の形態に係るＪａｖａプログラム実行システムの構成を示すブロック図である。

同図において、ＪａｖａＶＭ１０１は、インタプリタ１０２及びクラスローダ１０３を有している。インタプリタ１０２は、Ｊａｖａバイトコード（中間コード）を解釈及び実行する。システムライブラリ１０４は、ＪａｖａＶＭ１０１と共に提供されるシステムクラスライブラリ（以下、システムライブラリと称す）である。ロード済みクラス１０５は、メモリにロードされて実行可能状態となっているクラスである。

アプリケーション１０６は、Ｊａｖａ言語で記述されたアプリケーションである。アプリケーションクラス１０７は、このアプリケーション１０６の動作のメインとなるクラス（以下、アプリケーションクラスと称す）である。アプリケーションライブラリ１０８は、アプリケーション１０６と共に提供されるクラスライブラリ（以下、アプリケーションライブラリと称す）である。インポートライブラリ１０９は、アプリケーション１０６の外部に存在するが、アプリケーション１０６の動作の一部分に使用されるクラスライブラリ（以下、インポートライブラリと称す）を示している。１１０はＪａｖａＶＭ実行装置である。

図１において、ＪａｖａＶＭ１０１は、インタプリタ１０２及びクラスローダ１０３を有している。またアプリケーション１０６は、アプリケーションクラス１０７及びアプリケーションライブラリ１０８を有している。ＪａｖａＶＭ実行装置１１０は、ＪａｖａＶＭ１０１、システムライブラリ１０４、及びロード済みクラス１０５を有している。ここでＪａｖａＶＭ１０１及びアプリケーション１０６は、同じ装置、つまりＪａｖａＶＭ実行装置１１０の中に存在してもよい。また、アプリケーション１０６は外部装置に置かれ、ネットワーク手段を用いてＪａｖａＶＭ１０１がそれをロードし実行するという形態でもよい。

図２は、本実施の形態に係るＪａｖａＶＭ実行装置１１０のハードウェア構成を説明するブロック図である。

図において、２０１は装置全体を制御するための中央処理装置（以下、ＣＰＵ）である。ＲＯＭ２０２は、ＣＰＵ２０１により実行される各種動作プログラムやデータを読み取り可能に格納している。ＲＡＭ２０３は、プログラム動作中、ＣＰＵ２０１が各種データを一時的に保存するためのワークエリアとして使用される。タイマ２０４は、ＣＰＵ２０１の指示に従って各種時間を計測する。表示部２０５は、ユーザインタフェースを表示するためのディスプレイ（表示部）で、例えば液晶やプラズマ等の表示パネルを有している。キーボード２０６は、各種操作キーや、マウス等のポインティングデバイスを有し、ユーザの操作によりアプリケーションの実行指示や各種コマンドやデータデータの入力に使用される。ＦｌａｓｈＲＯＭ２０７は、各種設定データやファイルを不揮発性に保存している。２０８は、ネットワークを介して外部装置と接続するためのネットワークＩ／Ｆである。ハードディスク（以下、ＨＤと称す）２０９には、ＯＳや各種アプリケーションプログラム等が予めインストールされており、また各種設定データファイルも保存している。

ここでは前述したインタプリタ１０２、クラスローダ１０３は、プログラム形態で、例えばＲＯＭ２０２に格納されており、ＣＰＵ２０１はそれを読み出して実行する。尚、これらはＨＤ２０９に格納されていても良い。システムライブラリ１０４は、ＦｌａｓｈＲＯＭ２０７又はＨＤ２０９に記憶されている。更に、ロード済みクラス１０５は、ＲＡＭ２０３に記憶されている。またアプリケーション１０６やインポートライブラリ１０９は、ＪａｖａＶＭ実行装置１１０と同一装置内に置かれる場合は、ＦｌａｓｈＲＯＭ２０７或はＨＤ２０９に記憶される。また他の外部装置内に置かれる場合は、その外部装置の適切な記憶媒体上に置かれる。

以下の説明において、動作の主体となるハードウエアは、殆どの場合、装置を制御するＣＰＵ２０１であるため、例外となる場合を除いて、動作の主体を逐一明示することはしない。

次に、アプリケーション１０６の実行手順について、図３のフローチャートを用いて説明する。

図３は、本実施の形態に係るＪａｖａＶＭ実行装置１１０におけるアプリケーションの実行手順を示すフローチャートである。

まずステップＳ３０１で、クラスローダ１０３がアプリケーション１０６のメインとなるクラス（最初に呼び出すクラス）をアプリケーションクラス１０７からロードする。こうしてロードしたクラスは、ロード済みクラス１０５として、ＲＡＭ２０３に記憶される。次にステップＳ３０２で、ロード済みクラス１０５となったメインクラスをインタプリタ１０２が読み出して、これを解釈及び実行する。ここでインタプリタ１０２は、アプリケーション１０６が終了するまで、この解釈及び実行処理を実行する。そのためステップＳ３０３で、アプリケーション１０６が終了したかどうかを常に監視する。

ステップＳ３０３でアプリケーション１０６が終了したら、実行手順は終了する。アプリケーション１０６が終了していない場合はステップＳ３０４に進み、インタプリタ１０２は、次のバイトコードの実行に必要なクラスが、ロード済みクラス１０５にロードされているかどうかを判断する。ここでロード済みであればステップＳ３０２に進み、アプリケーション１０６の解釈及び実行ステップに戻る。

一方、ステップＳ３０４で、必要なクラスがロード済みでなければステップＳ３０５に進み、インタプリタ１０２はそのクラスのロードをクラスローダ１０３に要求する。これを受けてステップＳ３０６で、クラスローダ１０３は、その要求されたクラスをロードする。このクラスのロード先としてはシステムライブラリ１９４、アプリケーションライブラリ１０８、インポートライブラリ１０９等があり、これらのそれぞれの場合のついては詳しく後述する。こうして、そのクラスのロードが終了した後、ステップＳ３０２の解釈実行ステップに戻る。

以下、図３のステップＳ３０６で実行されるクラスローダ１０３によるクラスロード処理の各実施例を説明する。

［実施例１］
図４は、本発明の実施例１に係るステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順１）を説明するフローチャートである。

最初にステップＳ４０１で、クラスローダ１０３は、インタプリタ１０２より要求されたクラスが、予め定められた条件を満たすかどうかを判断する。この具体的な、第一の判断方法は、クラス名が次の条件を満たしているかどうかを調べることである（Ｊａｖａ言語におけるクラス名は、一乃至複数の文字列がピリオドで連結された形式をとる）。
・第一の判断方法の条件
（１）要求されたクラスのクラス名が、予めＲＡＭ２０３等の記憶媒体に記憶された、一乃至複数の文字列に完全に一致する。
（２）要求されたクラスのクラス名の先頭部分が、予め記憶された一乃至複数の文字列に一致する。
（３）要求されたクラスのクラス名の一部が、予め記憶された一乃至複数の文字列を含む。

ここでパッケージ名と比較される一乃至複数の文字列としては、上記条件を満たすことにより、ＪａｖａＶＭ実行装置１１０が動作する上で望ましくなる文字列が選択される。これら条件は、アプリケーションライブラリ１０８からロードした方が望ましいクラスの名称が満たすべき条件を例示している。従って、これ以降のステップでは、上記条件を満たすクラスについては、アプリケーションライブラリ１０８からロードを試みる。アプリケーションライブラリ１０８は、アプリケーション１０６に同梱されており、通常、既に動作評価が終了している。つまり、安定動作が保証されている。アプリケーションライブラリ１０８の中に存在するクラスでも、更新された一部のクラスについてはその更新クラスを使用した方がよい場合もあるが、安定動作が保証されたクラスを使用した方がよい場合もある。こうすることにより、ある特定のクラスだけ、アプリケーションライブラリ１０８からのロードを優先することができる。

上記の３つの条件は、もちろん、いずれを採用してもよく、例えばあるクラスについては条件（１）、他のクラスについては条件（２）というように組み合わせてもよい。

第二の判断方法は、パッケージ名がある条件を満たしているかどうかを調べることである。Ｊａｖａ言語におけるパッケージ名とは、クラス名のうち、最後のピリオドより前の部分を指す。例えば、クラス名が「com.xxx.project1.module1.type1.class1」である場合、パッケージ名は「com.xxx.project1.module1.type1」である。クラスに名前を付けるとき、必ずパッケージ名がなければいけないということはないが、クラス名の衝突を防ぐため、つまり名前空間を確保するため、パッケージ名が付けられる。このように一貫した思想の基にパッケージ名を付与することによって、クラスの作成者（企業）やクラスの種別を識別することもできる。
・第二の判断方法の条件
（１）パッケージ名が、予めＲＡＭ２０３等の記憶媒体に記憶された、一乃至複数の文字列に完全に一致する。
（２）パッケージ名の先頭部分が、予め記憶された一乃至複数の文字列に一致する。
（３）パッケージ名の一部が、予め記憶された一乃至複数の文字列を含む。

ここでパッケージ名と比較される一乃至複数の文字列としては、上記条件を満たすことにより、ＪａｖａＶＭ実行装置１１０が動作する上で望ましくなる文字列が選択される。これら条件は、アプリケーションライブラリ１０８からロードした方が望ましいクラスのパッケージ名称が満たすべき条件を例示している。従ってこれ以降のステップでは、上記条件を満たすクラスについては、アプリケーションライブラリ１０８からロードを試みる。アプリケーションライブラリ１０８は、アプリケーション１０６に同梱されており、通常、既に動作評価が終了している。つまり、安定動作が保証されている。アプリケーションライブラリ１０８の中に存在するクラスでも、更新された一部のクラスについてはその更新クラスを使用した方がよい場合もあるが、安定動作が保証されたクラスを使用した方がよい場合もある。

一部、注意しなければならないのは、セキュリティ上、アプリケーションライブラリ１０８からロードすることが望ましくないクラス或はパッケージが存在することである。例えば、Ｊａｖａ言語の場合は、ｊａｖａやｊａｖａｘで始まるパッケージはシステムが提供するライブラリであり、セキュリティの根幹をなすものである。それらのパッケージをアプリケーションライブラリ１０８からロードすることはセキュリティ違反であり、許可されない。そのようなクラス或はパッケージについては、上記条件を設定しても、無効になるようにする。具体的には、それらのパッケージ名をＲＡＭ２０３に設定しようとしても（設定手順は図示せず）、できないようにしておく。

このようにすることによって、許可された、ある特定のパッケージだけ、アプリケーションライブラリ１０８からのロードを優先することができる。上記の３条件は、もちろん、いずれを採用してもよく、あるパッケージについては条件１、別のパッケージについては条件２というように組み合わせてもよい。またクラス名の条件とパッケージ名の条件を混合して使用することも可である。

こうしてステップＳ４０１で、要求されたクラスが所定の条件を満たしていると判断した場合はステップＳ４０２に進み、クラスローダ１０３はそのクラスがアプリケーションライブラリ１０８に存在するかどうかを調べる。ここでアプリケーションライブラリ１０８内に存在すればステップＳ４０３に進み、クラスローダ１０３はアプリケーションライブラリ１０８から、そのクラスをロードする。

一方、ステップＳ４０２で、アプリケーションライブラリ１０８内に存在しなければ、ステップＳ４０４に進み、クラスローダ１０３はそのクラスがインポートライブラリ１０９内に存在するかどうかを調べる。ここでインポートライブラリ１０９内に存在していると判定するとステップＳ４０５に進み、そこからクラスをロードする。

またステップＳ４０４で、インポートライブラリ１０９内に存在していないと判定した場合、或はステップＳ４０１で、その要求されたクラスが所定の条件を満たさなかった場合はステップＳ４０６に進む。そして、ステップＳ４０６では、クラスローダ１０３はクラスパスの優先順位に従って、クラスを検索する。そしてステップＳ４０７で、最終的にクラスが見つかったかどうかを判断し、クラスが見つかった場合はステップＳ４０８に進んで、クラスローダ１０３は、その見つかったパスからクラスをロードして処理を終了する。一方、ステップＳ４０７で、最終的にクラスが見つからなかった場合はステップＳ４０９に進み、クラスローダ１０３はクラスを発見できなかったことを示す例外を発生させて、この処理を終了する。

尚、ここでステップＳ４０６〜Ｓ４０９の処理は従来技術と同様である。通常、システムライブラリ１０４からのロードが、アプリケーションライブラリ１０８やインポートライブラリ１０９からのロードより優先される。

以上説明したように実施例１に係るクラスロード手順１によれば、アプリケーションライブラリ１０８或はインポートライブラリ１０９にクラスが存在する場合は、システムライブラリ１０４を探さずに、そのクラスが存在しているアプリケーションライブラリ１０８或はインポートライブラリ１０９からクラスをロードする。これにより、既に動作確認されているはずのクラスを優先して使用できるため、安定した動作が期待できる。

［実施例２］
次に本発明の実施例２に係るクラスロード手順２について、図５のフローチャートを用いて説明する。

図５は、実施例２に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順２）を説明するフローチャートである。尚、この実施例２に係るｊａｖａＶＭ実行装置１１０の構成及びアプリケーションの実行手順の基本的流れは前述の実施例１（図３）と同様であるものとする。

まずステップＳ５０１で、クラスローダ１０３は、インタプリタ１０２より要求されたクラスが、予め定められた条件を満たすかどうかを判断する。この判断処理は前述の図４のステップＳ４０１の場合と同じであるため、その説明を省略する。

ステップＳ５０１で所定の条件を満たしていると判断した場合はステップＳ５０２に進み、クラスローダ１０３は、そのクラスがアプリケーションライブラリ１０８内に存在するかどうかを調べる。ここでアプリケーションライブラリ１０８内に存在すればステップＳ５０３に進み、クラスローダ１０３はアプリケーションライブラリ１０８のバージョン情報を取得する。次にステップＳ５０４で、クラスローダ１０３は、その要求されたクラスがシステムライブラリ１０４内に存在するかどうかを調べる。存在すればステップＳ５０５に進み、クラスローダ１０３は、そのシステムライブラリ１０４のバージョン情報を取得する。次にステップＳ５０６に進み、クラスローダ１０３は、ステップＳ５０３で取得したアプリケーションライブラリ１０８のバージョンと、ステップＳ５０５で取得したシステムライブラリ１０４のバージョンとが等しいかどうかを調べる。ここで両者のバージョンが異なると判定するとステップＳ５０７に進み、クラスローダ１０３はアプリケーションライブラリ１０８からクラスをロードする。一方、ステップＳ５０６で、バージョンが等しいと判断するとステップＳ５１４に進み、クラスローダ１０３はシステムライブラリ１０４からクラスをロードする。

またステップＳ５０４で、その要求されたクラスがシステムライブラリ１０４内に存在しない場合はステップＳ５０７に進み、アプリケーションライブラリ１０８からクラスをロードする。

またステップＳ５０２で、そのクラスがアプリケーションライブラリ１０８内に存在しない場合はステップＳ５０８に進み、クラスローダ１０３は、そのクラスがインポートライブラリ１０９内に存在するかどうかを調べる。ここでインポートライブラリ１０９内に存在していると判定するとステップＳ５０９に進み、インポートライブラリ１０９のバージョンを取得してステップＳ５０４に進む。この場合はステップＳ５０４で、クラスローダ１０３は、その要求されたクラスがシステムライブラリ１０４内に存在するかどうかを調べる。存在すればステップＳ５０５に進み、クラスローダ１０３は、そのシステムライブラリ１０４のバージョン情報を取得する。次にステップＳ５０６に進み、クラスローダ１０３は、ステップＳ５０９で取得したインポートライブラリ１０９のバージョンと、ステップＳ５０５で取得したシステムライブラリ１０４のバージョンとが等しいかどうかを調べる。ここで両者のバージョンが異なると判定するとステップＳ５０７に進み、クラスローダ１０３はインポートライブラリ１０９からクラスをロードする。一方、ステップＳ５０６で、バージョンが等しいと判断するとステップＳ５１４に進み、クラスローダ１０３はシステムライブラリ１０４からクラスをロードする。

またステップＳ５０８で、クラスがインポートライブラリ１０９内に存在していない場合、或はステップＳ５０１で所定の条件を満たさなかった場合はステップＳ５１０に進み、クラスローダ１０３はクラスパスの優先順位に従って、クラスを検索する。そしてステップＳ５１１で、最終的にクラスが見つかったかどうかを判断し、クラスが見つかった場合はステップＳ５１２に進み、クラスローダ１０３は、その見つかったパスからクラスをロードする。一方、見つからなかった場合はステップＳ５１３に進み、クラスローダ１０３はクラスを発見できなかったことを示す例外を発生させる（前述の図４のステップＳ４０６〜Ｓ４０９と同様）。

尚、このクラスロード手順２の説明では、システムライブラリ１０４、アプリケーションライブラリ１０８、及びインポートライブラリ１０９が、まるで一つずつ提供されており、バージョン情報が各々に一つ付与されているような印象を与えたかもしれない。しかし、各ライブラリは複数のライブラリファイルとして構成することが可能であり、その場合は、探索中のクラスを含むライブラリファイルのバージョン情報を取得すればよい。

Ｊａｖａ環境では、ライブラリとしてｊａｒファイル形式を用いるのが一般的である。このｊａｒファイルは、クラスファイルの他に、様々なライブラリ情報を格納したマニフェストファイルを含むことができる。よって、このマニフェストファイルにバージョン情報を記述しておけば、これをライブラリのバージョン情報として利用できる。

また上記説明では、ライブラリのバージョン情報を使用した。しかし、もしクラス毎にバージョン情報が付与されていて、それを取得できるのであれば（これもマニフェストファイルに記述しておくことができる）、クラス毎にライブラリを変えてロードすることも可能である。

以上説明したように実施例２に係るクラスロード手順２によれば、クラスをロードするライブラリのバージョンを比較して、等しい場合にシステムライブラリ１０４からクラスをロードしている。これによって、クラスのロードに要する時間を短縮できる。特に、アプリケーションライブラリ１０９がＪａｖａＶＭ実行装置１１０の外部にある場合は有効である。

また、アプリケーションライブラリ１０９がＪａｖａＶＭ実行装置１１０の内部にある場合でも、クラスのロードもしくはクラスの実行が速くなることがある。

その第一の理由は、システム内で共通に利用されるシステムライブラリ１０４は重要度が高いので、アプリケーションライブラリ１０９よりもアクセス速度が速い記憶媒体に置かれることが多いためである。

第二の理由は、やはり重要度が高いシステムライブラリ１０４は、ＣＰＵ２０１による実行速度向上を目的に、最適化された中間コード、もしくは、ＣＰＵ２０１が直接実行できるネイティブコードに予め変換されている場合があるためである。

［実施例３］
次に、実施例３に係るクラスロード手順３について図６のフローチャートを用いて説明する。

図６は、実施例３に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順３）を説明するフローチャートである。尚、この実施例３に係るｊａｖａＶＭ実行装置１１０の構成及びアプリケーションの実行手順の基本的流れは前述の実施例１（図３）と同様であるものとする。

最初にステップＳ６０１で、クラスローダ１０３は、実行中のアプリケーションがクラスロードにおいてクラスパス検索を優先するかどうかを判断する。この判断を行うために、ＲＡＭ２０３には、クラスパス検索を優先するかどうかを示すフラグをアプリケーション毎に記憶しているものとする（図示せず）。

ステップＳ６０１で、クラスパス検索を優先しないと判定した場合はステップＳ６０２に進み、クラスローダ１０３は、インタプリタ１０２より要求されたクラスが、予め定められた条件を満たすかどうかを判断する。ここで予め定められた条件（図４のＳ４０１の場合と同様）を満たすと判定したときはステップＳ６０３に進み、クラスローダ１０３は、そのクラスがアプリケーションライブラリ１０８内に存在するかどうかを調べる。ここで存在する場合はステップＳ６０４に進み、クラスローダ１０３はアプリケーションライブラリ１０８から該クラスをロードする。

一方、ステップＳ６０３で、そのクラスがアプリケーションライブラリ１０８内に存在しないと判定した場合はステップＳ６０５に進み、クラスローダ１０３は、そのクラスがインポートライブラリ１０９内に存在するかどうかを調べる。ここでインポートライブラリ１０９内に存在していればステップＳ６０６に進み、そこからクラスをロードする。

ステップＳ６０５で、インポートライブラリ１０９内に存在していない場合、或はステップＳ６０２で所定の条件を満たさなかった場合、或はステップＳ６０１でクラスパス検索を優先すると判断された場合はステップＳ６０７に進む。そして、ステップＳ６０７では、クラスローダ１０３はクラスパスの優先順位に従って、クラスを検索する。ここでステップＳ６０７〜Ｓ６１０の処理は、前述の図４のステップＳ４０６〜Ｓ４０９の処理と同じであるため、その説明を省略する。

以上説明したように本実施例３に係るクラスロード手順３では、あるアプリケーションではクラスパス検索を優先し、他のアプリケーションではアプリケーションライブラリ１０８からロードすることが可能となる。例えば、あるクラスの新バージョンがシステムライブラリ１０４の一部として提供されたと仮定する。このとき、あるアプリケーションではシステムライブラリ１０４内に存在する新バージョンのクラスを用いる。一方、他のアプリケーションでは、アプリケーションライブラリ１０９内に存在する、安定動作が期待できる旧バージョンのクラスを用いるというように設定できる。このようにＪａｖａＶＭ実行装置１１０を運用することが可能である。

或は、もう一つの例として、あるアプリケーションはアプリケーションライブラリ１０８からクラスをロードすると仮定する。そしてバグフィックスの後、新バージョンのクラスをシステムライブラリ１０４に入れて、そこからロードするように変更する場合を考える。アプリケーション１０６（及びそれに内包されているアプリケーションライブラリ１０８）は容易に変更できないが、ＪａｖａＶＭ実行装置１１０内のソフトウエアの入れ替ができる状況では、そのような事態も起こり得る。その場合は、システムライブラリ１０４を含むソフトウエアの入れ替えを行うと同時に、上記クラスパス検索を優先するかどうかを示すフラグを該アプリケーション１０６について変更すれば、ユーザが意図するように動作を変更できる。

［実施例４］
次に、クラスロード手順４について、図７のフローチャートを用いて説明する。

図７は、本発明の実施例４に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順４）を説明するフローチャートである。尚、この実施例４に係るｊａｖａＶＭ実行装置１１０の構成及びアプリケーションの実行手順の基本的流れは前述の実施例１（図３）と同様であるものとする。

まず最初にステップＳ７０１で、クラスローダ１０３は、インタプリタ１０２より要求されたクラスが、予め定められた条件を満たすかどうかを判断する。この予め定められた条件とは、前述の図４のＳ４０１で説明した条件と同じである。ここで所定の条件を満たしていると判断した場合はステップＳ７０２に進み、クラスローダ１０３は、そのクラスがアプリケーションライブラリ１０８内に存在するかどうかを調べる。ここで存在すればステップＳ７０３に進み、クラスローダ１０３はアプリケーションライブラリ１０８のバージョン情報を取得する。次にステップＳ７０４に進み、クラスローダ１０３は、そのクラスがシステムライブラリ１０４内に存在するかどうかを調べる。存在すればステップＳ７０５に進み、クラスローダ１０３は、システムライブラリ１０４のバージョン情報を取得する。

次にステップＳ７０６で、クラスローダ１０３は、ステップＳ７０３で取得したアプリケーションライブラリ１０８のバージョンと、システムライブラリ１０４のバージョンとが等しいか否かを調べる。ここで両者のバージョンが異なる場合はステップＳ７０７に進み、クラスローダ１０３は、新しいバージョンのライブラリからロードすべきかどうかを調べる。これを判断するために、ＲＡＭ２０３内に、新しいバージョンのライブラリからロードすべきかどうかを示すフラグ（図示せず）が存在する。このフラグはＪａｖａＶＭ実行装置１１０内に一つだけ存在してもよいし、アプリケーション毎、またはライブラリ毎に存在してもよい。ステップＳ７０７でロードすべきでないと判断した場合はステップＳ７０８に進み、クラスローダ１０３は、アプリケーションライブラリ１０８からクラスをロードする。一方、ロードすべきであると判断した場合はステップＳ７１６に進み、新しいバージョンのライブラリからクラスをロードする。

またステップＳ７０６で、両者のバージョンが等しい場合はステップＳ７１５に進み、クラスローダ１０３は、システムライブラリ１０４からクラスをロードする。またステップＳ７０４で、そのクラスがシステムライブラリ１０４内に存在しない場合はステップＳ７０８に進み、アプリケーションライブラリ１０８からクラスをロードする。

またステップＳ７０２で、そのクラスがアプリケーションライブラリ１０８内に存在しない場合はステップＳ７０９に進み、クラスローダ１０３は、そのクラスがインポートライブラリ１０９内に存在するかどうかを調べる。ここでインポートライブラリ１０９内に存在していればステップＳ７１０に進み、インポートライブラリ１０９のバージョンを取得してステップＳ７０４に移行する。この後の手順は、アプリケーションライブラリ１０８をインポートライブラリ１０９と置き換えれば、上述したステップＳ７０４〜７０８，Ｓ７１５，Ｓ７１６の説明の通りであるため、その説明を省略する。

またステップＳ７０９で、クラスがインポートライブラリ１０９内に存在していない場合、或はステップＳ７０１で所定の条件を満たさなかった場合はステップＳ７１１に進み、クラスローダ１０３は、クラスパスの優先順位に従って、クラスを検索する。そしてステップＳ７１１〜Ｓ７１４の処理は、前述の図４のステップＳ４０６〜Ｓ４０９の処理と同様であるため、その説明を省略する。

［実施例５］
次に、クラスロード手順５について、図８のフローチャートを用いて説明する。

図８は、本発明の実施例５に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順５）を説明するフローチャートである。尚、この実施例５に係るｊａｖａＶＭ実行装置１１０の構成及びアプリケーションの実行手順の基本的流れは前述の実施例１（図３）と同様であるものとする。

この処理は、インタプリタ１０２がクラスローダ１０３に対しクラスのロードを要求することにより開始され、まずステップＳ８０１で、クラスローダ１０３は現在実行中のアプリケーション１０６の情報を取得する。次にステップＳ８０２で、クラスローダ１０３は、要求されたクラスが入っているライブラリをクラスパスに従って検索する。次にステップＳ８０３で、そのクラスを含むライブラリが見つかったかどうかを判断し、見つかった場合はステップＳ８０４に進み、その見つけたライブラリのパスを記憶する。更にステップＳ８０５で、そのライブラリのバージョンを取得する。次にステップＳ８０６で、クラスローダ１０３は、ステップＳ８０１で取得したアプリケーション情報、ステップＳ８０４，Ｓ８０５で見つかったライブラリの情報、及びそのバージョン情報に基づいて、そのクラスを、そのライブラリからロードすべきかどうかを判断する。ここで、そのライブラリからロードしないと判断したときはステップＳ８０２に戻る。

このステップＳ８０６の判断は、図９のライブラリ情報テーブル９０１に基づいて行う。このテーブルはＲＡＭ２０３、ＦｌａｓｈＲＯＭ２０７、或はＨＤ２０９に記憶されている。

図９は、この実施例５に係るライブラリ情報テーブルの一例を示す図である。

ここではアプリケーションに対応して、ライブラリ、バージョン、クラスをロードしてくる優先ライブラリの位置が記憶されている。

このようなライブラリ情報テーブル９０１を用いて、アプリケーション１０６、ライブラリ、更に必要であればバージョン情報に基づき、クラスをロードするライブラリの位置を決定することができる。

例えば、アプリケーションＡＡＡを実行中に、クラスＹＹＹをロードする要求が生じたとする。このクラスＹＹＹは、ライブラリaaa.jarに含まれるとする。この場合、ライブラリ情報テーブル９０１を参照すると、アプリケーション＝AAA、ライブラリ＝aaa.jarに対応する、クラスをロードしてくる「優先ライブラリの位置」の項には「アプリケーションライブラリ」となっている。

この時、ステップＳ８０２の検索で発見されたライブラリがシステムライブラリ１０４であれば、これはライブラリ情報テーブル９０１が指示する「アプリケーションライブラリ」とは一致しなくなる。従って、この場合ステップＳ８０６において、クラスローダ１０３はシステムライブラリ１０４からクラスをロードすべきでないと判断し、ステップＳ８０２に戻り、クラスパスが示す次の検索場所からクラスを探す。

そして、ここでもし、２回目の検索で見つかったライブラリがアプリケーションライブラリ１０８であれば、これはライブラリ情報テーブル９０１が指示する「アプリケーションライブラリ」と一致する。従って、この場合はステップＳ８０６で、クラスローダ１０３はアプリケーションライブラリ１０８からクラスをロードすべきであると判断してステップＳ８０７に進み、クラスローダは、そのロードすべきであると判断したライブラリからクラスをロードする。

また別の例として、アプリケーションＢＢＢを実行中に、クラスＹＹＹをロードする要求が生じたとする。クラスＹＹＹは上記と同様、ライブラリaaa.jarに含まれるものとする。このとき図８のステップＳ８０２でシステムライブラリ１０４の中にあることが見つかったとする。この場合、ライブラリ情報テーブル９０１の優先ライブラリの位置は「システムライブラリ」であるので、ステップＳ８０６において、クラスローダ１０３はシステムライブラリ１０４からクラスをロードすべきであると判断してステップＳ８０７に進む。

尚、ライブラリ情報テーブル９０１に存在する、「クラスをロードしてくる優先ライブラリの位置」の情報は、どこからロードすべきか区別がつくものであればよい。よって、例えば「アプリケーションライブラリ」、「システムライブラリ」というような位置の種別を表すものでもよいし、直接ライブラリを指す、ライブラリパスそのものが記憶されていてもよい。上記の例では、クラスをロードすべきかどうかを判断するのに、ステップＳ８０５で得たバージョン情報は使わなかった。これは図９に示すライブラリ情報テーブル９０１では、アプリケーションＡＡＡ、ライブラリaaa.jarに対応するバージョン欄は空欄のためである。

以下の例では、このバージョン情報を使う場合で説明する。

アプリケーションＣＣＣを実行中に、クラスＹＹＹをロードする必要が生じたとする。このクラスＹＹＹは上記と同様、ライブラリaaa.jarに含まれる。いまステップＳ８０４で見つかったライブラリは、システムライブラリ１０４であったとする。そしてステップＳ８０５では、このシステムライブラリ１０４のバージョンを取得する。この場合、ステップＳ８０６では、クラスローダ１０３は、ライブラリ情報テーブル９０１でアプリケーション＝ＣＣＣ、ライブラリ＝aaa.jar、クラスをロードしてくる「優先ライブラリの位置」＝「システムライブラリ」に対応するバージョン情報を取得する。

図９において、アプリケーション＝ＣＣＣ、ライブラリ＝aaa.jarに対応するシステムライブラリのバージョン情報は「２．０以上」となっている。

従って、この場合はステップＳ８０６で、このバージョン情報の条件をステップＳ８０５で取得したバージョン情報が満たすかどうかを判定する。そして条件を満たす場合は、そのクラスを、そのライブラリからロードすべきであると判断する。

一方ステップＳ８０２で、クラスをクラスパスに従って検索し、ステップＳ８０３で、最後までステップＳ８０６の条件を満たすライブラリがなかった場合はステップＳ８０８に進む。ここでは、クラスローダ１０３は、以前、要求クラスが存在することを発見されたライブラリがあったか、つまり、ステップＳ８０４で記憶されたライブラリがあるかどうかを調べる。ここで記憶されたライブラリとは、クラスを含むことは分かっているものの、ステップＳ８０６の条件判断により、ロードを一旦断念したライブラリである。しかし、このライブラリは、その要求されたクラスは含んでいるので、発見されたライブラリがあった場合はステップＳ８０７に進み、そのクラスをロードする。一方、ステップＳ８０８で、発見されたライブラリが一つもなければステップＳ８０９に進み、クラスローダ１０３は、クラスを発見できない旨を示す例外を発生して処理を終了する。

またこれ以外に、発見されたライブラリが複数存在する場合も、様々な実施例が考えられる。即ち、この場合には、
（１）最初に発見されたライブラリを優先する。
（２）アプリケーションライブラリ１０８を優先する。
（３）新しいバージョンのライブラリを優先する。
などのように、クラスロード手順１〜４までに説明した様々なライブラリ選択手法を応用することが考えられる。

また図８のフローチャートでは、ステップＳ８０２で、クラスパスに従ってライブラリを検索したが、この検索方法においても、様々なバリエーションが考えられる。即ち、
（１）最初に発見されたライブラリを優先する。
（２）アプリケーションライブラリ１０８を優先する。
（３）新しいバージョンの方を優先する。
など、クラスロード手順１〜４までに説明した様々なライブラリ選択手法を応用することが考えられる。

［実施例６］
次に、クラスロード手順６について、図１０のフローチャートを用いて説明する。

図１０は、本発明の実施例６に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順６）を説明するフローチャートである。尚、この実施例６に係るｊａｖａＶＭ実行装置１１０の構成及びアプリケーションの実行手順の基本的流れは前述の実施例１（図３）と同様であるものとする。

最初にステップＳ１００１で、クラスローダ１０３は、現在実行中のアプリケーション情報を取得する。次にステップＳ１００２で、クラスローダ１０３は、要求されたクラスが入っているライブラリをクラスパスに従って検索する。その結果ステップＳ１００３で、クラスを含むライブラリが見つかったかどうかを判定する。見つかった場合はステップＳ１００４に進み、そのライブラリ名を取得する。次にステップＳ１００５に進み、クラスローダは、次に優先するライブラリが存在するかどうかを調べる。これは、ライブラリ情報テーブル９０１をアレンジしたテーブルである、図１１のライブラリ情報テーブル１１０１を参照して判定する。

図１１は、この実施例６に係るライブラリ情報テーブルの一例を示す図である。

図９に示すライブラリ情報テーブル９０１と、この図１１に示すテーブル１１０１の相違点を説明する。図９のテーブル９０１では、クラスをロードしてくる優先ライブラリの位置の情報が一つだけ存在している。これに対して図１１では、優先ライブラリ情報がリストになっており、第１優先ライブラリから第３優先ライブラリまで存在している。もちろん、図１１では、第３優先ライブラリまでが記述されているが、この優先ライブラリの数に制限はない。

ステップＳ１００５では、クラスローダ１０３は、ステップＳ１００１で取得したアプリケーション情報、ステップＳ１００４で取得したライブラリ名から、ライブラリ情報テーブル１１０１を参照して、次に優先するライブラリが存在するかどうかを調べる。このステップを最初に実行する場合は、当然、「第１優先ライブラリの位置」の項が存在するかどうかを調べる。調べる方法は、ライブラリ情報テーブル９０１を用いて上記で説明した方法と同一である。

ステップＳ１００５で、優先するライブラリが存在すればステップＳ１００６に進み、その優先ライブラリの位置を取得する。次にステップＳ１００７で、クラスローダ１０３は、そのライブラリの位置に、ステップＳ１００４で取得したライブラリ名を持つライブラリが実在するかどうかを調べる。ここで実在すればステップＳ１００８に進み、クラスローダ１０３は、要求されたクラスが、そのライブラリの中に存在するかどうかを調べる。ここでクラスが存在すればステップＳ１００９に進み、クラスローダ１０３は、ライブラリを一旦ＲＡＭ２０３などに記憶してステップＳ１０１０に進み、ライブラリのバージョンを取得する。次にステップＳ１０１１で、クラスローダ１０３は、そのバージョンがライブラリ情報テーブル１１０１のバージョン条件に適合しているかどうかを調べる。これを調べる方法は、ライブラリ情報テーブル９０１を用いて上記で説明した方法と同一である。ここでバージョン条件が適合していればステップＳ１０１２に進み、クラスローダ１０３は、そのライブラリからクラスをロードする（ステップＳ１０１２）。

一方、ステップＳ１００７でライブラリが実在しない場合、或はステップＳ１００８でクラスがライブラリの中に存在しない場合、或は、ステップＳ１０１１でバージョン条件が適合しない場合はステップＳ１００５に戻り、次の優先するライブラリを探す。このループ処理によって、第１優先ライブラリから順に優先ライブラリの探索が行われる。

ステップＳ１００５で、次に優先するライブラリが存在しな苦なるとステップＳ１０１３に進み、クラスローダ１０３は、ステップＳ１００９で記憶されたライブラリが存在するかどうかを調べる。この記憶されたライブラリは、要求されたクラスを含むことが分かっているライブラリである。ステップＳ１０１３で、記憶されたライブラリが存在すればステップＳ１０１２に進み、そのライブラリからクラスをロードする。一方、ステップＳ１０１３で、記憶されたライブラリが存在しなかった場合、或は、ステップＳ１００３でクラスを含むライブラリが見つからない場合はステップＳ１０１４に進み、クラスローダ１０３は、クラスを発見できない旨の例外を発生する。

以上、各種実施例におけるクラスロード手順について説明してきたが、これらのクラスロード手順は全て、アプリケーション毎に変更することが可能である。それは、ＪａｖａＶＭ１０１内に存在するクラスローダ１０３が、実行中のアプリケーションを識別して、クラスロード手順を切り替えることによって可能である。

また図示していないが、各アプリケーションがクラスローダを備える（アプリケーションクラスローダ）ことによっても、クラスロード手順をアプリケーション毎に変更することができることは、同業者にとっては容易に理解できよう。この場合はアプリケーションクラスローダの違いが、各アプリケーションを識別していることになる。

尚、本実施の形態においては、Ｊａｖａ言語とそれを用いたプログラム及びクラスを例に説明してきた。しかしながら、本発明の骨子は、Ｊａｖａシステムに特有というわけではなく、オブジェクト指向プログラム実行装置一般に適用可能なものであることは、同業者にとって容易に理解できるところである。

（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また一つの機器からなる装置に適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などである。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される。

本発明の実施の形態に係るＪａｖａプログラム実行システムの構成を示すブロック図である。 本実施の形態に係るＪａｖａＶＭ実行装置のハードウェア構成を説明するブロック図である。 本実施の形態に係るＪａｖａＶＭ実行装置におけるアプリケーションの実行手順を示すフローチャートである。 本実施例１に係るステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順１）を説明するフローチャートである。 実施例２に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順２）を説明するフローチャートである。 実施例３に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順３）を説明するフローチャートである。 本発明の実施例４に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順４）を説明するフローチャートである。 本発明の実施例５に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順５）を説明するフローチャートである。 実施例５に係るライブラリ情報テーブルの一例を示す図である。 本発明の実施例６に係る、図３のステップＳ３０６で実行されるクラスのロード処理手順（クラスロード手順６）を説明するフローチャートである。 実施例６に係るライブラリ情報テーブルの一例を示す図である。

Claims (21)

1. オブジェクト指向プログラムを実行する情報処理装置であって、
   ライブラリクラスを蓄積するクラス蓄積手段と、
   実行中のアプリケーションで使用されるクラスが、予め定められた条件を満たすか否かを判定する判定手段と、
   前記判定手段により前記条件を満たすと判定されると、前記アプリケーションが提供するクラスライブラリから前記使用されるクラスをロードし、前記条件を満たさないと判定した場合には、前記クラス蓄積手段から、対応するクラスをロードするように制御するロード制御手段と、
   を有することを特徴とする情報処理装置。
2. 前記予め定められた条件は、前記クラスの名称の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項１に記載の情報処理装置。
3. 前記予め定められた条件は、要求されたクラスのパッケージ名の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項１に記載の情報処理装置。
4. オブジェクト指向プログラムを実行する情報処理装置であって、
   ライブラリクラスを蓄積するクラス蓄積手段と、
   実行中のアプリケーションが第１条件を満たすか否かを判定する第１判定手段と、
   要求されたクラスが第２条件を満たすか否かを判定する第２判定手段と、
   前記第１判定手段により前記第１条件を満たしていると判定され、かつ前記第２判定手段により前記第２条件を満たしていると判定されると、前記アプリケーションが提供するクラスライブラリからクラスをロードし、前記第１判定手段により前記第１条件を満たさないと判定されるか、或は前記第２判定手段により前記第２条件を満たさないと判定されると前記クラス蓄積手段からクラスをロードするように制御する制御手段と、
   を有することを特徴とする情報処理装置。
5. 前記第１条件は、前記アプリケーションがクラスパスを優先する条件であり、前記第２条件は前記クラスの名称の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項４に記載の情報処理装置。
6. オブジェクト指向プログラムを実行する情報処理装置であって、
   ライブラリクラスを蓄積するクラス蓄積手段と、
   実行中のアプリケーションで使用されるクラスが、予め定められた条件を満たすか否かを判定する判定手段と、
   前記クラス蓄積手段と前記アプリケーションのクラスライブラリのバージョン同士を比較する比較手段と、
   前記判定手段により前記条件を満たしていると判定され、かつ前記比較手段の比較により前記バージョンが一致する場合は前記アプリケーションのクラスライブラリから前記クラスをロードし、前記判定手段により前記条件を満たしていないと判定され、かつ前記比較手段の比較により前記バージョンが一致しない場合には、前記クラス蓄積手段からクラスをロードするように制御する制御手段と、
   を有することを特徴とする情報処理装置。
7. 前記予め定められた条件は、前記クラスの名称の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項６に記載の情報処理装置。
8. 前記予め定められた条件は、要求されたクラスのパッケージ名の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項６に記載の情報処理装置。
9. オブジェクト指向プログラムを実行する情報処理装置であって、
   ライブラリクラスを蓄積するクラス蓄積手段と、
   アプリケーションに対応して、クラスをロードするクラスライブラリの優先順位を記憶する記憶手段と、
   アプリケーションの実行中にクラスが要求されると、前記記憶手段を参照して前記クラスをロードすべきクラスライブラリの位置を取得し、当該クラスライブラリから前記クラスをロードするように制御する制御手段と、
   を有することを特徴とする情報処理装置。
10. 前記記憶手段は更に前記クラスライブラリに対応してバージョンを記憶しており、前記制御手段は、更に、前記クラスライブラリのバージョンを基に、ロードを優先すべきクラスライブラリの位置を取得し、当該クラスライブラリからクラスデータをロードすることを特徴とする請求項９に記載の情報処理装置。
11. オブジェクト指向プログラムを実行する情報処理装置におけるオブジェクト指向プログラムの実行方法であって、
    実行中のアプリケーションで使用されるクラスが、予め定められた条件を満たすか否かを判定する判定工程と、
    前記判定工程で前記条件を満たすと判定されると、前記アプリケーションが提供するクラスライブラリから前記使用されるクラスをロードし、前記条件を満たさないと判定した場合には、クラスライブラリを蓄積するシステムライブラリから、対応するクラスをロードするように制御するロード制御工程と、
    を有することを特徴とする情報処理装置におけるオブジェクト指向プログラムの実行方法。
12. 前記予め定められた条件は、前記クラスの名称の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項１１に記載のオブジェクト指向プログラムの実行方法。
13. 前記予め定められた条件は、要求されたクラスのパッケージ名の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項１１に記載のオブジェクト指向プログラムの実行方法。
14. オブジェクト指向プログラムを実行する情報処理装置におけるオブジェクト指向プログラムの実行方法であって、
    実行中のアプリケーションが第１条件を満たすか否かを判定する第１判定工程と、
    要求されたクラスが第２条件を満たすか否かを判定する第２判定工程と、
    前記第１判定工程で前記第１条件を満たしていると判定され、かつ前記第２判定工程で前記第２条件を満たしていると判定されると、前記アプリケーションが提供するクラスライブラリからクラスをロードし、前記第１判定工程で前記第１条件を満たさないと判定されるか、或は前記第２判定工程で前記第２条件を満たさないと判定されると、クラスライブラリを蓄積するシステムライブラリから対応するクラスをロードするように制御する制御工程と、
    を有することを特徴とする情報処理装置におけるオブジェクト指向プログラムの実行方法。
15. 前記第１条件は、前記アプリケーションがクラスパスを優先する条件であり、前記第２条件は前記クラスの名称の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項１４に記載のオブジェクト指向プログラムの実行方法。
16. オブジェクト指向プログラムを実行する情報処理装置におけるオブジェクト指向プログラムの実行方法であって、
    装置が記憶するシステムライブラリと、実行中のアプリケーションで使用されるクラスが、予め定められた条件を満たすか否かを判定する判定工程と、
    前記システムライブラリと前記アプリケーションのクラスライブラリのバージョン同士を比較する比較工程と、
    前記判定工程で前記条件を満たしていると判定され、かつ前記比較工程での比較により前記バージョンが一致する場合は前記アプリケーションのクラスライブラリから前記クラスをロードし、前記判定工程により前記条件を満たしていないと判定され、かつ前記比較工程の比較により前記バージョンが一致しない場合には、前記システムライブラリから対応するクラスをロードするように制御する制御工程と、
    を有することを特徴とする情報処理装置におけるオブジェクト指向プログラムの実行方法。
17. 前記予め定められた条件は、前記クラスの名称の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項１６に記載のオブジェクト指向プログラムの実行方法。
18. 前記予め定められた条件は、要求されたクラスのパッケージ名の少なくとも一部が、予め記憶されている文字列に一致する条件であることを特徴とする請求項１６に記載のオブジェクト指向プログラムの実行方法。
19. オブジェクト指向プログラムを実行する情報処理装置におけるオブジェクト指向プログラムの実行方法であって、
    アプリケーションに対応して、クラスをロードするクラスライブラリの優先順位をメモリに記憶する記憶工程と、
    アプリケーションの実行中にクラスが要求されると、前記メモリを参照して前記クラスをロードすべきクラスライブラリの位置を取得し、当該クラスライブラリから前記クラスをロードするように制御する制御工程と、
    を有することを特徴とするオブジェクト指向プログラムの実行方法。
20. 前記メモリは更に前記クラスライブラリに対応してバージョンを記憶しており、前記制御工程では、更に、前記クラスライブラリのバージョンを基に、ロードを優先すべきクラスライブラリの位置を取得し、当該クラスライブラリからクラスデータをロードすることを特徴とする請求項１９に記載のオブジェクト指向プログラムの実行方法。
21. 請求項１１乃至２０のいずれか１項に記載のオブジェクト指向プログラムの実行方法を実現するためのプログラム。

Images