JP2018032119A - 情報処理装置、情報処理装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】アプリを新バージョンのアプリ実行環境に合わせる互換対応を行った後に、再度、旧バージョンのアプリ実行環境に戻したとしても、アプリを修正することなく使用可能にすること。【解決手段】画像形成装置に構築されたアプリ実行環境内の互換対応モジュールが、アプリのインストール時に、旧バージョンのアプリ実行環境で動作可能なアプリの実行コード内に含まれる第一のクラスの名称を、旧バージョンとの差異を吸収するために用意された第二のクラスの名称に書き換え（S602〜S616）、また、該アプリの実行コードの格納場所に、第二のクラスの実体を差し込む（S617〜S619）。【選択図】図６

Description

本発明は、所定のアプリケーション実行環境を構築可能な情報処理装置、情報処理装置の制御方法、及びプログラムに関するものである。

近年、情報処理装置、及び画像形成装置においては、JAVA（登録商標、以下省略）環境に代表されるようなアプリケーション（以下「アプリ」と略称する）動作環境が提供されている。さらに、JAVAの持つプログラムの可搬性を利用して、拡張可能なアプリを提供する技術が提案されている。

従来、このような情報処理装置、及び画像形成装置上でアプリを実行するためのアプリ実行環境と、そこで実行されるアプリにおいては、アプリがそのアプリ実行環境に合わせて作成されることが前提であった。

一方、アプリ実行環境には、従来の振舞の問題や新たな機能に対応する必要性から従来の振舞との互換性が一部失われるような、すなわち非互換性を含んだ新しいバージョンが市場に導入されることがよくある。
そのような非互換性を含んだ新しいバージョンのアプリ実行環境が導入された場合、アプリもその違いに沿った新しいバージョンが作成されるのが通例であった。これにより、アプリの新しいバージョンが、アプリ実行環境の新しいバージョンとの組合せで不具合なく動作することが保証されてきた。

しかし、近年では、アプリの開発が大規模化し高コストとなっている。その結果、アプリ実行環境の非互換性を含んだ新しいバージョンが導入されたにも関わらず、それに沿った新しいバージョンのアプリを作成するのが困難なケースがある。
このため、アプリ新しいバージョンを作成することなく、非互換性を含んだ新しいバージョンのアプリ実行環境の上でもアプリを不具合なく動作させることを実現するための技術が提案されている。そのような技術に、特許文献１がある。

特許文献１では、アプリ実行環境間の差異を吸収する互換機構部を有する情報処理装置が提案されている。特許文献１の互換機構部は、アプリ実行環境間のインストール仕様の差異を吸収するインストール仕様定義部と、アプリ実行環境間のインタフェース仕様の差異を吸収するインタフェース仕様定義部とを有し、これらをインストール時、及び実行時に利用する。このような構成により、上述のような課題を解決しようとするものである。

特開２０１０−１８１９７６号公報

しかし、上述のような従来技術では、しばしば、新しいアプリ実行環境にアプリをインストールしたときに、アプリ毎の設定ファイルやアプリ自身のファイルなどを新しいアプリ実行環境に合わせる対応を行う。その結果、再度、旧アプリ実行環境に戻した際に、改めて、再度、旧アプリ実行環境に合わせこむための複雑な戻し作業が必要になるという課題があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、アプリを新バージョンのアプリ実行環境に合わせる対応を行った後に、再度、旧バージョンのアプリ実行環境に戻したとしても、アプリを修正することなく使用可能にする仕組みを提供することである。

本発明は、所定のアプリケーション実行環境を構築可能な情報処理装置であって、第１のアプリケーション実行環境との非互換性を含む第２のアプリケーション実行環境において、前記第１のアプリケーション実行環境との非互換性に関わる第１クラスの代替となり、前記非互換性を補完する第２クラスの実体を保持する保持手段と、前記第１のアプリケーション実行環境で動作可能なアプリケーションを前記第２のアプリケーション実行環境で動作させるための前記非互換性に関わる対応を行う第１対応手段と、を有し、前記第１対応手段は、前記対応として、該アプリケーションにおいて前記第１クラスを利用する箇所を前記第２クラスの利用に変更し、また、該アプリケーションに前記保持手段に保持される前記第２クラスの実体を追加することを特徴とする。

本発明によれば、アプリケーションを新バージョンのアプリケーション実行環境に合わせる対応を行った後に、再度、旧バージョンのアプリケーション実行環境に戻したとしても、アプリケーションを修正することなく使用可能にすることができる。

本実施例の情報処理装置を適用可能な画像形成装置のハードウェア構成図 本実施例のアプリケーション実行環境等を説明する図 本実施例のアプリケーション実行環境等を説明する図 本実施例における互換性問題を説明する図 本実施例における互換性問題を説明する図 本実施例における互換対応後のアプリキャッシュの状態を説明する図 本実施例の差し替え条件テーブルを例示する図 実施例１の互換対応を含むインストール処理を説明するフローチャート 実施例１の改変対象クラスリストテーブルを例示する図 実施例２のアップグレード処理を説明するフローチャート 実施例３の削除条件テーブルを例示する図 実施例３の互換対応したアプリを互換対応前の状態に戻す処理を説明するフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。

図１は、本発明の一実施例を示す情報処理装置を適用可能な画像形成装置130のハードウェア構成を例示する図である。本実施例では、本発明の情報処理装置の一実施例を示す画像形成装置130として、プリント機能、スキャン機能、ネットワーク通信機能などを備える複合機を例に説明する。

図１において、コントローラ100は、画像形成装置130の全体を統括制御する制御部である。コントローラ100は、スキャナ部113やプリンタ部114と電気的に接続され、一方でＬＡＮ116を介して外部デバイスと接続される。

コントローラ100において、ＣＰＵ101は、ＲＯＭ102に記憶された制御プログラム等に基づいて接続中の各種ハードウェアとのアクセスを統括的に制御する。また、ＣＰＵ101は、コントローラ100内部で行われる各種処理についても統括的に制御する。
ＲＯＭ102は、フラッシュＲＯＭ等の不揮発記憶装置であり、画像形成装置130のブートプログラム、ファームウェアなどが格納されている。

ＲＡＭ103は、ＣＰＵ101が動作するためのシステムワークメモリであり、各種データを一時記憶するためのメモリである。このＲＡＭ103は、記憶した内容を電源オフ後も保持可能なＦＲＡＭ（登録商標）およびＳＲＡＭ、電源オフ後に記憶内容が消去されるＤＲＡＭなどにより構成される。

ＨＤＤ104は、ハードディスク等の不揮発記憶装置であり、システムアプリ等の各種プログラムや各種データなどを格納する。図２Ａ、図２Ｂで説明するインストールするアプリを含むファームウェアは、ＨＤＤ104に格納される。なお、ハードディスクの代わりに又は併用して、ＳＳＤ（Solid State Drive）等の他の不揮発記憶装置を備えていてもよい。

操作部Ｉ／Ｆ105は、システムバス119と操作部118を接続するインタフェース部である。具体的には、操作部Ｉ／Ｆ105は、操作部118に表示するデータをシステムバス119から受取り表示すると共に、操作部118からの入力情報をシステムバス119へ出力する。画像形成装置130に対するユーザの指示や情報提示は、例えば操作部118を介して行う。

ネットワークＩ／Ｆ106は、ＬＡＮ116、ＷＡＮ117及びシステムバス119に接続し、外部との情報の入出力を行う。スキャナＩ／Ｆ108は、スキャナ部113から受取った画像データに対して、補正、加工、及び編集を行う。画像形成部109は、画像データの方向変換、画像圧縮、伸張部などの処理を行う。プリンタＩ／Ｆ110は、画像形成部109から送られた画像データを受取り、画像形成後にプリンタ部114にて印刷する。

図２Ａ（ａ）は、実施例１のアプリ実行環境の構成を説明する図である。
200は、アプリ実行環境である。図２Ａ（ａ）に示すような、アプリ実行環境200は、ＣＰＵ101がＲＯＭ102又はＨＤＤ104に格納されたプログラムを必要に応じてＲＡＭ103にロードして実行することにより実現されるものである。

アプリ実行環境200において、201は、アプリ実行基盤である。以降、アプリ実行基盤201は、例えば、旧バージョンとしてV1.0、新バージョンとしてV2.0を想定する。旧バージョンのアプリ実行環境200には旧バージョンのアプリ実行基盤201が含まれ、新バージョンのアプリ実行環境200には新バージョンのアプリ実行基盤201が含まれる。なお、本実施例では、新バージョンのアプリ実行環境200は、旧バージョンのアプリケーション実行環境との非互換性を含むものとして以下を説明する。

本実施例では、アプリ実行環境200の一例として、JAVA環境を想定しているが、本発明はJAVA環境に限定されるものではなく、各種のアプリ実行環境に適用可能である。

210は、コード解釈実行モジュールである。アプリキャッシュ203に配置されたアプリのクラスファイル内のバイトコードを解釈して実行する。
211は、実行基盤ライブラリモジュールである。第一のクラス212は、実行基盤ライブラリモジュール211に含まれる、アプリ実行環境200の旧バージョンとの間で互換性が失われたクラスを示す。すなわち、第一のクラス212は、旧バージョンとの間で差異のあるクラス（旧バージョンとの非互換性に関わるクラス）である。

213は互換用サポートライブラリモジュールで、新バージョンのアプリ実行環境200に非対応であるアプリの動作を補完するためのものである。第二のクラス214は、互換用サポートライブラリモジュール213に含まれる、新バージョンのアプリ実行環境200の第一のクラス212における旧バージョンとの非互換性（差異）を補完（吸収）して旧バージョンとの互換性を維持するために用意されたクラスである。なお、第一のクラス212と第二のクラス214は一組である必要はなく、複数組用意されることもある。

上述したように、互換用サポートライブラリモジュール213は、新バージョンと旧バージョンとの互換のために用意されたものであるので、旧バージョンのアプリ実行基盤201には存在せず、215で示すように、新バージョンのアプリ実行基盤201にのみに存在する。

202は、アプリ管理フレームワークである。アプリインストール制御モジュール220は、アプリのインストール、及び、アップデートを実行するためのものである。アプリインストール制御モジュール220は、アプリのインストールやアップデート時に、アプリインストール用ファイルをアプリキャッシュ203へ展開する。
互換対応モジュール221は、アプリのインストール時にアプリの互換対応を行うためのものである。

203は、アプリキャッシュである。アプリ用区画230は、アプリインストール用ファイルをアプリキャッシュ203に展開するためのものである。通常一つのアプリ用区画は、一つのアプリ用ディレクトリを意味する。ここで、アプリは１個、または複数個インストールされることができる。ここでは、Ｎ個のアプリがインストールされている状態を例示する。これ以降、便宜上、アプリ１用区画を230(1)、アプリ２用区画を230(2)、アプリＮ用区画を230(N)で表す。順序を特に指定せずアプリ用区画を表す場合には、単に230で表す。

図２Ａ（ｂ）は、アプリ実行環境200にインストールされるアプリのアプリインストール用ファイルの一般的な構成を説明する図である。
240は、アプリインストール用ファイルである。アプリインストール用ファイル240は、マニフェストファイル241、いくつかの実行コードファイル242、いくつかのライブラリ実行コード243を内包している。

実行コードファイル242は、実際に実行されるべきプログラムコードを保持しているファイルである。一般的にこのファイルは、ソフトウェア的な単位であるクラスごとに一つのファイル（クラス（class）ファイル）になっている。クラスファイルの中身は、バイトコードと呼ばれる中間形式となっている。
ライブラリ実行コード243も、マニフェストファイル、いくつかの実行コードファイルから成る。

図２Ｂ（ｃ）は、アプリ実行環境200におけるアプリキャッシュ203にアプリが保持されている状態を説明する図である。
アプリキャッシュ203は、ＨＤＤ104上に確保されている。アプリ１用区画230(1)は、アプリキャッシュ203に生成されたアプリ１用ディレクトリ251以下で示される。

dataフォルダ252は、アプリ１が利用するデータを置くディレクトリを示す。
アプリ１インストール用ファイル253は、インストールされたアプリ１のアプリインストールファイル240から展開され配置されたものである。
ライブラリ実行コード254は、アプリインストール用ファイル240のライブラリ実行コード243を抜き出して配置されものである。

図２Ｂ（ｄ）は、本実施例のアプリ実行環境200における実行コードファイル242の内部構造を説明する図である。
261は、マジックナンバーである。このマジックナンバー261は、実行コードファイル242を識別するために用いられる。
262は、実行コードファイル242のバージョンである。

263は、定数プールである。
265は、定数プール263内の定数定義である。定数プール263には、１個または複数の定数定義265が置かれる。
266は、定数定義265のうち定数を記述している定数記述子の部分である。
267は、定数定義265のうち定数の値を記述している定数値の部分である。
264は、実行コードの本体であるコードを記述するコード記述部分である。

図３Ａ、図３Ｂを用いて、アプリ実行環境200の新バージョンにおいて、第一のクラス212を利用しているアプリが、代わりに第二のクラス214を用いて、旧バージョンとの互換を保つ方法について説明する。

図３Ａは、アプリが実行基盤ライブラリモジュール211の第一のクラス212を利用するときの実行コードファイル242を説明する図である。
JAVAの場合、ソース上で、利用したいクラスについて、クラスのパッケージ名.クラス名としてimport宣言を行う。このソースをコンパイルして作成される実行コードファイル242には、定数プール263に、図２Ｂ（ｄ）に示した定数値267として、300のように、上記パッケージ名.クラス名が記載される。具体的には、第一のクラス212が"legacy.class.System"である場合、図３Ａ（ａ）の300で示すように、定数値267として、"legacy.class.System"が記載される。

なお、互換用サポートライブラリモジュール213に含まれる第二のクラス214を"inheritclass.System"とする。アプリにおいて、この第一のクラス212に関わる旧バージョンとの互換性を保つために第二のクラス214を利用したい場合は、この定数値267に記載されている300の"legacy.class.System"を"inheritclass.System"に置き換えることにより、第二のクラス214が利用可能となる。この置き換えは、互換対応モジュール221によってインストール時に、適切な実行コードファイル242に対して実行される。これについては、図６のフローチャートで説明する。

図３Ａ（ｂ）は、旧バージョンにおけるアプリ実行環境200において、第一のクラス212（"legacy.class.System"）が持つ互換対応が必要なget( )メソッドについて説明する図である。

301で示すように、旧バージョンのアプリ実行環境200においては、第一のクラス212のget( )というメソッドに対して"legacy.prop"という文字列を与えることにより、アプリが必要な値であるValueAを獲得していた。以下"legacy.prop"という文字列を「非互換引数Ａ」と呼ぶ。

図３Ａ（ｃ）は、新バージョンにおけるアプリ実行環境200において、第一のクラス212のget( )メソッドについて説明する図である。

302に示すように、新バージョンのアプリ実行環境200においては、非互換引数Ａをget( )に与えると、旧バージョンで得られたものと全く違う値であるValueBが返ってくるようになった。これは、アプリが想定している値ではない。よって、代替手段として、アプリ実行環境200の新バージョンでは、"alternative.prop"という文字列を用意する。以下"alternative.prop"という文字列を「互換引数Ｂ」と呼ぶ。アプリは、get( )に対して互換引数Ｂを与えることにより、旧バージョンで非互換引数Ａにより得られていた値であるValueAを得ることができる。このように、アプリ実行環境のバージョン変更に、アプリ自身が対応する場合には、互換引数Ｂを使用することで、互換性の問題を回避できる。

しかし、アプリ実行環境のバージョン変更に、アプリ自身が対応しない場合は、次に示すように、互換対応モジュール221が、実行コードファイル242の定数値267を第一のクラス212のクラス名（例えば図３Ａ（ａ）の300の"legacy.class.System"）から第二のクラス214のクラス名への書き換えることで対応が可能である。

図３Ａ（ｄ）は、"inheritclass.System"クラスのget( )メソッドについて具体的なコードを例示する図である。
"inheritclass.System"クラスのget( )メソッドでは、303で示すように、引数に「非互換引数Ａ」である"legacy.prop"が渡された時は、ValueAを戻り値として戻す。それ以外の引数が渡された時は、第一のクラスである"legacy.class.System"のget( )メソッドを呼び出す。これにより、「非互換引数Ａ」を考慮したget( )メソッドについての旧バージョンからの互換性が保たれる。

図３Ｂ（ｅ）は、旧バージョンと同じ動作を期待するアプリの実行コードファイル242の書き換えについて説明する図である。
304は、すでに新バージョンに対応済みのアプリを示している。すなわち、第一のクラス212のget( )に対して互換引数Ｂ（上記例では"alternative.prop"）を引き渡すことで互換性を確保している。そのようなアプリの実行コードファイル242では、互換引数Ｂが定数プール263の文字列定数として保持されることになる。従って、304で示すような定数プール263に第一のクラス212のクラス名（上記例では"legacy.class.System"）があっても互換引数Ｂの文字列が保持されている実行コードファイル242については、クラス名の書き換えは不要である。

一方、305で示すような定数プール263に第一のクラス212のクラス名があり、更に文字列定数として互換引数Ｂを持っていない実行コードファイル242については、アプリ実行環境のバージョン変更にアプリ自身が対応していないため、クラス名の書き換えが必要になる。

図４は、図３Ｂ（ｅ）の305で示した実行コードファイル242の定数プールの書き換えが必要なアプリをインストールした場合のインストール後のキャッシュの構成を説明する図である。

アプリは、後述するインストール処理により、互換対応モジュール221によって、図４のようなキャッシュ構成で配置される。このとき、図２Ｂ（ｃ）で示したキャッシュの構成に加え、図３Ａで示した第二のクラス214である"inheritclass.System"クラスが、アプリ用インストールファイルフォルダ253の直下に配置される。具体的には、このパスに従い、400のように、inheritclassフォルダの直下にSystem.classが配置される。

図５は、図３Ｂ（ｅ）の305で示した実行コードファイル242の定数プールの書き換えを実行するために、互換対応モジュール221が保持する、差し替え条件テーブル500を例示する図である。差し替え条件テーブル500は、例えばＨＤＤ104に記憶されている。

501は、実行コードファイル242の差し替えが必要かどうかを判断するためのキーワードである差し替え条件キーワード１を示す。この差し替え条件キーワード１がある実行コードファイル242が差し替え対象候補となる。本実施例の場合、「非互換引数Ａ」であるlegacy.propをもつ実行コードファイル242が差し替え候補となる。

502は、実行コードファイル242の差し替えが必要かどうかを判断するためのキーワードである差し替え条件キーワード２を示す。この差し替え条件キーワード２をもつ実行コードファイル242は、差し替え対象候補とはならない。本実施例の場合、「非互換引数Ｂ」であるalternative.propをもつ実行コードファイル242は差し替え候補とならない。

503は、定数プール263の改変対象とするキーワードを示す。本実施例の場合、第一のクラス212のクラス名であるlegacy.class.Systemが改変対象キーワードとなる。
504は、改変対象キーワード503に対応した改変後のキーワードを示す。本実施例の場合、第二のクラス214のクラス名であるinheritclass.Systemが改変後キーワードとなる。

505は、図４で示したアプリインストール後のアプリキャッシュ203配下のアプリインストール用ファイルフォルダ253配下に、クラスファイルを差し込むときの、ファイルのパスを含んだクラス名を示す。本実施例の場合、inheritclass/System.classとなる。

図６は、アプリ実行環境200におけるアプリインストール処理時にアプリインストール制御モジュール220及び互換対応モジュール221が行う、互換対応を含むインストール処理を説明するフローチャートである。すなわち、このフローチャートの処理は、ＣＰＵ101がＲＯＭ102又はＨＤＤ104に格納されたプログラムを必要に応じてＲＡＭ103にロードして実行することにより実現されるものである。

まず、S600において、アプリインストール制御モジュール220がインストール処理を開始する。
S601において、アプリインストール制御モジュール220は、インストールファイルであるｊａｒファイルを、図２Ｂ（ｃ）で示したようにアプリキャッシュ203にアプリ用ディレクトリ（例えばアプリ１用区画230(1)）を作成して配置する。この後、アプリキャッシュ203に配置されたインストールファイルセットに対して、互換対応モジュール221が処理を進める。

S602〜S609の動作＃1によって、互換対応モジュール221は、改変対象とするクラスがどれかを判断し、図７に示す改変対象クラスリストテーブル700を作成する。
具体的には、互換対応モジュール221は、S602〜S609において、上記S601で配置したファイル内にある全てのクラスファイルを対象としたループ処理を行うように制御する。互換対応モジュール221は、上記S601で配置したファイル内にある未処理のクラスファイルを１つ処理対象に選択し（以下「現在の処理対象クラスファイル」という）、S603に処理を進める。

次に、S603において、互換対応モジュール221は、現在の処理対象クラスファイルの全てのデータ（本実施例ではバイトコード）を取得する。

次に、S604〜S608において、互換対応モジュール221は、図５で示した、差し替え条件テーブル500の全てのレコードを対象としたループ処理を行うように制御する。互換対応モジュール221は、差し替え条件テーブル500内の未処理のレコードを１つ処理対象に選択し（以下「現在のレコード」という）、S605に処理を進める。

S605において、互換対応モジュール221は、上記S603において取得したバイトコードが、現在のレコードの差し替え条件キーワード１（501）を満たすデータを含み、かつ、差し替え条件キーワード２（502）を満たすデータを含まないという差し替え条件を満たすか否かを判断する。そして、この差し替え条件を満たさないと判断した場合（S605でNOの場合）、互換対応モジュール221は、そのままS608に処理を進める。

一方、上記差し替え条件を満たすと判断した場合（S605でYESの場合）、互換対応モジュール221は、S606に処理を進める。
S606において、互換対応モジュール221は、上記S603において取得したバイトコードが、現在のレコードの改変対象キーワード503を含むかどうかを判断する。そして、上記改変対象キーワード503を含まないと判断した場合（S606でNOの場合）、互換対応モジュール221は、そのままS608に処理を進める。

一方、上記改変対象キーワード503を含むと判断した場合（S606でYESの場合）、互換対応モジュール221は、S607に処理を進める。
S607において、互換対応モジュール221は、図７に示す改変対象クラスリストテーブル700に、現在の処理対象クラスファイルに対応するクラスを、上記改変対象キーワード503に対応する改変対象クラスとして追加する。

ここで、図７で示す改変対象クラスリストテーブル700について説明する。
図７は、改変対象クラスリストテーブル700を例示する図である。なお、改変対象クラスリストテーブル700は、例えばＲＡＭ103に記憶されている。

改変対象キーワード701には、図６のS606の条件で判定した改変対象キーワード503が、互換対応モジュール221により追加される。一方、改変対象クラスリスト702には、改変対象と判断した現在の処理対象クラスファイルに対応するクラス名が互換対応モジュール221により追加される。以下、図６のフローチャートの説明に戻る。

S608において、互換対応モジュール221は、差し替え条件テーブル500の全てのレコードを対象としたS604〜S608のループ処理を完了したか否かを判断する。そして、まだS604〜S608のループ処理を完了していないと判断した場合、互換対応モジュール221は、S604に処理を戻しループ処理を継続する。

一方、S604〜S608のループ処理を完了したと判断した場合、互換対応モジュール221は、S609に処理を進める。

S609において、互換対応モジュール221は、上記S601で配置したファイル内にある全てのクラスファイルを対象としたS602〜S609のループ処理を完了したか否かを判断する。そして、まだS602〜S609のループ処理を完了していないと判断した場合、互換対応モジュール221は、S602に処理を戻しループ処理を継続する。

一方、S602〜S609のループ処理を完了したと判断した場合、互換対応モジュール221は、S610に処理を進める。

図７の例では、上記＃1の処理によって、改変対象キーワード701に、legacy.class.Systemが追加されている。また、それに対応する改変対象クラスリスト702に、A.classとB.classが改変対象クラスとして追加されている。よって、以降の＃2の処理では、この改変対象クラスリスト702に追加されたA.classとB.classの実行コードファイル242を書き変え対象と考える。

次に、S610〜S619の動作＃2によって、互換対応モジュール221が、改変対象クラスリストテーブル700に登録された改変対象クラスに対して、実行コードファイル242の書き換え処理と、アプリキャッシュ203に互換用クラスの実体の追加処理を行う。

まず、S610〜S616において、互換対応モジュール221は、上記S601で配置したファイル内にある全てのファイルを対象としたループ処理を行うように制御する。互換対応モジュール221は、上記S601で配置したファイル内にある未処理のファイルを１つ選択し（以下「処理対象ファイル」という）、S611に処理を進める。

S611において、互換対応モジュール221は、上記処理対象ファイルがクラスファイルかどうかを判断する。そしてクラスファイルでないと判断した場合（S611でNOの場合）、互換対応モジュール221は、そのままS616に処理を進める。

一方、上記処理対象ファイルがクラスファイルであると判断した場合（S611でYESの場合）、互換対応モジュール221は、該処理対象ファイルを現在の処理対象クラスファイルとし、S612に処理を進める。

S612〜S615において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対してループ処理を行うように制御する。互換対応モジュール221は、未処理の改変対象クラスリスト702を１つ選択し（以下「処理対象の改変対象クラスリスト702」という）、S613に処理を進める。

S613において、互換対応モジュール221は、上記処理対象の改変対象クラスリスト702に現在の処理対象クラスが含まれるかどうかを判断する。そして、上記処理対象の改変対象クラスリスト702に現在の処理対象クラスファイルに対応するクラスが含まれていないと判断した場合（S613でNOの場合）、互換対応モジュール221は、そのままS615に処理を進める。

一方、上記処理対象の改変対象クラスリスト702に現在の処理対象クラスファイルに対応するクラスが含まれていると判断した場合（S613でYESの場合）、互換対応モジュール221は、S614に処理を進める。

S614において、互換対応モジュール221は、上記処理対象の改変対象クラスリスト702に対応する改変対象キーワード701をキーとして、現在の処理対象クラスファイルのバイトコードを検索し、該検索された改変対象キーワードに対応するバイトコードを、差し替え条件テーブル500における上記改変対象キーワードに対応した改変後キーワード504のバイトコードに改変して書き込む。本実施例では、現在の処理対象クラスファイル内のlegacy.class.Systemをinheritclass.Systemに書き換える処理を行う。

次に、S615において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対するS612~S615のループ処理を完了したか否かを判断する。そして、まだS612~S615のループ処理を完了していないと判断した場合、互換対応モジュール221は、S612に処理を戻しループ処理を継続する。

一方、S612~S615のループ処理を完了したと判断した場合、互換対応モジュール221は、S616に処理を進める。

S616において、互換対応モジュール221は、上記S601で配置した全てのファイルを対象としたS610〜S616のループ処理を完了したか否かを判断する。そして、まだS610〜S616のループ処理を完了していないと判断した場合、互換対応モジュール221は、S610に処理を戻しループ処理を継続する。

一方、S610〜S616のループ処理を完了したと判断した場合、互換対応モジュール221は、S617に処理を進める。

次に、S617〜S619において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対してループ処理を行うように制御する。互換対応モジュール221は、未処理の改変対象クラスリスト702を１つ選択し（以下「現在の改変対象クラスリスト702」という）、S618に処理を進める。

S618において、互換対応モジュール221は、上記現在の改変対象クラスリスト702に対応する改変対象キーワード701をキーとして、差し替え条件テーブル500における改変対象キーワード503を検索し、該検索結果に対応する差し込み対象とする互換用クラス505を、互換用サポートライブラリモジュール213の第二のクラス214からコピーして、アプリキャッシュ203の対応するアプリ用区画230に差し込む。本実施例では、これにより図４で示した第二のクラス214であるSystem.classが、inheritclass/System.class（400）として、アプリインストール用ファイルフォルダ253以下に差し込まれる。

次に、S619において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対するS617~S619のループ処理を完了したか否かを判断する。そして、まだS617~S619のループ処理を完了していないと判断した場合、互換対応モジュール221は、S617に処理を戻しループ処理を継続する。

一方、S617~S619のループ処理を完了したと判断した場合、互換対応モジュール221は、本インストール処理を終了する（S620）。
以上、実施例１で示した構成により、具体的には以下に示すような効果を得ることができる。

〔効果事例１〕
旧バージョンのアプリ実行環境200の実行基盤ライブラリモジュール211の第一のクラス212を利用していたアプリを、新バージョンのアプリ実行環境200にインストールする時に、互換のために用意された第二のクラス214を利用するために実行コードファイル242の定数プール263の定数値267を第二のクラス214に書き変えるのに加えて、アプリキャッシュ203のアプリ用区画にその参照先である第二のクラス214の実体を差し込む。すなわち、互換対応モジュール221が、アプリのインストールに関するタイミングで、旧バージョンのアプリ実行環境で動作可能なアプリを新バージョンのアプリ実行環境で動作させるための互換対応として、該アプリにおいて第一のクラス（新旧バージョン間の差異に関わるクラス）を参照する箇所を、第二のクラス（新旧バージョン間の差異を補完するクラス）の参照に変更し、また、該アプリに第二のクラスの実体を追加する。こうすることで、アプリインストール後に、新バージョンのアプリ実行環境200から、旧バージョンのアプリ実行環境200に戻すようなケースにおいても、互換のために手を加えた実行コードファイル242をそのまま（修正することなく）利用することが可能となる。

上記実施例１では、新バージョンのアプリ実行環境200にアプリをインストールする場合に（すなわちアプリのインストールに関するタイミングで）、新旧バージョンのアプリケーションの実行環境の差異に依る互換性を考慮したインストール処理について説明した。しかし、アプリ実行環境200には旧バージョンが存在しており、すでに旧バージョンにおいて複数のアプリがインストールされた状態で稼働していることが想定される。本実施例２では、そのようなアプリ実行環境200の旧バージョンが更新され、新バージョンのアプリ実行環境200に移行（以降、これを「ファームアップ」という）した時に、新バージョンで初めて起動された時に実行される処理について述べる。

図８は、アプリ実行環境200を更新後に初めて起動する時にアプリインストール制御モジュール220及び互換対応モジュール221が実施するアップグレード処理を説明するフローチャートである。すなわち、このフローチャートの処理は、ＣＰＵ101がＲＯＭ102又はＨＤＤ104に格納されたプログラムを必要に応じてＲＡＭ103にロードして実行することにより実現されるものである。

まず、S800において、互換対応モジュール221がファームアップ処理を開始する。
S801において、インストール制御モジュール220は、アプリキャッシュ203配下にある全てのアプリをアップデートする。

次に、互換対応モジュール221は、S802〜S804において、上記S801でアップデートされたアプリキャッシュ203配下の全てのアプリ用区画を対象としたループ処理を行うように制御する。互換対応モジュール221は、未処理のアプリ用区画を１つ処理対象に選択し（以下「現在の処理対象のアプリ用区画」という）、S803に処理を進める。

S803において、互換対応モジュール221は、現在の処理対象のアプリ用区画配下にある全てのｊａｒファイルに対して（すなわちインストール済のアプリに対して）、図６で示した差し替え処理を実行する。ここでの差し替え処理は、現在の処理対象のアプリ用区画配下にある各ｊａｒファイルに対して、図６で示したS602〜S609の動作＃1、及び、S610〜S619の動作＃2を行うものであり、図６で示した処理と同一のため説明を省略する。

次に、S804において、互換対応モジュール221は、上記S801でアップデートされたアプリキャッシュ203配下の全てのアプリ用区画を対象としたS802〜S804のループ処理を完了したか否かを判断する。そして、S802〜S804のループ処理を完了していないと判断した場合、互換対応モジュール221は、S802に処理を戻しループ処理を継続する。

一方、S802〜S804のループ処理を完了したと判断した場合、互換対応モジュール221は、本ファームアップ処理を終了する（S805）。

〔効果事例２〕
旧バージョンのアプリ実行環境200の実行基盤ライブラリモジュール211において、第一のクラス212を利用していたアプリがインストールされているとする。新バージョンのアプリ実行環境200にファームアップする時に、互換のために用意された第二のクラス214を利用するために、インストールされているアプリの実行コードファイル242の定数プール263の定数値267を第二のクラス214に書き変えるのに加えて、アプリキャッシュ領域203のアプリ用区画にその参照先である第二のクラス214の実体を差し込む。こうすることで、新バージョンのアプリ実行環境200にファームアップした後に、旧バージョンのアプリ実行環境200に戻すようなケースにおいても、互換のために手を加えた実行コードファイル242をそのまま利用することが可能となる。

本実施例３においては、新たに、更なる新バージョン（以降、これをV3.0とする）のアプリ実行環境200がリリースされた時のことを考える。さらに、このV3.0のアプリ実行環境200がもつ、実行基盤ライブラリモジュールの第一のクラスが、旧バージョンV1.0の第一のクラスと同じ動きに戻ったとする。より具体的に説明すると、図３Ａ（ｂ）の301と同様に、V3.0のアプリ実行環境200においては、第一のクラス212のget( )というメソッドに対して非互換引数Ａである"legacy.prop"という文字列を与えたときに、アプリが必要な値であるValueAを獲得できるようになっているものとする。すなわち、V3.0のアプリ実行環境200は、第一のクラスについて、旧バージョンとしてV1.0と互換性を有する。

上述した実施例１のインストール処理又は実施例２のファームアップ処理の実行後、アプリは、アプリキャッシュ203配下に互換用の第二のクラス214が差し込まれたままの状態である。また、アプリの実行コードファイルも第二のクラスを利用するように書き換えられたままの状態である。

本実施例３では、この状態から、V3.0のアプリ実行環境200にファームアップするときのことを考える。このとき、アプリは、そのままでも動作可能である。しかし、アプリがget( )メソッドを利用する場合、非互換引数Ａ以外は、図３Ａ（ｄ）の303で示したように、一旦、第二のクラス214を経由して、第一のクラス212のget( )メソッドを利用することになる。そのため、パフォーマンス的に不利となる可能性がある。V3.0のアプリ実行環境200においては、第一のクラスのget( )メソッドが直接利用可能になっているのであれば、実施例１又は実施例２で互換対応したアプリを互換対応前の状態に戻すことが望ましい。そのための、実施例３のファームアップ方法を以下に述べる。

図９は、ファームアップ時に、アプリの互換対応を元に戻すために、互換対応モジュール221が保持する削除条件テーブル900を例示する図である。削除条件テーブル900は、例えばＨＤＤ104に記憶されている。

901は、参照先を元に戻すための定数プール263の改変対象とするキーワードである改変対象キーワードを示す。図９に示す例では、第二のクラス214のクラス名であるinheritclass.Systemが改変対象キーワード901となる。

902は、参照先を元に戻すための改変対象キーワード901に対応した改変後のキーワードである改変後キーワードを示す。図９に示す例では、第一のクラス212のクラス名であるlegacy.class.Systemが改変後キーワード902となる。

903は、削除対象となる、図４の400で示した、アプリインストール後のアプリキャッシュ203配下のアプリインストール用ファイルフォルダ253配下に差し込んだファイルのパスを含んだクラス名である削除対象とする互換用クラスを示す。図９に示す例では、inheritclass/System.classが削除対象とする互換用クラス903となる。

ファームアップ時の全体フローは、図８で示したフローと同じである。ただし、S803において、図６の差し替え処理の代わりに、アプリを互換対応前の状態に戻す処理（図１０）を行う。

図１０は、V3.0のアプリ実行環境200にファームアップ時に、互換対応モジュール221が行う、互換対応したアプリを互換対応前の状態に戻す処理を説明するフローチャートである。このフローチャートの処理は、ＣＰＵ101がＲＯＭ102又はＨＤＤ104に格納されたプログラムを必要に応じてＲＡＭ103にロードして実行することにより実現されるものである。

まず、S1000において、互換対応モジュール221が互換対応前に戻す処理を開始する。
S1001〜S1007において、互換対応モジュール221は、図８のS802〜S804のループ処理における「現在の処理対象のアプリ用区画」内にある全てのクラスファイルを対象としたループ処理を行うように制御する。互換対応モジュール221は、現在の処理対象のアプリ用区画内にある未処理のクラスファイルを１つ処理対象に選択し（以下「現在の処理対象クラスファイル」という）、S1002に処理を進める。

次に、S1002において、互換対応モジュール221は、現在の処理対象クラスファイルの全てのデータ（本実施例ではバイトコード）を取得する。

次に、S1003〜S1006において、互換対応モジュール221は、図９で示した、削除条件テーブル900の全てを対象としたループ処理を行う。互換対応モジュール221は、削除条件テーブル900にある未処理のレコードを１つ処理対象に選択し（以下「現在のレコード」という）、S1004に処理を進める。

S1004において、互換対応モジュール221は、上記S1002において取得したバイトコードが、現在のレコードの改変対象キーワード901を含むか否かを判断する。そして、上記S1002において取得したバイトコードが現在のレコードの改変対象キーワード901を含まないと判断した場合（S1004でNOの場合）、互換対応モジュール221は、そのままS1006に処理を進める。

一方、上記S1002において取得したバイトコードが現在のレコードの改変対象キーワード901を含むと判断した場合（S1004でYESの場合）、互換対応モジュール221は、S1005に処理を進める。

S1005において、互換対応モジュール221は、図７に示す改変対象クラスリストテーブル700に現在の処理対象クラスファイルに対応するクラスを、改変対象クラスとして追加する。

次に、S1006において、互換対応モジュール221は、削除条件テーブル900の全てのレコードを対象としたS1003〜S1006のループ処理を完了したか否かを判断する。そして、まだS1003〜S1006のループ処理を完了していないと判断した場合、互換対応モジュール221は、S1003に処理を戻しループ処理を継続する。

一方、S1003〜S1006のループ処理を完了したと判断した場合、互換対応モジュール221は、S1007に処理を進める。

S1007において、互換対応モジュール221は、現在の処理対象のアプリ用区画内にある全てのクラスファイルを対象としたS1001〜S1007のループ処理を完了したか否かを判断する。そして、まだS1001〜S1007のループ処理を完了していないと判断した場合、互換対応モジュール221は、S1001に処理を戻しループ処理を継続する。

一方、S1001〜S1007のループ処理を完了したと判断した場合、互換対応モジュール221は、S1008に処理を進める。

次に、S1008〜S1014の動作によって、互換対応モジュール221が、改変対象クラスリストテーブル700に登録された改変対象クラスに対して、改変処理と、アプリキャッシュ203配下にある互換用クラスの実体の削除処理を行う。

まず、S1008〜S1014において、互換対応モジュール221は、現在の処理対象のアプリ用区画内のアプリファイル内にある全てのファイルを対象としたループ処理を行うように制御する。互換対応モジュール221は、アプリファイル内にある未処理のファイルを１つ選択し（以下「処理対象ファイル」という）、S1009に処理を進める。

S1009において、互換対応モジュール221は、上記処理対象ファイルがクラスファイルかどうかを判断する。そしてクラスファイルでないと判断した場合（S1009でNOの場合）、互換対応モジュール221は、そのままS1014に処理を進める。

一方、上記処理対象ファイルがクラスファイルであると判断した場合（S1009でYESの場合）、互換対応モジュール221は、該処理対象ファイルを現在の処理対象クラスファイルとし、S1010に処理を進める。

S1010〜S1013において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対してループ処理を行うように制御する。互換対応モジュール221は、未処理の改変対象クラスリスト702を１つ選択し（以下「処理対象の改変対象クラスリスト702」という）、S1011に処理を進める。

S1011において、互換対応モジュール221は、上記処理対象の改変対象クラスリスト702に、現在の処理対象クラスファイルに対応するクラスが含まれるかどうかを判断する。そして、上記処理対象の改変対象クラスリスト702に現在の処理対象クラスファイルに対応するクラスが含まれていないと判断した場合（S1011でNOの場合）、互換対応モジュール221は、そのままS1013に処理を進める。

一方、上記処理対象の改変対象クラスリスト702に現在の処理対象クラスファイルに対応するクラスが含まれていると判断した場合（S1011でYESの場合）、互換対応モジュール221は、S1012に処理を進める。

S1012において、互換対応モジュール221は、上記処理対象の改変対象クラスリスト702に対応する改変対象キーワード701をキーとして、現在の処理対象クラスファイルのバイトコードを検索し、該検索された改変対象キーワードに対応するバイトコードを、削除条件テーブル900における上記改変対象キーワードに対応した改変後キーワード902のバイトコードに改変して書き込む。本実施例では、現在の処理対象クラスファイル内のinheritclass.Systemをlegacy.class.Systemに書き換える処理を行う。

次に、S1013において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対するS1010~S1013のループ処理を完了したか否かを判断する。そして、まだS1010~S1013のループ処理を完了していないと判断した場合、互換対応モジュール221は、S1010に処理を戻しループ処理を継続する。

一方、S1010~S1013のループ処理を完了したと判断した場合、互換対応モジュール221は、S1014に処理を進める。

S1014において、互換対応モジュール221は、現在の処理対象のアプリ用区画内のアプリファイル内にある全てのファイルを対象としたS1008〜S1014のループ処理を完了したか否かを判断する。そして、まだS1008〜S1014のループ処理を完了していないと判断した場合、互換対応モジュール221は、S1008に処理を戻しループ処理を継続する。

一方、S1008〜S1014のループ処理を完了したと判断した場合、互換対応モジュール221は、S1015に処理を進める。

次に、S1015〜S1017において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対してループ処理を行うように制御する。互換対応モジュール221は、未処理の改変対象クラスリスト702を１つ選択し（以下「現在の改変対象クラスリスト702」という）、S1016に処理を進める。

S1016において、互換対応モジュール221は、上記現在の改変対象クラスリスト702に対応する改変対象キーワード701をキーとして、削除条件テーブル900における改変対象キーワード901を検索し、該検索された改変対象キーワード901に対応する削除対象とする互換用クラス903を、アプリキャッシュ203の対応するアプリ用ディレクトリ（アプリ用区画230）の中から探索して、削除する。本実施例では、これにより図４で示した第二のクラス214であるinheritclass/System.class（400）が、アプリインストール用ファイルフォルダ253から削除される。

次に、S1017において、互換対応モジュール221は、改変対象クラスリストテーブル700内の全ての改変対象クラスリスト702に対するS1015〜S1017のループ処理を完了したか否かを判断する。そして、まだS1015〜S1017のループ処理を完了していないと判断した場合、互換対応モジュール221は、S1015に処理を戻しループ処理を継続する。

一方、S1015〜S1017のループ処理を完了したと判断した場合、互換対応モジュール221は、本互換対応前の状態に戻す処理を終了する（S1018）。
以上、実施例３で示した方法により、具体的には以下に示すような効果を得ることができる。

〔効果事例３〕
V3.0のアプリ実行環境200にファームアップ時に、アプリを互換対応前の状態に戻すことで、互換対応のために犠牲になる可能性があったパフォーマンスの劣化を防ぐことが可能となる。

以上の各実施例では、本発明の情報処理装置の一例として画像形成装置を用いて説明したが、本発明の情報処理装置は画像形成装置に限定されるものではない。図２Ａ（ａ）に示したような所定のアプリケーション実行環境（例えばJAVA環境）を構築可能な情報処理装置であればどのような情報処理装置であってもよい。例えば、パーソナルコンピュータでも、タブレット端末、スマートフォン、各種家電、ナビゲーションシステム、カメラ等でも、上述のようなアプリケーション実行環境を構築可能であれば、本発明を適用可能である。

また、上記各実施例では、アプリ実行環境を旧バージョンから新バージョンに変更する場合等に本発明を適用する場合について説明した。しかし、アプリ実行環境の変更は、旧バージョンから新バージョンへの変更に限定するものではなく、バージョン変更に限定されない異なるアプリ実行環境への変更についても本発明を適用可能である。

以上、本発明によれば、新しいバージョンのアプリ実行環境に合わせるために用意された互換用クラスを、新しいアプリ実行環境にアプリをインストールしたとき等にアプリ自身の中に差し込む処理を行うことにより、アプリを新バージョンのアプリ実行環境に合わせる互換対応を入れた後に、再度、旧バージョンのアプリ実行環境に戻した場合でも、アプリに手を入れることなく、問題なく動作し、使い続けることが可能となる仕組みを提供することができる。よって、アプリを新バージョンのアプリ実行環境に合わせる互換対応を入れた後に、再度、旧バージョンのアプリ実行環境に戻した場合でも、アプリを改めて旧バージョンのアプリ実行環境に合わせこむための複雑な戻し作業が不要となる。この結果、JAVA環境に代表されるようなアプリ動作環境で動作するアプリの保守管理を容易にし、保守管理コストを低減することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
（その他の実施例）
本発明は、上述の実施例の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

200 アプリ実行環境
212 第一のクラス
214 第二のクラス
220 アプリインストール制御モジュール
221 互換対応モジュール
203 アプリキャッシュ

Claims (11)

1. 所定のアプリケーション実行環境を構築可能な情報処理装置であって、
   第１のアプリケーション実行環境との非互換性を含む第２のアプリケーション実行環境において、前記第１のアプリケーション実行環境との非互換性に関わる第１クラスの代替となり、前記非互換性を補完する第２クラスの実体を保持する保持手段と、
   前記第１のアプリケーション実行環境で動作可能なアプリケーションを前記第２のアプリケーション実行環境で動作させるための前記非互換性に関わる対応を行う第１対応手段と、を有し、
   前記第１対応手段は、前記対応として、該アプリケーションにおいて前記第１クラスを利用する箇所を前記第２クラスの利用に変更し、また、該アプリケーションに前記保持手段に保持される前記第２クラスの実体を追加することを特徴とする情報処理装置。
2. 前記第１対応手段は、前記アプリケーションに前記第１クラスを利用する箇所が存在する場合であっても、該アプリケーションにおいて前記第１クラスを利用する場合に用いる第１定数値の代替となる第２定数値を用いる箇所が存在する場合には、前記対応を行わないことを特徴とする請求項１に記載の情報処理装置。
3. 前記第１対応手段は、前記アプリケーションのインストールに関するタイミングで、該アプリケーションに対して、前記対応を行うことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第１対応手段は、アプリケーション実行環境が前記第１のアプリケーション実行環境から前記第２のアプリケーション実行環境に変更された場合に、インストール済のアプリケーションに対して、前記対応を行うことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記対応の前の状態に戻す処理として、インストール済のアプリケーションにおいて前記第２クラスを利用する箇所を前記第１クラスの利用に変更する第２対応手段を有することを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記第２対応手段は、前記処理として、さらに、該アプリケーションから、前記第２クラスの実体を削除することを特徴とする請求項５に記載の情報処理装置。
7. 前記第２対応手段は、アプリケーション実行環境が前記第２のアプリケーション実行環境から、前記第１クラスについて前記第１のアプリケーション実行環境と互換性が有る第３のアプリケーション実行環境に変更された場合に、前記処理を行うことを特徴とする請求項５又は６に記載の情報処理装置。
8. 前記第１のアプリケーション実行環境は、旧バージョンのアプリケーション実行環境であり、前記第２のアプリケーション実行環境は、新バージョンのアプリケーション実行環境であることを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
9. 前記アプリケーション実行環境は、JAVA環境であることを特徴とする請求項１〜８のいずれか１項に記載の情報処理装置。
10. 所定のアプリケーション実行環境を構築可能であり、第１のアプリケーション実行環境との非互換性を含む第２のアプリケーション実行環境において、前記第１のアプリケーション実行環境との非互換性に関わる第１クラスの代替となり、前記非互換性を補完する第２クラスの実体を保持する保持手段を有する情報処理装置の制御方法であって、
    前記第１のアプリケーション実行環境で動作可能なアプリケーションを前記第２のアプリケーション実行環境で動作させるための前記非互換性に関わる対応として、該アプリケーションにおいて前記第１クラスを利用する箇所を前記第２クラスの利用に変更するステップと、
    該アプリケーションに、前記保持手段に保持される前記第２クラスの実体を追加するステップと、
    を有することを特徴とする情報処理装置の制御方法。
11. コンピュータを、請求項１〜９のいずれか１項に記載の手段として機能させるためのプログラム。

Images