(57)【要約】      （修正有）【課題】アプリケーション（アプリ）実行環境における非互換性を解消する。【解決手段】第１の実行環境上で動作するアプリを第１の実行環境と一部が非互換の第２の実行環境で実行する情報処理装置は、第１の実行環境と非互換の第２の実行環境での第１のクラスを含む第１のライブラリと、第１の実行環境で非互換のクラスと互換の機能を第２の実行環境で提供する第２のクラスを含む第２のライブラリと、を格納する第１の格納手段と、情報処理装置に設定されたアプリの実行コードとマニフェストとを格納する第２の格納手段と、を有す。情報処理装置は、マニフェストを参照し、第２の実行環境でのアプリの動作互換性を判定する判定手段と、アプリが第２の実行環境で動作互換性なしと判定された場合、アプリの実行コードの第１のクラスを第２のクラスに書換える書換手段と、書換手段により書換えられた実行コードを第２の実行環境で実行する実行制御手段と、を有す。【選択図】図１
2017073036.tif 000002
【特許請求の範囲】
【請求項１】
第１の実行環境上で動作することが想定されたアプリケーションを前記第１の実行環境と少なくとも一部が非互換の第２の実行環境で実行する情報処理装置であって、
前記第１の実行環境と非互換である前記第２の実行環境における第１のクラスを含む第１のライブラリと、前記第１の実行環境における非互換のクラスと互換の機能を前記第２の実行環境において提供する第２のクラスを含む第２のライブラリと、を格納する第１の格納手段と、
前記情報処理装置にインストールされた前記アプリケーションの実行コードとマニフェストとを格納する第２の格納手段と、
前記マニフェストを参照して、前記第２の実行環境における前記アプリケーションの動作互換性を判定する判定手段と、
前記判定手段により前記アプリケーションが前記第２の実行環境における動作互換性を有していないと判定された場合、前記アプリケーションの実行コードにおける前記第１のクラスを前記第２のクラスに書き換える書換手段と、
前記書換手段による書き換えが行われた実行コードを前記第２の実行環境で実行する実行制御手段と、
を有することを特徴とする情報処理装置。
【請求項２】
第１の実行環境上で動作することが想定されたアプリケーションを前記第１の実行環境と少なくとも一部が非互換の第２の実行環境で実行する情報処理装置であって、
前記第１の実行環境と非互換である前記第２の実行環境における第１のクラスを含む第１のライブラリと、前記第１の実行環境における非互換のクラスと互換の機能を前記第２の実行環境において提供する第２のクラスを含む第２のライブラリと、を格納する第１の格納手段と、
前記情報処理装置にインストールされた前記アプリケーションの実行コードを格納する第２の格納手段と、
前記実行コードに含まれる定数プールを参照して、前記第２の実行環境における前記アプリケーションの動作互換性を判定する判定手段と、
前記判定手段により前記アプリケーションが前記第２の実行環境における動作互換性を有していないと判定された場合、前記アプリケーションの実行コードにおける前記第１のクラスを前記第２のクラスに書き換える書換手段と、
前記書換手段による書き換えが行われた実行コードを前記第２の実行環境で実行する実行制御手段と、
を有することを特徴とする情報処理装置。
【請求項３】
前記書換手段は、前記アプリケーションの実行コードにおける前記第１のクラスのクラス名の文字列を前記第２のクラスのクラス名の文字列に書き換える
ことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記第２の格納手段に格納された実行コードを、前記書換手段による書き換えが行われた実行コードに置換する置換手段と、
前記置換手段による置換前の実行コードを前記第２の格納手段に格納された実行コードのファイル名とは異なるファイル名で格納する複製格納手段と、
前記情報処理装置の終了処理の際に、前記複製格納手段に格納された実行コードのファイル名を前記第２の格納手段に格納された実行コードのファイル名に変更する変更手段と、
を更に有し、
前記変更手段は、更に、前記情報処理装置の起動処理の際に前記第２の実行環境で起動した場合、前記複製格納手段に格納された実行コードのファイル名を前記第２の格納手段に格納された実行コードのファイル名とは異なるファイル名に変更する
ことを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
【請求項５】
前記第２の格納手段に格納された実行コードを、前記書換手段による書き換えが行われた実行コードに置換する置換手段と、
前記置換手段による置換前の実行コードを格納する複製格納手段と、
前記情報処理装置の終了処理の際に、前記複製格納手段に格納された実行コードに対するハードリンクを前記第２の格納手段に格納された実行コードのファイル名で生成するリンク生成手段と、
を更に有する
ことを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
【請求項６】
前記情報処理装置が前記第２の実行環境での初回の起動であるか否かを検知する検知手段を更に有し、
前記書換手段は、前記第２の実行環境での初回の起動であると検知された場合に前記書き換えを行う
ことを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
【請求項７】
アプリケーションを前記第２の格納手段にインストールするインストール手段を更に有し、
前記インストール手段は、アプリケーションごとに前記第２の格納手段に個別の区画を作成してインストールを行い、
前記判定手段は、前記判定をアプリケーションごとに実行する
ことを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
【請求項８】
第１の実行環境上で動作することが想定されたアプリケーションを前記第１の実行環境と少なくとも一部が非互換の第２の実行環境で実行する情報処理装置の制御方法であって、
前記情報処理装置は、
前記第１の実行環境と非互換である前記第２の実行環境における第１のクラスを含む第１のライブラリと、前記第１の実行環境における非互換のクラスと互換の機能を前記第２の実行環境において提供する第２のクラスを含む第２のライブラリと、を格納する第１の格納手段と、
前記情報処理装置にインストールされた前記アプリケーションの実行コードとマニフェストとを格納する第２の格納手段と、
を有しており、
前記制御方法は、
前記マニフェストを参照して、前記第２の実行環境における前記アプリケーションの動作互換性を判定する判定工程と、
前記判定工程により前記アプリケーションが前記第２の実行環境における動作互換性を有していないと判定された場合、前記アプリケーションの実行コードにおける前記第１のクラスを前記第２のクラスに書き換える書換工程と、
前記書換工程による書き換えが行われた実行コードを前記第２の実行環境で実行する実行制御工程と、
を含むことを特徴とする情報処理装置の制御方法。
【請求項９】
第１の実行環境上で動作することが想定されたアプリケーションを前記第１の実行環境と少なくとも一部が非互換の第２の実行環境で実行する情報処理装置の制御方法であって、
前記情報処理装置は、
前記第１の実行環境と非互換である前記第２の実行環境における第１のクラスを含む第１のライブラリと、前記第１の実行環境における非互換のクラスと互換の機能を前記第２の実行環境において提供する第２のクラスを含む第２のライブラリと、を格納する第１の格納手段と、
前記情報処理装置にインストールされた前記アプリケーションの実行コードを格納する第２の格納手段と、
を有しており、
前記制御方法は、
前記実行コードに含まれる定数プールを参照して、前記第２の実行環境における前記アプリケーションの動作互換性を判定する判定工程と、
前記判定工程により前記アプリケーションが前記第２の実行環境における動作互換性を有していないと判定された場合、前記アプリケーションの実行コードにおける前記第１のクラスを前記第２のクラスに書き換える書換工程と、
前記書換工程による書き換えが行われた実行コードを前記第２の実行環境で実行する実行制御工程と、
を含むことを特徴とする情報処理装置の制御方法。
【請求項１０】
コンピュータを、請求項１乃至７の何れか１項に記載の情報処理装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置におけるアプリケーションの管理技術に関するものである。
【背景技術】
【０００２】
従来、情報処理装置上でアプリケーションを実行する為の“アプリケーション実行環境”とそこで実行される“アプリケーション”においては、アプリケーションをアプリケーション実行環境に合わせて作成することが前提であった。一方、アプリケーション実行環境においては、挙動に関する問題や新たな機能に対応する必要性から新しいバージョンが市場に導入されることがある。その際、従来の挙動との互換性が一部失われる（非互換性）場合がある。このように非互換性を含んだ新しいバージョンのアプリケーション実行環境が導入される場合、アプリケーションにおいても、アプリケーション実行環境の変化に合わせた新しいバージョンが作成されるのが通例である。これにより、新しいバージョンのアプリケーションは、新しいバージョンのアプリケーション実行環境との組合せで不具合なく動作することが可能であった。
【０００３】
しかしながら、近年では、アプリケーションの開発が大規模化し高コストとなってきている。その結果、非互換性を含んだ新しいバージョンのアプリケーション実行環境のが導入されたにも関わらず、それに沿った新しいバージョンのアプリケーションを作成するのが困難なケースがある。そこで、非互換性を含んだ新しいバージョンのアプリケーション実行環境においても既存のアプリケーションを不具合なく動作させることを実現する為の技術が提案されている。
【０００４】
例えば、特許文献１では、新しいバージョンのアプリケーション実行環境において、あらかじめ不具合を生ずる既存のアプリケーションの情報を保持するよう構成している。その上で、そのような既存のアプリケーションが読み込まれた時には、当該アプリケーションの起動前に当該アプリケーションと関連するアドレス空間に対してシムライブラリとフックライブラリを挿入する。フックライブラリは、アプリケーション中のどの位置に変更を導入すべきかの情報を有している。また、シムライブラリは、その位置に導入されるべき変更の内容を示す情報を有している。そして、当該アプリケーションの起動前に、これらのライブラリを参照して当該アプリケーションに導入する必要がある変更を特定し、特定された変更を導入する。これにより変更処理がなされたアプリケーションが起動されることになる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４８７８７１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述の従来技術においては、アプリケーション実行環境は、予めどのアプリケーションが不具合を生ずるかについての情報を全て知っている必要があり、その情報をアプリケーション実行環境が予め保持する必要がある。また、アプリケーションを不具合なく実行するために、当該アプリケーションの実行に先立って上述の変更処理を行う必要がある。更に、上述のライブラリの挿入によりリソースが無駄に費やされることがある。そのため、リソース容量や実行速度についての制限が厳しい組み込み向けのアプリケーション実行環境においては上述の従来技術の適用は困難である。
【０００７】
本発明は、このような問題に鑑みてなされたものであり、アプリケーション実行環境における非互換性をより好適に解消可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述の問題点を解決するため、本発明に係る情報処理装置は以下の構成を備える。すなわち、第１の実行環境上で動作することが想定されたアプリケーションを前記第１の実行環境と少なくとも一部が非互換の第２の実行環境で実行する情報処理装置において、前記第１の実行環境と非互換である前記第２の実行環境における第１のクラスを含む第１のライブラリと、前記第１の実行環境における非互換のクラスと互換の機能を前記第２の実行環境において提供する第２のクラスを含む第２のライブラリと、を格納する第１の格納手段と、前記情報処理装置にインストールされた前記アプリケーションの実行コードとマニフェストとを格納する第２の格納手段と、前記マニフェストを参照して、前記第２の実行環境における前記アプリケーションの動作互換性を判定する判定手段と、前記判定手段により前記アプリケーションが前記第２の実行環境における動作互換性を有していないと判定された場合、前記アプリケーションの実行コードにおける前記第１のクラスを前記第２のクラスに書き換える書換手段と、前記書換手段による書き換えが行われた実行コードを前記第２の実行環境で実行する実行制御手段と、を有する。
【０００９】
あるいは、第１の実行環境上で動作することが想定されたアプリケーションを前記第１の実行環境と少なくとも一部が非互換の第２の実行環境で実行する情報処理装置において、前記第１の実行環境と非互換である前記第２の実行環境における第１のクラスを含む第１のライブラリと、前記第１の実行環境における非互換のクラスと互換の機能を前記第２の実行環境において提供する第２のクラスを含む第２のライブラリと、を格納する第１の格納手段と、前記情報処理装置にインストールされた前記アプリケーションの実行コードを格納する第２の格納手段と、前記実行コードに含まれる定数プールを参照して、前記第２の実行環境における前記アプリケーションの動作互換性を判定する判定手段と、前記判定手段により前記アプリケーションが前記第２の実行環境における動作互換性を有していないと判定された場合、前記アプリケーションの実行コードにおける前記第１のクラスを前記第２のクラスに書き換える書換手段と、前記書換手段による書き換えが行われた実行コードを前記第２の実行環境で実行する実行制御手段と、を有する。
【発明の効果】
【００１０】
本発明によれば、アプリケーション実行環境における非互換性をより好適に解消可能とする技術を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】情報処理装置のハードウェア構成を例示的に示す図である。
【図２Ａ】アプリケーション実行環境の構成を例示的に示す図である。
【図２Ｂ】実行コード格納ファイル及びアプリケーションインストール用ファイルの構成を示す図である。
【図２Ｃ】アプリケーションキャッシュの構成を示す図である。
【図２Ｄ】マニフェストファイルを説明する図である。
【図２Ｅ】実行コードファイルの構成を示す図である。
【図２Ｆ】互換性追加ライブラリモジュールの構成を示す図である。
【図３】アプリケーションのインストール処理のフローチャートである。
【図４】新バージョンのアプリケーション実行環境における初回起動時の動作フローチャートである。
【図５Ａ】互換性に関わる各クラスの内部構成を示す図である。
【図５Ｂ】クラスフィールド及びインスタンスフィールドの構成を示す図である。
【図６】第１実施形態に係る各クラスの動作フローチャートである。
【図７】第２実施形態に係る各クラスの動作フローチャートである。
【図８】互換性の問題に関わる引数を説明する図である。
【図９】第２実施形態におけるインストール処理のフローチャートである。
【図１０】第２実施形態におけるアプリケーション実行環境の初回起動時の処理のフローチャートである。
【図１１】第３実施形態におけるアプリケーションキャッシュの内部構成を示す図である。
【図１２】第３実施形態におけるインストール処理のフローチャートである。
【図１３】第３実施形態におけるアプリケーション実行環境の初回起動時の処理のフローチャートである。
【図１４】アプリケーション実行環境の起動処理のフローチャートである。
【図１５】アプリケーション実行環境の終了処理のフローチャートである。
【図１６】第４実施形態におけるアプリケーションキャッシュの内部構成を示す図である。
【図１７】第４実施形態におけるインストール処理のフローチャートである。
【図１８】第４実施形態におけるアプリケーション実行環境の初回起動時の処理のフローチャートである。
【図１９】アプリケーション実行環境の起動処理のフローチャートである。
【発明を実施するための形態】
【００１２】
以下に、図面を参照して、この発明の好適な実施の形態を詳しく説明する。なお、以下の実施の形態はあくまで例示であり、本発明の範囲を限定する趣旨のものではない。
【００１３】
（第１実施形態）
本発明に係る情報処理装置の第１実施形態として、アプリケーション実行環境をバージョンアップ可能な情報処理装置を例に挙げて以下に説明する。
【００１４】
＜装置構成＞
図１は、情報処理装置のハードウェア構成を例示的に示す図である。情報処理装置（ＩＰＡ：Information Processing Apparatus）１０２はネットワーク１０１を介して不図示の外部装置と通信可能に構成されている。
【００１５】
ＩＰＡ１０２は、中央処理装置（ＣＰＵ）１１０、ランダムアクセスメモリ（ＲＡＭ）１１２、読み出し専用メモリ（ＲＯＭ）１１３を含む。また、ＩＰＡ１０２は、二次記憶装置接続インターフェース（Ｉ／Ｆ）１１４、二次記憶装置１１５、人間対話デバイス（ＨＩＤ）Ｉ／Ｆ１１６、ＨＩＤ１１７を含む。ＩＰＡ１０２は、更に、ネットワークＩ／Ｆ１１８、入出力（Ｉ／Ｏ）ポート１１９、周辺装置１２０を含む。ＩＰＡ１０２内の各部は、システムバス１１１を介して相互に接続される。また、ネットワークケーブル１２１は、ネットワークＩ／Ｆ１１８とネットワーク１０１を接続する。
【００１６】
＜ソフトウェア構成＞
図２Ａは、アプリケーション実行環境（ＡｐｐＲＥ：Application Runtime Environment）の構成を例示的に示す図である。以下では、アプリケーションをＡｐｐと呼ぶ。
【００１７】
ＡｐｐＲＥ２００は、アプリケーション実行基盤（ＡｐｐＰＦ：Application Platform）２０１、アプリケーション管理フレームワーク（ＡｐｐＭＦＷ：Application Management Framework）２０２、アプリケーションキャッシュ（ＡｐｐＣａｃｈｅ：Application Cache）２０３を含む。
【００１８】
ＡｐｐＰＦ２０１は、コード解釈実行モジュール（ＣＩＭ：Code Interpreter Module）２１０、実行基盤ライブラリモジュール（ＰＦＬＭ：Platform Library Module）２１１、互換性追加ライブラリモジュール（ＣＳＬＭ：Compatibility Support Library Module）２１２を含む。ＣＳＬＭ２１２は、新バージョンのＡｐｐＲＥ２００に非対応であるＡｐｐの動作を補完する為のモジュールである。
【００１９】
ここで、第１のクラス２１３は、ＰＦＬＭ２１１に含まれるクラスであり、ＡｐｐＲＥ２００の旧バージョンとの間での互換性に関わる（すなわち、非互換である）クラスである。
【００２０】
また、第２のクラス２１４は、ＣＳＬＭ２１２に含まれるクラスであり、ＡｐｐＲＥ２００の旧バージョンと第１のクラス２１３と互換の機能を提供するクラスである。なお、第１のクラス２１３と第２のクラス２１４のペアは一組である必要はなく、複数組用意されることもある。
【００２１】
ＡｐｐＭＦＷ２０２は、アプリケーションインストール状態管理モジュール２２０、アプリケーション起動状態管理モジュール２２１、アプリケーションキャッシュ管理モジュール２２２、初回起動検知モジュール２２３を含む。
【００２２】
アプリケーションインストール状態管理モジュール（ＡｐｐＤＳＭＭ：Application Deployment Status Manager Module）２２０は、Ａｐｐのインストールおよびアンインストールを実行しＡｐｐのインストール状態を管理する。
【００２３】
アプリケーション起動状態管理モジュール２２１（ＡｐｐＩＳＭＭ：Application Invocation Status Manager Module）は、Ａｐｐの起動および停止を処理しＡｐｐの起動状態を管理する。
【００２４】
アプリケーションキャッシュ管理モジュール（ＡｐｐＣＭＭ：Application Cache Manager Module）２２２は、アプリケーションファイルセット（ＡｐｐＦＳ：Application File Set）をＡｐｐＣａｃｈｅ２０３へ展開し管理する。
【００２５】
初回起動検知モジュール（ＩＳＤＭ：Initial Startup Detection Module）２２３は、ＡｐｐＲＥ２００全体が初めて起動されたことを検知する。アプリケーション用区画（ＡｐｐＳｅｃ：Application Section）２３０は、ＡｐｐＦＳを展開する為の個別の区画である。Ａｐｐは、ゼロ、１個、または複数個インストールされることができ、ここではＮ個のＡｐｐがインストールされている状態を図示している。これ以降、便宜上、アプリケーション１用区画をＡｐｐＳｅｃ２３０−１、アプリケーション２用区画をＡｐｐＳｅｃ２３０−２、アプリケーションＮ用区画をＡｐｐＳｅｃ２３０−Ｎで表す。順序を特に指定せずＡｐｐＳｅｃを表す場合には単にＡｐｐＳｅｃ２３０と表す。
【００２６】
図２Ｂは、ＡｐｐＲＥ２００で使用される実行コード格納ファイル（ＥＣＡＦ：Executable Code Archive File）及びアプリケーションインストール用ファイル（ＡｐｐＩＦ：Application Installation File）の構成を示す図である。
【００２７】
ＥＣＡＦ２０４は、いくつかの実行コードファイル（ＥＣ：Executable Code File）を内包し、マニフェスト（ＭＦ：Manifest File）２４２を付与したものである。
【００２８】
ＥＣＦ２４１は、実際に実行されるべきプログラムコードを保持しているファイルである。一般的にこのファイルはソフトウェア的な単位であるクラスごとに１つのファイルになっている。一般的にＥＣＡＦは１つまたは複数のＥＣＦを内包している。ここではＸ個のＥＣＦを内包している状態を図示している。以降便宜上、最初（１番目）のＥＣＦをＥＣＦ２４１−１、２番目のＥＣＦをＥＣＦ２４１−２、Ｘ番目のＥＣＦをＥＣＦ２４１−Ｘで表す。順序を特に指定せずＥＣＡＦ２０４に格納されたＥＣＦ一般を表す場合には単にＥＣＦ２４１で表す。
【００２９】
ＡｐｐＩＦ２０５は、ＥＣＡＦ２０４と同じ構造をしている。ＡｐｐＩＦ２０５は、ＥＣＡＦの中に別のＥＣＡＦ２０４を内包しているが、そのようなＥＣＡＦ２０４は許容される。ゆえにＡｐｐＩＦ２０５はＥＣＡＦ２０４の一種である。
【００３０】
主実行コードファイル（Ｍ−ＥＣＦ：Main Executable Code File）２５１は、Ａｐｐの主たる実行コードを保持するファイルである。副実行コードファイル（ＳｕｂＥＣＦ：Subordinate Executable Code File）２５２は、主たる実行コード以外を保持するファイルである。Ｍ−ＥＣＦ２５１およびＳｕｂＥＣＦ２５２はＥＣＦ２４１の一種である。ＡｐｐＩＦ２０５は、Ｍ−ＥＣＦ２５１を１つしか保持しない。一方、ＡｐｐＩＦ２０５は、ゼロ、１個、または複数個のＳｕｂＥＣＦ２５２を含み得る。ここではＹ個のＳｕｂＥＣＦを含んでいる状態を図示している。以降、便宜上、最初（１番目）のＳｕｂＥＣＦを２５２−１、２番目のＳｕｂＥＣＦを２５２−２、Ｙ番目のＳｕｂＥＣＦを２５２−Ｙで表す。順序を特に指定せずＳｕｂＥＣＦ一般を表す場合には単にＳｕｂＥＣＦ２５２で表す。
【００３１】
ライブラリ実行コード格納ファイル（ＬｉｂＥＣＡＦ：Library ECAF）２５３は、Ｍ−ＥＣＦ２５１およびＳｕｂＥＣＦ２５２以外の実行コードを保持したＥＣＦ２４１を格納しているＥＣＡＦ２０４に相当するものである。ＬｉｂＥＣＡＦ２５３は、ゼロ、１個、または複数個含まれる。ここではＺ個のＬｉｂＥＣＡＦが含まれた状態を図示している。以降、ＬｉｂＥＣＡＦ１を２５３−１、ライブラリ実行コード２を２５３−２、ＬｉｂＥＣＡＦ・Ｚを２５３−Ｚで表す。順序を特に指定せずＬｉｂＥＣＡＦ一般を表す場合には単に２５３で表す。
【００３２】
図２Ｃは、アプリケーションキャッシュの構成を示す図である。ここでは、ＡｐｐＲＥ２００におけるＡｐｐＣａｃｈｅ２０３に１以上のＡｐｐが保持されている状態を図示している。ＡｐｐＣａｃｈｅ２０３は二次記憶装置１１５上に確保されており、ここに、ＡｐｐＳｅｃ２３０が設定されている。
【００３３】
ＡｐｐＳｅｃ２３０は、インストールされるＡｐｐ用に確保された領域である。ＡｐｐＦＳ２３１は、インストールされるＡｐｐのＡｐｐＩＦ２０５から展開され配置される。ＡｐｐＦＳ２３１は、ＡｐｐＩＦ２０５および、ＬｉｂＥＣＡＦ２５３−１からＬｉｂＥＣＡＦ２５３−Ｚまでを有する。ＬｉｂＥＣＡＦ２５３はＡｐｐＩＦ２０５から取り出されたものである。
【００３４】
図２Ｄは、マニフェストファイルを説明する図である。ここでは、ＡｐｐＲＥ２００におけるＭＦ２４２の内容を例示的に示している。
【００３５】
項目２６０は、ＭＦ２４２に含まれている項目の例を示しており、項目名２６１、項目の値２６２を含む。ＭＦ２４２は、１つまたは複数の項目を保持することができる。ＡｐｐＲＥ２００内では、ＡｐｐＭＦＷ２０２は、ＥＣＡＦ２０４について、項目名を指定することにより項目の値を取り出すことが可能なようになっている。例えばこの図の例で言えば、“Ｍａｎｉｆｅｓｔ−Ｖｅｒｓｉｏｎ”を指定すると“ｘ．ｘ”が取得できるなどである。このような項目と値の組み合わせはＡｐｐの開発の過程において決定され、ＡｐｐＩＦ２３１が作成される際に、開発者がそれぞれＥＣＡＦ２０４のＭＦ２４２に値を記載する。
【００３６】
図２Ｅは、実行コードファイルの構成を示す図である。ここでは、ＡｐｐＲＥ２００におけるＥＣＦ２４１の内部構成を示している。
【００３７】
マジックナンバー２７１は、ＥＣＦ２４１を識別する為に用いられる。バージョン２７２は、ＥＣＦ２４１のバージョンである。定数プール（ＣＰ：Constant Pool）２７３は、ゼロ、１個、または複数の定数定義２７５を含む。ここでは一例としてＭ個の定数定義が置かれている状態を図示している。定数定義２７５は、定数記述子２７６及び定数値２７７を含む。ここでは便宜的に、定数定義１を定数定義２７５−１、定数記述子１を定数記述子２７６−１、すなわち定数値１を定数値２７７−１と表す。同様に、定数定義２を定数定義２７５−２、定数記述子２を定数記述子２７６−２、定数値２を定数値２７７−２と表す。定数定義一般を表す場合には２７５と表し、定数記述子一般を表す場合には２７６と表し、定数値一般を表す場合には２７７と表す。コード記述部分（ＣＢ：Code Body）２７４は、実行コードの本体であるコードを記述する。
【００３８】
図２Ｆは、互換性追加ライブラリモジュールの構成を示す図である。ここでは、ＡｐｐＲＥ２００におけるＣＳＬＭ２１２の内部構成を示している。
【００３９】
ＣＳＬＭ２１２は、１つまたは複数の互換性追加ＬｉｂＥＣＡＦ２８１から構成されている。ここでは一例としてＱ個の互換性追加ＬｉｂＥＣＡＦが存在するところを図示している。ここでは、最初（１番目）の互換性追加ＬｉｂＥＣＡＦをＬｉｂＥＣＡＦ２８１−１、２番目の互換性追加ＬｉｂＥＣＡＦをＬｉｂＥＣＡＦ２８１−２、Ｑ番目の互換性追加ＬｉｂＥＣＡＦをＬｉｂＥＣＡＦ２８１−Ｑと表す。互換性追加ＬｉｂＥＣＡＦ一般を表す場合には互換性追加ＬｉｂＥＣＡＦ２８１と表す。
【００４０】
＜インストール処理の動作＞
図３は、アプリケーションのインストール処理のフローチャートである。すなわち、ＡｐｐＲＥ２００におけるＡｐｐＭＦＷ２０２がＡｐｐのインストールを実施する際のフローチャートである。
【００４１】
ステップＳ３０１では、ＡｐｐＭＦＷ２０２は、処理を開始する。ステップＳ３０２では、ＡｐｐＤＳＭＭ２２０は、ユーザーによりライセンスファイル（ＬＦ：License File）が指定されているかどうかを判定する。指定されていない場合にはステップＳ３０６へ進む。指定されている場合にはステップＳ３０３へ進む。
【００４２】
ステップＳ３０３では、ＡｐｐＤＳＭＭ２２０は、Ａｐｐをインストールしようとする利用者によって指定されたＡｐｐＩＦ２０５を読み込む。この場合ＡｐｐＩＦ２０５はライセンス処理されている為、ＡｐｐＤＳＭＭ２２０は利用者によって指定されたＬＦを読み込み、ＡｐｐＩＦ２０５を復元する。復元の後ステップＳ３０７へ進む。
【００４３】
ステップＳ３０６では、ＡｐｐＭＦＷ２０２は、ＡｐｐＩＦ２０５を読み込む。完了したらステップＳ３０７へ進む。ステップＳ３０７では、ＡｐｐＭＦＷ２０２は、ＡｐｐＣａｃｈｅ２０３にＡｐｐＦＳ２３１を配置する為のＡｐｐＳｅｃ２３０を作成し、ＡｐｐＩＦ２０５をＡｐｐＳｅｃ２３０に配置する。またＡｐｐＩＦ２０５からＬｉｂＥＣＡＦ２５３を取り出しＡｐｐＳｅｃ２３０に配置する。
【００４４】
ステップＳ３１１では、ＡｐｐＭＦＷ２０２は、ＡｐｐＩＦ２０５のＭＦ２４２にＡｐｐＲＥ２００の新バージョン対応を示す記述があるかをチェックする。すなわち、動作互換性を判定する。ここでは、ＭＦの“Ｘ−ＯｓＮａｍｅＣｏｍｐｌｉａｎｃｅ”という項目の値が“１”であるかどうかをチェックしている。その値が“１”であれば、ＡｐｐＩＦ２０５は新バージョン対応である。“１”以外の値であった場合、および“Ｘ−ＯｓＮａｍｅＣｏｍｐｌｉａｎｃｅ”という項目自体が存在しない場合については対応の記述がないものとして扱う。ＡｐｐＩＦ２０５が新バージョン対応である、ということは含まれているＭ−ＥＣＦ２５１、ＳｕｂＥＣＦ２５２が新バージョン対応である、ということを意味する。対応の記述がない場合にはステップＳ３１２へ進む。ＭＦ２４２に対応の記述がある場合にはステップＳ３１８へ進む。
【００４５】
ステップＳ３１２では、ＡｐｐＤＳＭＭ２２０は、ＡｐｐＩＦ２０５からＭ−ＥＣＦ２５１を取り出す。ステップＳ３１３では、ＡｐｐＤＳＭＭ２２０は、Ｍ−ＥＣＦ２５１のＣＰ２７３を順番にチェックする。そして、ＣＰ２７３に第１のクラス２１３のクラス名が存在するかどうかを判定する。存在する場合にはステップＳ３１４へ進む。存在しない場合にはステップＳ３１６へ進む。
【００４６】
ステップＳ３１４では、ＡｐｐＤＳＭＭ２２０は、Ｍ−ＥＣＦ２５１の第１のクラス２１３のクラス名を含んだ定数定義２７５を新たな値に書き換える。新たな値として第２のクラス２１４のクラス名を用いる。例えば、ここで第１のクラス２１３のクラス名が“ｌｅｇａｃｙ．ｃｌａｓｓ．Ｓｙｓｔｅｍ”である場合には、互換性を維持する為に用意する第２のクラス２１４のクラス名を“ｉｎｈｅｒｉｔｃｌａｓｓ．Ｓｙｓｔｅｍ”のように定める。これら二つのクラス名は文字列長が一致するように定めておく。また第２のクラス２１４のクラス名はＡｐｐＰＦ２０１のＰＦＬＭ２１１にすでに存在するクラス名と衝突しないように定めておく。このような第１のクラス２１３と第２のクラス２１４の組み合わせが複数ある場合にはこれらの全ての組み合わせにういて同様に処理する。書き換えた後、ＡｐｐＤＳＭＭ２２０は、定数値２７７を書き換えたＭ−ＥＣＦ２５１をＡｐｐＩＦ２０５内のものと置き換える。
【００４７】
ステップＳ３１６では、ＡｐｐＤＳＭＭ２２０は、ＳｕｂＥＣＦ２５２があれば、それら全てに対して、ここまでにＭ−ＥＣＦ２５１に施した処理と同じ処理を施す。すなわち、ＣＰ２７３に第１のクラス２１３のクラス名の定数値２７７が存在する場合には第２のクラス２１４のクラス名に書き換える。書き換えが行われた場合には書き換えたＳｕｂＥＣＦ２５２でＡｐｐＩＦ２０５の中のものを置き換える。全てのＳｕｂＥＣＦ２５２に対するＣＰ２７３のチェックと必要な置き換え処理を完了したら、ステップＳ３１８へ進む。
【００４８】
ステップＳ３１８では、ＡｐｐＤＳＭＭ２２０は、ＬｉｂＥＣＡＦ２５３があれば、その最初（１番目）のファイルであるＬｉｂＥＣＡＦ２５３−１のＭＦ２４２を参照する。そして、ＭＦ２４２にＡｐｐＲＥ２００の新バージョン対応を示す記述があるかをチェックする。あればステップＳ３２４へ進み、なければステップＳ３１９へ進む。
【００４９】
ステップＳ３１９では、ＡｐｐＤＳＭＭ２２０は、ＬｉｂＥＣＡＦ２５３−１からＥＣＦ２４１−１を取り出す。そして続くステップＳ３２０にて、ＥＣＦ２４１−１のＣＰ２７３を順番にチェックする。そして、ＣＰ２７３に第１のクラス２１３のクラス名が存在するかどうかを判定する。ある場合にはステップＳ３２１へ進む。ない場合にはステップＳ３２３へ進む。
【００５０】
ステップＳ３２１では、ＡｐｐＤＳＭＭ２２０は、ＥＣＦ２４１−１のＣＰ２７３内の第１のクラス２１３のクラス名を、第２のクラス２１４のクラス名に書き換える。そして書き換えたＥＣＦ２４１−１をＬｉｂＥＣＡＦ２５３−１の中のものと置き換える。
【００５１】
ステップＳ３２３では、ＡｐｐＤＳＭＭ２２０は、ＬｉｂＥＣＡＦ２５３−１に含まれる他のＥＣＦ２４１があればそれらに対して同様の処理を施す。全てのＥＣＦ２４１に対して処理が終わったらステップＳ３２４へ進む。
【００５２】
ステップＳ３２４では、ＬｉｂＥＣＡＦ２５３−１に施したのと残る全てのＬｉｂＥＣＡＦについて処理を行い、全て終わったらステップＳ３２５へ進み処理を終了する。
【００５３】
＜初回起動時の動作＞
図４は、新バージョンのアプリケーション実行環境における初回起動時の動作フローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２が、更新後の初回起動時に実施するアップグレード処理のフローチャートである。
【００５４】
第１の実行環境であるＡｐｐＲＥ２００の旧バージョンが存在しており、すでに旧バージョンにおいて（すなわち、第１の実行環境上で）動作することが想定された複数のＡｐｐがインストールされた状態で稼働していることが想定する。そのようなＡｐｐＲＥ２００の旧バージョン（第１の実行環境）が更新され新バージョン（第２の実行環境）に移行した時に、新バージョン上で初めて起動された時に実行される処理について述べる。ステップＳ４０１では、ＡｐｐＭＦＷ２０２は、処理を開始する。
【００５５】
ステップＳ４０２では、ＡｐｐＣＭＭ２２１は、ＡｐｐＣａｃｈｅ２０３上にすでにＡｐｐＳｅｃ２３０が存在しているかどうかを判定する。なければステップＳ４１２へ進む。ある場合にはステップＳ４０３へ進む。
【００５６】
ステップＳ４０３では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−１上のＡｐｐＩＦ２０５のＭＦ２４２を参照する。ステップＳ４０４では、ＡｐｐＭＦＷ２０２は、ＭＦ２４２に新バージョンに対応していることを示す記述が含まれているかどうかを判定する。含まれている場合にはステップＳ４０８へ進む。含まれていなければステップＳ４０５へ進む。
【００５７】
ステップＳ４０５では、ＡｐｐＤＳＭＭ２２０は、図３で示したインストール時の処理と同様に、Ｍ−ＥＣＦ２５１のＣＰ２７３をチェックする。そして第１のクラス２１３のクラス名が存在しているかを判定する。ある場合には第２のクラス２１４のクラス名に書換え、ＡｐｐＩＦ２０５の中のものと置換する。ステップＳ４０６では、ＡｐｐＤＳＭＭ２２０は、ＳｕｂＥＣＦ２５２についても同様の処理を行う。
【００５８】
ステップＳ４０４もしくはステップＳ４０６からステップＳ４０８へ進むと、ＡｐｐＳｅｃ２３０−１に配置されているＬｉｂＥＣＡＦ２５３があれば、最初（１番目）のファイルであるＬｉｂＥＣＡＦ２５３−１のＭＦ２４２を参照する。ＭＦ２４２に新バージョン対応の記述があればステップＳ４１０へ進む。なければステップＳ４０９へ進む。
【００５９】
ステップＳ４０９では、ＡｐｐＤＳＭＭ２２０は、ＬｉｂＥＣＡＦ２５３−１に含まれるＥＣＦ２４１のＣＰ２７３のチェックを行う。そして必要があれば、それぞれについて第１のクラス２１３のクラス名から第２のクラス２１４のクラス名への書換えを実施する。それらＥＣＦ２４１の処理が全て完了したらステップＳ４１０へ進む。
【００６０】
ステップＳ４１０では、ＡｐｐＤＳＭＭ２２０は、ＬｉｂＥＣＡＦ２５３−２からＬｉｂＥＣＡＦ２５３−Ｚが存在すれば、それらについて、ＬｉｂＥＣＡＦ２５３−１と同様の処理を行う。残りのＬｉｂＥＣＡＦ２５３について処理が全て完了したら、ステップＳ４１１へ進む。
【００６１】
ステップＳ４１１では、ＡｐｐＣＭＭ２２１は、ＡｐｐＣａｃｈｅ２０３にＡｐｐＳｅｃ２３０−２からＡｐｐＳｅｃ２３０−Ｎが存在しているかをチェックする。存在していれば、それらについても同様の処理を行う。ＥＣＦ２４１およびＬｉｂＥＣＡＦ２５３についての処理が全て完了したらステップＳ４１２へ進み処理を完了する。
【００６２】
図５Ａは、互換性に関わる各クラスの内部構成を示す図である。ここでは、ＡｐｐＲＥ２００の互換性に関わる第１のクラス２１３および第２のクラス２１４の内部構成を示している。
【００６３】
第１のクラス２１３に備わるクラスフィールド（ＣＦｌｄ：Class Field）５００は、ゼロ、１個もしくは複数個存在する。ここでは一例としてＰ個のＣＦｌｄが存在する状態を図で示している。最初（１番目）のＣＦｌｄをＣＦｌｄ５００−１と表す。同様に、２番目のＣＦｌｄをＣＦｌｄ５００−２、Ｐ番目のＣＦｌｄをＣＦｌｄ５００−Ｐと表す。順序に関係なくＣＦｌｄを表す場合には単にＣＦｌｄ５００と表す。
【００６４】
第１のクラス２１３に備わるインスタンスフィールド（ＩＦｌｄ：Instance Field）５０１も、ゼロ、１個または複数個存在する。ここでは一例としてＱ個のＩＦｌｄが存在する状態を図で示している。最初（１番目）のＩＦｌｄをＩＦｌｄ５０１−１と表す。同様に、２番目のＩＦｌｄをＩＦｌｄ５０１−２、Ｑ番目のＩＦｌｄをＩＦｌｄ５０１−Ｑと表す。順序に関係なくＩＦｌｄを表す場合には単にＩＦｌｄ５０１と表す。
【００６５】
第１のクラス２１３に備わるクラスメソッド（ＣＭｔｈｄ：Class Method）５０２も、ゼロ、１個または複数個存在する。ここでは一例としてＲ個のＣＭｔｈｄが存在する状態を図で示している。最初（１番目）のＣＭｔｈｄをＣＭｔｈｄ５０２−１と表す。同様に、２番目のＣＭｔｈｄをＣＭｔｈｄ５０２−２、Ｒ番目のＣＭｔｈｄをＣＭｔｈｄ５０２−Ｒと表す。順序に関係なくＣＭｔｈｄを表す場合には単にＣＭｔｈｄ５０２と表す。
【００６６】
第１のクラス２１３に備わるインスタンスメソッド（ＩＭｔｈｄ：Instance Method）５０３も、ゼロ、１個または複数個存在する。ここでは一例としてＳ個のＩＭｔｈｄが存在する状態を図で示している。最初（１番目）のＩＭｔｈｄをＩＭｔｈｄ５０３−１と表す。同様に、２番目のＩＭｔｈｄをＩＭｔｈｄ５０３−２、Ｓ番目のＩＭｔｈｄをＩＭｔｈｄ５０３−Ｓと表す。順序に関係なくＩＭｔｈｄを表す場合には単にＩＭｔｈｄ５０３と表す。
【００６７】
第２のクラス２１４は、第１のクラス２１３と同数のＣＦｌｄを備える。第２のクラス２１４の最初（１番目）のＣＦｌｄを同様にＣＦｌｄ５１０−１で表す。２番目以降のＣＦｌｄも同様にＣＦｌｄ５１０−２からＣＦｌｄ５１０−Ｐと表す。順序に関係なく第２のクラス２１４のＣＦｌｄを表す場合は単にＣＦｌｄ５１０と表す。ここで、第２のクラス２１４の各ＣＦｌｄは外部参照の為の定義が第１のクラス２１３のもの一致するように用意されている。ＩＦｌｄ、ＣＭｔｈｄ、ＩＭｔｈｄについても同様である。
【００６８】
図５Ｂは、クラスフィールド及びインスタンスフィールドの構成を示す図である。ここでは、ＡｐｐＲＥ２００の第２のクラス２１４のＣＦｌｄ５１０およびＩＦｌｄ５１１の値の定義のパターンを示している。
【００６９】
第２のクラス２１４のａ番目のＣＦｌｄであるＣＦｌｄ５１０−ａは、互換性に影響しないＣＦｌｄである。すなわち第１のクラス２１３に属する対応するＣＦｌｄ５００−ａと同一の値のままでよいＣＦｌｄであるとする。この場合、ＣＦｌｄ５１０−ａの値はＣＦｌｄ５００−ａの値をそのまま参照する。これによりＡｐｐがＣＦｌｄ５１０−ａを参照すると、常にＣＦｌｄ５００−ａと同一の値が得られることとなる。
【００７０】
一方、第２のクラス２１４のｂ番目のＣＦｌｄであるＣＦｌｄ５１０−ｂは互換性に影響する。そのため、第１のクラス２１３の対応するＣＦｌｄ５００−ｂの値とは異なる値を保持する必要がある。独自定義値５２１は、この場合のＣＦｌｄＣＦｌｄ５１０−ｂの値として定義される。これにより、ＡｐｐがＣＦｌｄ５１０−ｂを参照すると、独自定義値５２１が得られることとなる。ＩＦｌｄについても同様である。
【００７１】
＜クラスメソッド実行時の動作＞
図６は、第１実施形態に係る各クラスの動作フローチャートである。ここでは、ＡｐｐＲＥ２００の第２のクラス２１４におけるＣＭｔｈｄ５１２の動作を示している。
【００７２】
ＣＭｔｈｄ５１２−ｅは互換性に影響しないＣＭｔｈｄである。すなわち第１のクラス２１３に属する対応するＣＭｔｈｄ５０２−ｅと同じ振る舞いをするべきＣＭｔｈｄであるとする。ＣＭｔｈｄ５１２−ｅは次のような処理を実施する。
【００７３】
ＡｐｐＲＥ２００に保持されているいずれかのＡｐｐが、第１のクラス２１３のＣＭｔｈｄ５０２−ｅを呼び出すようプログラミングされているとする。そこでＡｐｐのＣＭｔｈｄ５０２−ｅを呼び出すコードを含んでいるＥＣＦ２４１が、図３もしくは図４に示した処理によりＣＰ２７３に書かれた第１のクラス２１３のクラス名を書き換えられているとする。ここでＥＣＦ２４１とは、Ｍ−ＥＣＦ２５１、ＳｕｂＥＣＦ２５２、もしくはＬｉｂＥＣＡＦ２５３に含まれるもののいずれかである。この時ＥＣＦ２４１におけるＣＭｔｈｄ５０２−ｅの呼び出しは、クラス名が第２のクラス２１４のクラス名に書き換えられていることによりＣＭｔｈｄ５１２−ｅの呼び出しに変わっている。これによりＣＩＭ２１０はＥＣＦの実行コードを解釈実行する際に、ＣＭｔｈｄ５１２−ｅの呼び出しを処理する。
【００７４】
ステップＳ６０１では、ＣＩＭ２１０は、処理を開始する。すなわち、Ａｐｐの実行制御を開始する。ステップＳ６０２では、ＣＩＭ２１０は、ＣＭｔｈｄ５０２−ｅを、ＣＭｔｈｄ５１２−ｅに渡された引数があればそれを渡して呼び出す。ステップＳ６０３にてＣＭｔｈｄ５０２−ｅの戻り値を、ＣＭｔｈｄ５１２−ｅの戻り値として返す。そして、ステップＳ６０４へ進んで処理を完了する。処理が完了するとＣＩＭ２１０は、呼び出し元へ戻って処理を続行する。
【００７５】
これらの処理により、ＡｐｐのＣＭｔｈｄ５１２−ｅの呼び出し処理は、第１のクラス２１３のＣＭｔｈｄ５０２−ｅを呼び出したのと等価となり、Ａｐｐの動作に影響を与えることはない。
【００７６】
一方、ＣＭｔｈｄ５１２−ｆは互換性に影響し、第１のクラス２１３に属する対応するＣＭｔｈｄ５０２−ｆとは異なる、ＡｐｐＲＥ２００の旧バージョンが返すのと同じ値を返す必要があるとする。この場合、ＣＭｔｈｄ５１２−ｆは次のような処理を実施する。
【００７７】
ここでもＡｐｐのＣＭｔｈｄ５０２−ｆを呼び出すコードを含んだＥＣＦ２４１が、図３もしくは図４に示した処理によりＣＰ２７３に書かれた第１のクラス２１３のクラス名を書き換えられているとする。この時ＥＣＦ２４１におけるＣＭｔｈｄ５０２−ｆの呼び出しはＣＭｔｈｄ５１２−ｆの呼び出しに変わっている。これによりＣＩＭ２１０は、ＥＣＦの実行コードを解釈実行する際に、ＣＭｔｈｄ５１２−ｆの呼び出しを処理する。
【００７８】
ステップＳ６１１では、ＣＩＭ２１０は、処理を開始する。ステップＳ６１２では、ＣＩＭ２１０は、引数があれば、渡された引数の値が互換性に関わる引数の値の範囲に含まれているかどうかを判定する。含まれている場合にはステップＳ６１５へ進む。それ以外の場合はステップＳ６１３へ進む。
【００７９】
ステップＳ６１３では、互換性に問題がない為、ＣＩＭ２１０は、ＣＭｔｈｄ５０２−ｆを、ＣＭｔｈｄ５１２−ｆに渡された引数があればその引数を渡して呼び出す。ステップＳ６１４でＣＭｔｈｄ５０２−ｆが戻り値として返してきた値を、戻り値として返し、ステップＳ６１７へ進み処理を完了する。
【００８０】
一方、ステップＳ６１５へ進んだ場合には、ＣＩＭ２１０は、ＡｐｐＲＥ２００の旧バージョンが返すのと同じ値を返すように、独自の処理を行い、戻り値を算出する。ステップＳ６１６では、ＣＩＭ２１０は、算出された戻り値をＣＭｔｈｄ５１２−ｆの戻り値として返す。そしてステップＳ６１７へ進み処理を完了する。
【００８１】
第２のクラス２１４のＩＭｔｈｄ５１３の動作のパターンについても、ＣＭｔｈｄ５１２の動作と基本的に同様であるため詳細な説明は省略する。
【００８２】
これらの処理により、ＣＭｔｈｄ５１２−ｆが呼び出されることがＡｐｐＲＥ２００の旧バージョンにおいて第１のクラス２１３のＣＭｔｈｄ５０２−ｆの呼び出しと等価となる。ＩＭｔｈｄ５０３−ｈとＩＭｔｈｄ５１３−ｈの関係でも同様である。これによりＡｐｐＲＥ２００が新バージョンであることにより発生する第１のクラス２１３の互換性に関わる問題は、Ａｐｐの動作に影響を与えないことになる。
【００８３】
以上説明したとおり第１実施形態によれば、ＡｐｐＲＥ２００は、互換性に関わる第１のクラス２１３のクラス名が書かれたＥＣＦ２４１を書き換える。そして書き換えたＥＣＦ２４１をＥＣＡＦ２０４もしくはＡｐｐＩＦ２０５の中のものと置き換える。これらクラス名の書き換え処理やＥＣＦの置き換え処理は、Ａｐｐのインストール処理もしくは、新バージョンのＡｐｐＲＥ２００の初回起動時に実施される。この為、Ａｐｐが実際に解釈実行される時にはＡｐｐの実行に大きな影響を与えることはない。
【００８４】
また、第１実施形態では、第２のクラス２１４を含んだＣＳＬＭ２１２が追加されるだけでありＡｐｐＲＥにおいて互換性の為に費やされるモジュールの占有する容量も少ない。また書き換えられるのは互換性に関わる第１のクラス２１３のクラス名が書かれた定数定義２７５の定数値２７７領域だけである。すなわち余分なリソース容量を費やすことがない。
【００８５】
これらの特性により、第１実施形態に係るＡｐｐＲＥ２００は、リソースの容量や実行速度についての制限が厳しい組込向けのＡｐｐＲＥ２００である場合にも好適に適用可能である。
【００８６】
（第２実施形態）
第２実施形態では、ＭＦ２４２を参照し、新バージョンに対応するという記述が含まれているかをチェックする替わりに、ＥＣＦ２４１のＣＰ２７３に含まれる値のみで判定を行う。
【００８７】
第１実施形態においては、ＡｐｐＩＦ２０５およびＥＣＡＦ２０４について、そのＭＦ２４２をチェックしている。ＭＦ２４２にＡｐｐＲＥ２００の新バージョンに対応する記述があるかを判定し、あるのであれば、ＥＣＦ２４１の書き換えは必要ないと判断している。しかしＭＦ２４２に新バージョンに対応する記述を追加するのは開発者による為、開発者にとっては負担である。更に開発者のヒューマンエラーにより記述が漏れてしまうことがあり得る。その場合、実際にはＡｐｐが新バージョンに対応しているにも関わらず、ＥＣＦ２４１の書き換えが発生してしまう。すると、本来第２のクラス２１４を経由する必要はないにも関わらず、常に第２のクラス２１４を経由してしまい、パフォーマンスに悪影響を与えてしまうという可能性が生じる。
【００８８】
＜クラスメソッド実行時の動作＞
図７は、第２実施形態に係る各クラスの動作フローチャートである。ここでは、第２のクラス２１４におけるＣＭｔｈｄ５１２−ｆおよびＩＭｔｈｄ５１３−ｈの処理を示している。以下の説明においては、第１実施形態（図６）に対して差異のある部分についてのみ説明する。またここで提示されている図７の処理の内容は、図６の処理の内容のうち特別なケースに相当する。
【００８９】
ＣＭｔｈｄ５１２−ｆの処理を行う中で、ステップＳ６１２において、引数が互換性に関わる範囲に含まれている場合にはステップＳ８０１へ進む。
【００９０】
ステップＳ８０１では、ＣＩＭ２１０は、互換性の為に用意されたＣＭｔｈｄ５１２−ｆに渡された引数の値に対応する別の値を引数としてＣＭｔｈｄ５０２−ｆを呼び出す。
【００９１】
ステップＳ８０２では、ＣＩＭ２１０は、ＣＭｔｈｄ５０２−ｆの呼び出しから戻ってきた戻り値を受け取り、それをＣＭｔｈｄ５１２−ｆの戻り値として返す。そしてステップＳ６１７へ進んで終了する。
【００９２】
また、ＩＭｔｈｄ５１３−ｈの処理を行う中で、ステップＳ６３２において、引数が互換性に関わる範囲に含まれている場合にはステップＳ８１１へ進む。
【００９３】
ステップＳ８１１では、ＣＩＭ２１０は、互換性の為に用意されたＩＭｔｈｄ５１３−ｈに渡された引数の値に対応する別の値を引数としてＩＭｔｈｄ５０３−ｈを呼び出す。
【００９４】
ステップＳ８１２では、ＣＩＭ２１０は、ＩＭｔｈｄ５０３−ｈの呼び出しから戻ってきた戻り値を受け取り、それをＩＭｔｈｄ５１３−ｈの戻り値として返す。そしてステップＳ６３７へ進んで終了する。
【００９５】
図８は、互換性の問題に関わる引数を説明する図である。特に、ここで問題になっている引数の値の一例を示している。
【００９６】
第１のクラス２１３が“ｌｅｇａｃｙ．ｃｌａｓｓ．Ｓｙｓｔｅｍ”であるとする。ＡｐｐＲＥ２００の旧バージョンでは、第１のクラス２１３の“ｇｅｔ（）”というＣＭｔｈｄに対して“ｌｅｇａｃｙ．ｐｒｏｐ”という文字列を与えることによりＡｐｐが必要な値を獲得していた。以下“ｌｅｇａｃｙ．ｐｒｏｐ”という文字列を“非互換引数Ａ”と呼ぶ。
【００９７】
一方、ＡｐｐＲＥ２００の新バージョンでは、非互換引数Ａを“ｇｅｔ（）”に与えると旧バージョンで得られたものと全く違う値が返ってくるようになっている。その代わりに、ＡｐｐＲＥ２００の新バージョンでは “ａｌｔｅｒｎａｔｉｖｅ．ｐｒｏｐ”という文字列を用意する。以下“ａｌｔｅｒｎａｔｉｖｅ．ｐｒｏｐ”という文字列を“互換引数Ｂ”と呼ぶ。Ａｐｐは“ｇｅｔ（）”に対して互換引数Ｂを与えることにより、従来は非互換引数Ａにより得られていた値を得ることができるようになった。このように、Ａｐｐ自身が互換引数Ｂを使用するように構成されている場合には、ＡｐｐＲＥ２００のバージョンに関する互換性の問題を回避できる。しかしＡｐｐ自身がこのような処理に対応していない場合には、第１のクラス２１３のクラス名から第２のクラス２１４のクラス名への書き換えが必要である。
【００９８】
ここでＡｐｐＲＥ２００はＣＳＬＭ２１２に含まれる第２のクラス２１４である“ｉｎｈｅｒｉｔｃｌａｓｓ．Ｓｙｓｔｅｍ”を用意している。この第２のクラス２１４のクラス名は第１のクラス２１３の“ｇｅｔ（）”に対応するＣＭｔｈｄである“ｇｅｔ（）”を保持している。そして、この第２のクラス２１４の“ｇｅｔ（）”に非互換引数Ａという文字列を引き渡すと、必要な値を得ることができる。すなわち、旧バージョンにおいて第１のクラス２１３の“ｇｅｔ（）”に非互換引数Ａという文字列を引き渡した時に得られる値と同じ値が得られるようになっている。
【００９９】
旧バージョンと同じ動作を期待するＡｐｐは、ＡｐｐＭＦＷ２０２によって実行コード２４１を書き換えられた場合のことを考える。Ａｐｐにおいて第１のクラス２１３の“ｇｅｔ（）”を呼び出していたコードは、第２のクラス２１４の“ｇｅｔ（）”を呼び出すように変更される。すると非互換引数Ａに対して、Ａｐｐが期待していた値Ａが返ってくる。これにより互換性が保たれる。
【０１００】
一方、すでに新バージョンのＡｐｐＲＥ２００に対応済みのＡｐｐは第１のクラス２１３の“ｇｅｔ（）”に対して互換引数Ｂを引き渡すことで互換性を確保している。すると、そのようなＡｐｐのＥＣＦ２４１では互換引数Ｂが文字列定数として保持されることになる。従って、ＣＰ２７３に第１のクラス２１３のクラス名があっても互換引数Ｂの文字列が保持されているＥＣＦ２４１は書き換える必要がないことが分かる。一方、ＣＰ２７３に第１のクラス２１３のクラス名があり、更に文字列定数として互換引数Ｂを持っていないＥＣＦ２４１はクラス名の書き換えが必要であることになる。
【０１０１】
＜インストール処理の動作＞
図９は、第２実施形態におけるインストール処理のフローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２が、Ａｐｐをインストールする処理を示している。以下の説明では第１実施形態（図３）に対して差異のある部分についてのみ説明する。
【０１０２】
ステップＳ３１３では、ＡｐｐＭＦＷ２０２は、ＣＰ２７３に第１のクラス２１３のクラス名を表す定数値２７７が存在するかチェックする。ある場合にはステップＳ１００１へ進む。なければステップＳ１００２へ進む。ステップＳ１００１では、ＡｐｐＭＦＷ２０２は、ＣＰ２７３に互換性に関わる第１のクラス２１３のメソッド７０３に渡される引数を表すような定数値２７７が存在しているかをチェックする。なければステップＳ３１４へ進む。あればステップＳ１００２へ進む。ステップＳ３１４では、ＡｐｐＭＦＷ２０２は、ＣＰ２７３内の第１のクラス２１３のクラス名を第２のクラス２１４のクラス名に書き換える。その後ステップＳ１００２へ進む。
【０１０３】
ステップＳ３１３、ステップＳ１００１、あるいはステップＳ３１４からステップＳ１００２に到達すると、ＡｐｐＭＦＷ２０２は、ＳｕｂＥＣＦ２５２についても順に同様の処理を行う。全てのＳｕｂＥＣＦ２５２について処理が完了したらステップＳ３１９へ進む。
【０１０４】
ステップＳ３１９では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１からＥＣＦ２４１−１を取り出す。ステップＳ３２０では、ＡｐｐＭＦＷ２０２は、ＥＣＦ２４１−１のＣＰに第１のクラス２１３のクラス名があるかをチェックする。あればステップＳ１００３へ進む。なければステップＳ１００４へ進む。ステップＳ１００３では、ＡｐｐＭＦＷ２０２は、ここで問題となっている互換性に関わる第１のクラス２１３のメソッド７０３に渡される引数を表すような定数値２７７がＣＰ２７３内に存在しているかをチェックする。なければステップＳ３２１へ進む。ある場合にはステップＳ１００４へ進む。ステップＳ３２１では、ＡｐｐＭＦＷ２０２は、ＣＰ２７３内の第１のクラス２１３のクラス名を第２のクラス２１４のクラス名に書き換える。その後ステップＳ１００４へ進む。
【０１０５】
ステップＳ３２０、ステップＳ１００３、ステップＳ３２１からステップＳ１００４へ進んできたら、ステップＳ１００４では、ＡｐｐＭＦＷ２０２は、同様の処理を、２番目のＥＣＦであるＥＣＦ２４１−２からＸ番目のＥＣＦであるＥＣＦ２４１−Ｘまで施す。残りの全てのＥＣＦ２４１について処理が完了したら処理はステップＳ１００５へ進む。
【０１０６】
ステップＳ１００５では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−２からＬｉｂＥＣＡＦ２５３−Ｚまでについて、ＬｉｂＥＣＡＦ２５３−１と同様の処理を行う。すべてのＬｉｂＥＣＡＦ２５３の処理が完了したらステップＳ３２５へ進み、処理を完了する。
【０１０７】
＜初回起動時の動作＞
図１０は、第２実施形態におけるアプリケーション実行環境の初回起動時の処理のフローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２が、更新後の初回起動時に実施するアップグレード処理を示している。以下の説明では第１実施形態（図４）に対して差異のある部分のみ説明する。
【０１０８】
ステップＳ４０２では、ＡｐｐＭＦＷ２０２は、ＡｐｐＣａｃｈｅ２０３上にすでにＡｐｐＳｅｃ２３０が存在するかどうかをチェックする。なければステップＳ４１２へ進み、あればステップＳ１１０１へ進む。
【０１０９】
ステップＳ１１０１では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−１に配置されたＡｐｐＩＦ２０５を参照する。ステップＳ１１０２では、ＡｐｐＭＦＷ２０２は、ＡｐｐＩＦ２０５に含まれるＭ−ＥＣＦ２５１について、図９で示したインストールの処理時にＥＣＦ２４１に対して行ったのと同様の処理を行う。
【０１１０】
ステップＳ１１０３では、ＡｐｐＭＦＷ２０２は、ＡｐｐＩＦ２０５のＳｕｂＥＣＦ２５２が存在すれば、それらに順番に、同様の処理を施す。全てのＳｕｂＥＣＦ２５２に対する処理が完了したらステップＳ１１０４へ進む。
【０１１１】
ステップＳ１１０４では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−１に配置されたＬｉｂＥＣＡＦ２５３−１が存在すればそれを参照する。ステップＳ１１０５では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１に含まれるＥＣＦ２４１のそれぞれについて、同様の処理を実施する。全てのＥＣＦ２４１について処理が完了したらステップＳ１１０６へ進む。
【０１１２】
ステップＳ１１０６では、ＡｐｐＭＦＷ２０２は、更に、ＡｐｐＳｅｃ２３０−１にＬｉｂＥＣＡＦ２５３−２からＬｉｂＥＣＡＦ２５３−Ｙが存在すれば、同様の処理を行う。全てのＬｉｂＥＣＡＦ２５３について処理が完了したらステップＳ１１０７へ進む。
【０１１３】
ステップＳ１１０７では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−２からＡｐｐＳｅｃ２３０−Ｎが存在すれば、そこに展開されているＡｐｐＦＳ２３１について同様の処理を行う。更にＡｐｐＦＳ２３１に展開されているＬｉｂＥＣＡＦ２５３についても、含まれているＥＣＦ２４１に対して同様の処理を行う。ＡｐｐＭＦＷ２０２は、展開されている全てのＡｐｐＳｅｃ２３０に対して処理が完了したらステップＳ４１２へ進み処理を完了する。
【０１１４】
以上説明したとおり第２実施形態によれば、ＡｐｐＲＥ２００は、ＥＣＦ２４１のＣＰ２７３に含まれる値に基づいてＥＣＦ２４１書き換えを行うか否かを判定する。これにより、あるＡｐｐがＡｐｐＲＥ２００の新バージョンに対する対応を行ったかどうかを、開発者が意識してＭＦ２４２に値を記載する必要がない。これにより、開発者の負担が軽減される。また、開発者が誤ってＭＦ２４２に新バージョン対応の記述を追加することを忘れた場合にも、対応済のＥＣＦ２４１についての無駄な書き換えを抑止できる。
【０１１５】
（第３実施形態）
第３実施形態では、書き換える前のＥＣＦ２４１を維持する形態について説明する。実際の運用においては、ＡｐｐＲＥ２００を新バージョンに切り替えた後、ＩＰＡ１０２の処理能力等の問題で旧バージョンのＡｐｐＲＥ２００に戻す場合がある。このような場合第１及び第２実施形態においては、ＥＣＦ２４１は新バージョンとの互換性のために書き換えられていることから、旧バージョンのＡｐｐＲＥ２００では正常に動作しない場合がある。
【０１１６】
そこで、第３実施形態では、書き換える前のＥＣＦ２４１を維持する構成について説明する。一般に、ＡｐｐＲＥ２００の新バージョンから旧バージョンへの切り替えの際にはＩＰＡ１０２のシャットダウンと起動が行われる。そこで、ＩＰＡ１０２のシャットダウン時において、次回のＩＰＡ１０２の起動時にＡｐｐＲＥ２００が旧バージョンに戻っていても問題がないようにする構成する。具体的には、シャットダウン時に、次回にＡｐｐを実行する際に書き換え前のＥＣＦ２４１を保持したＥＣＡＦ２０４が実行される状態に変更する。一方で、新バージョンのＡｐｐＲＥ２００は、起動時に、次回にＡｐｐを実行する際に書き換え後のＥＣＦ２４１を保持したＥＣＡＦ２０４が実行される状態に変更する。これにより、ＡｐｐＲＥ２００が旧バージョンに戻された際にも問題なくＡｐｐが実行されるようにする。
【０１１７】
図１１は、第３実施形態におけるアプリケーションキャッシュの内部構成を示す図である。ここでは、ＡｐｐＣａｃｈｅ２０３の内容を示している。
【０１１８】
複製ＡｐｐＩＦ１４０１は、ＡｐｐＩＦ２０５の保持しているＥＣＦ２５１及びＥＣＦ２５２に対して書き換えを行った場合に、その書き換えたファイルを格納する為に作成されたＡｐｐＩＦの複製である。複製ＬｉｂＥＣＡＦ１４０２は、ＬｉｂＥＣＡＦ２５３の保持しているＥＣＦ２４１に対して書き換えを行った場合に、その書き換えたファイルを格納する為に作成されたＬｉｂＥＣＡＦの複製である。すなわち、ＡｐｐＣａｃｈｅ２０３の一部区画は複製格納手段として機能する。
【０１１９】
なお、図では複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２がそれぞれのＥＣＦ２４１に対応して存在するように示しているが、実際にはこれらは書き換えが発生した場合にのみ作成されるものである。またＥＣＡＦ２０４の名称変更は複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２が作成された場合にのみ行われるものである。
【０１２０】
もともとはＡｐｐＦＳ２３１にはＡｐｐＩＦ２０５とＬｉｂＥＣＡＦ２５３が格納されている。第３実施形態では、ＡｐｐＭＦＷ２０２が各ＥＣＡＦ２０４に含まれるＥＣＦ２４１を書き換えることがある。それらを書き換えた場合に、それをＥＣＡＦ２０４の複製（すなわち書換え前、置換前のＥＣＡＦ２０４）を作成しそちらの元のファイルと置き換える。すなわち、そのような場合にはＡｐｐＩＦ２０５の複製である複製ＡｐｐＩＦ１４０１や、ＬｉｂＥＣＡＦの複製である複製ＬｉｂＥＣＡＦ１４０２が作成される。
【０１２１】
そしてこのような複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２を作成する場合には元のＥＣＡＦ２０４を別名に名称変更する。その上でこれら元のＥＣＡＦ２０４に付与されていた元の名称を複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２に与える。
【０１２２】
＜インストール処理の動作＞
図１２は、第３実施形態におけるインストール処理のフローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２が、Ａｐｐをインストールする処理を示している。以下の説明においては、第１実施形態（図３）に対すて差異のある部分についてのみ説明する。
【０１２３】
ステップＳ３１３では、ＡｐｐＭＦＷ２０２は、ＣＰ２７３に第１のクラス２１３のクラス名があるかをチェックする。ある場合にはステップＳ３１３へ進む。ない場合にはステップＳ１５０３へ進む。ステップＳ３１４では、ＡｐｐＭＦＷ２０２は、Ｍ−ＥＣＦ２５１のＣＰ２７３内の第１のクラス２１３のクラス名を第２のクラス２１４のクラス名に書き換える。
【０１２４】
ステップＳ１５０１では、ＡｐｐＭＦＷ２０２は、ＡｐｐＩＦ２０５の名称を変更する。その上で、ＡｐｐＩＦ２０５の複製ＡｐｐＩＦ１４０１をＡｐｐＩＦ２０５に与えられていた名称で作成する。そして書き換えたＭ−ＥＣＦ２５１を、ＡｐｐＩＦの複製１４０１の中の元のファイルと置き換える。
【０１２５】
ステップＳ３１３もしくはステップＳ１５０１からステップＳ１５０３へ進むと、ＡｐｐＭＦＷ２０２は、ＳｕｂＥＣＦ２５２についても同様の処理を行う。全てのＳｕｂＥＣＦ２５２について処理が完了したらステップＳ３１８へ進む。
【０１２６】
ステップＳ３２０では、ＡｐｐＭＦＷ２０２は、最初（１番目）のＥＣＦであるＥＣＦ２４１−１のＣＰ２７３に第１のクラス２１３のクラス名が存在するかをチェックする。存在する場合にはステップＳ３２１へ進む。なければステップＳ１５０６へ進む。
【０１２７】
ステップＳ３２１では、ＡｐｐＭＦＷ２０２は、ＥＣＦ２４１−１のＣＰ２７３の第１のクラス２１３のクラス名を第２のクラス２１４のクラス名へ書き換えたら、ステップＳ１５０４へ進む。
【０１２８】
ステップＳ１５０４では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１の名称を変更し、その上でＬｉｂＥＣＡＦ２５３−１の元の名称で複製ＬｉｂＥＣＡＦ１４０２−１を作成する。その後書き換えを行ったＥＣＦ２４１−１で、複製ＬｉｂＥＣＡＦ１４０２−１の中のファイルを置き換える。
【０１２９】
ステップＳ３２０もしくはステップＳ１５０４からステップＳ１５０６へ進むと、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１に含まれる残りのＥＣＦ２５３があれば、それらについて同様の処理を行う。全てのＬｉｂＥＣＡＦ２５３について処理が完了したらステップＳ１５０７へ進む。
【０１３０】
ステップＳ３１８もしくはステップＳ１５０６からステップＳ１５０７へ進むと、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−２からＬｉｂＥＣＡＦ２５３−Ｚについても同様の処理を実行する。これらの処理を全てのＬｉｂＥＣＡＦ２５３に対して実行し終わったらステップＳ３２５へ進み処理を完了する。
【０１３１】
＜初回起動時の動作＞
図１３は、第３実施形態におけるアプリケーション実行環境の初回起動時の処理のフローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２が、更新後の初回起動時に実施するアップグレード処理を示している。以下では、第１実施形態（図４）との差異がある部分についてのみ説明する。
【０１３２】
ステップＳ４０４では、ＡｐｐＭＦＷ２０２は、ＡｐｐＩＦ２０５のＭＦ２４２に新バージョン対応の記述があるか否かをチェックし、あればステップＳ４０８へ進む。なければステップＳ１６０１へ進む。
【０１３３】
ステップＳ１６０１では、ＡｐｐＭＦＷ２０２は、Ｍ−ＥＣＦ２５１のＣＰ２７３に第１のクラス２１３のクラス名が含まれているかをチェックする。含まれている場合には文字列を第２のクラス２１４のクラス名に書き換える。そしてＡｐｐＩＦ２０５の名称を変更する。そしてＡｐｐＩＦ２０５の元の名称で、ＡｐｐＩＦ２０５の複製である複製ＡｐｐＩＦ１４０１を作成する。そして複製ＡｐｐＩＦ１４０１に含まれるＭ−ＥＣＦ２５１を書き換えたものと置き換える。
【０１３４】
ステップＳ１６０２では、ＡｐｐＭＦＷ２０２は、ＳｕｂＥＣＦ２５２があれば、それらに対して同様の処理を行う。全てのＳｕｂＥＣＦ２５２の処理が完了したらステップＳ４０８へ進む。
【０１３５】
ステップＳ４０８では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１のＭＦ２４２に新バージョン対応の記述があるかどうかをチェックする。ある場合にはステップＳ１６０４へ進む。ない場合にはステップＳ１６０３へ進む。
【０１３６】
ステップＳ１６０３では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１に含まれるＥＣＦ２４１のそれぞれについて、同様の処理を実行する。ＬｉｂＥＣＡＦ２５３−１に含まれる全てのＥＣＦ２４１について処理が完了したらステップＳ１６０４へ進む。
【０１３７】
ステップＳ１６０４では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−１に配置されている他のＬｉｂＥＣＡＦがあればそれらに対して同様の処理を行う。ＡｐｐＳｅｃ２３０−１に配置されたＬｉｂＥＣＡＦ２５３全ての処理が完了したらステップＳ１６０５へ進む。
【０１３８】
ステップＳ１６０５では、ＡｐｐＭＦＷ２０２は、他のＡｐｐＳｅｃ２３０が存在すればそれらＡｐｐＳｅｃ２３０−２からＡｐｐＳｅｃ２３０−Ｎまでについて同様の処理を行う。これらの処理を全てのＡｐｐＳｅｃ２３０に対して実行し終わったらステップＳ４１２へ進み処理を完了する。
【０１３９】
＜起動処理時の動作＞
図１４は、アプリケーション実行環境の起動処理のフローチャートである。ここでは、ＡｐｐＲＥ２００の起動時にＡｐｐＭＦＷ２０２が実行する処理を示している。ＡｐｐＲＥ２００およびＡｐｐＭＦＷ２０２は他にも起動時に実行する処理を備えているが、ここでは第３実施形態に関わる部分だけを抜き出したものを示している。ＡｐｐＲＥ２００は、通常はＩＰＡ１０２に電源が投入された際にその起動処理の一環として起動される。ただし、場合によっては利用者の手動、もしくはＡｐｐＲＥ２００自身の再起動が必要な状況に置いて自動的に起動されることがあり得る。ステップＳ１７０１から処理を開始する。
【０１４０】
ステップＳ１７０２では、ＡｐｐＭＦＷ２０２は、ＡｐｐＣａｃｈｅ２０３にＡｐｐＳｅｃ２３０が作成されているかどうかをチェックする。なければステップＳ１７０７へ進む。作成されていればステップＳ１７０３へ進む。
【０１４１】
ステップＳ１７０３では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−１の中に存在するファイル２０５及び２５３の中に、複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２を有するファイルがあるかどうかをチェックする。存在していればステップＳ１７０４へ進む。いなければステップＳ１７０５へ進む。
【０１４２】
ステップＳ１７０４では、ＡｐｐＭＦＷ２０２は、複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２が存在するファイルについて、元のファイル名称で存在している元のファイル２０５及びファイル２５３を別の名称に名称変更する。そしてそれらに対応する複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２を、それらの元のファイルにつけられていたファイル名に名称変更する。
【０１４３】
ステップＳ１７０５では、ＡｐｐＭＦＷ２０２は、残りのＡｐｐＳｅｃ２３０が存在すればそれらに対しても同様の処理を行う。
【０１４４】
ステップＳ１７０６では、ＡｐｐＭＦＷ２０２は、Ａｐｐをそれぞれ起動する。ステップＳ１７０７では、ＡｐｐＭＦＷ２０２は、処理が完了する。
【０１４５】
＜終了処理時の動作＞
図１５は、アプリケーション実行環境の終了処理のフローチャートである。ここでは、ＡｐｐＲＥ２００の終了時にＡｐｐＭＦＷ２０２が実行する処理を示している。ＡｐｐＲＥ２００およびＡｐｐＭＦＷ２０２は他にも終了時に実行する処理を備えているが、ここでは第３実施形態に関わる部分だけを抜き出したものを示している。ＡｐｐＲＥ２００は、通常はＩＰＡ１０２に対して電源断処理が実施された際にその電源断（シャットダウン）処理の一環として終了する。ただし、場合によっては利用者の手動、もしくはＡｐｐＲＥ２００自身の再起動が必要な状況に置いて自動的に終了することがあり得る。ステップＳ１８０１では、ＡｐｐＭＦＷ２０２は、処理を開始する。
【０１４６】
ステップＳ１８０２では、ＡｐｐＭＦＷ２０２は、全てのＡｐｐの終了処理が完了するのを待つ。ステップＳ１８０３では、ＡｐｐＭＦＷ２０２は、ＡｐｐＣａｃｈｅ２０３に作成されたＡｐｐＳｅｃ２３０が存在するかをチェックする。存在していなければステップＳ１８０７へ進む。存在していればステップＳ１８０４へ進む。
【０１４７】
ステップＳ１８０４では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−１に配置されたファイルの中に複製が存在しているものがあるかどうかをチェックする。存在していればステップＳ１８０５へ進む。存在していなければステップＳ１８０６へ進む。ステップＳ１８０５では、ＡｐｐＭＦＷ２０２は、複製が存在するファイルそれぞれについて、以下の処理を実行する。すなわち、複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２についてその名称を別名に名称変更し、元のファイル２０５及びファイル２５３の名称を、本来の名称に変更する。
【０１４８】
ステップＳ１８０６では、ＡｐｐＭＦＷ２０２は、ＡｐｐＳｅｃ２３０−２からＡｐｐＳｅｃ２３０−Ｎが存在していれば、それらに対して同様の処理を実施する。それら全てに対する処理が完了したらステップＳ１８０７へ進み処理を完了する。
【０１４９】
以上説明したとおり第３実施形態によれば、ＡｐｐＲＥ２００は、図１５の終了処理を行った時点から次回の起動時に図１４の起動処理を実行するまでの間、元のファイル２０５及びファイル２５３が元のファイル名を保持する。
【０１５０】
ＩＰＡ１０２上にてＡｐｐＲＥ２００のバージョンの入れ替えが発生する場合、ＡｐｐＲＥ２００自体は開始する前もしくは終了した後の状態に置かれる。この為ＡｐｐＲＥ２００のバージョンの入れ替えが発生した時点では元のファイル２０５及びファイル２５３が元のファイル名を保持している。ここでＡｐｐＲＥ２００が旧バージョンであった場合には、当該旧バージョンのＡｐｐＲＥ２００は元のファイル２０５及びファイル２５３を実行することとなる。これは元のファイル２０５及びファイル２５３が元のファイル名を保持しているからである。
【０１５１】
このように、第３実施形態では、ＡｐｐＲＥ２００を旧バージョンに戻した場合においてもＡｐｐを正常に実行することが可能となる。
【０１５２】
（第４実施形態）
第４実施形態では、書き換える前のＥＣＡＦ２０５及び２５３およびそれらの複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２に対して、元の名前でのアクセスが可能になるようなハードリンクを起動前後に付与する形態について説明する。
【０１５３】
上述の第３実施形態では、元のファイル２０５及びファイル２５３に元のファイル名を付与する処理を、ＡｐｐＲＥ２００のシャットダウン処理の一環で実施していた。正常にＡｐｐＲＥ２００をシャットダウンできた場合においては問題は起こらない。しかしながら、シャットダウンを正常に実行できなかった場合には問題が生じる。例えば、ＩＰＡ１０２の置かれる環境等によってはＩＰＡ１０２に対する電源供給が突然断たれることにより、正常なシャットダウン処理を経ないままＩＰＡ１０２が停止してしまう事態があり得る。その場合、次にＩＰＡ１０２に電源が投入された時、第３実施形態ではＡｐｐＲＥ２００は複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２に元のファイル名が付与された状態で開始することになる。そのため、ＡｐｐＲＥ２００が旧バージョンに戻っていた場合、ＥＣＦ２４１の書き換えが行われたＡｐｐについては正常に動作しない可能性がある。
【０１５４】
図１６は、第４実施形態におけるアプリケーションキャッシュの内部構成を示す図である。ここでは、ＡｐｐＣａｃｈｅ２０３の内容を示している。以下では、図１１との差異部分についてのみ説明する。
【０１５５】
第４実施形態においては、ＡｐｐＲＥ２００は、ＥＣＡＦ２０５及びＥＣＡＦ３５２もしくは複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２を実行する際に、元の名前で参照されるハードリンクを通じて行う。なお、ここでは、ＩＰＡ１０２が採用しているファイルシステムにおいては、１つのファイルの実体に対してファイル名が異なる複数のハードリンクを張ることが可能であることを想定している。このハードリンクを張る処理（リンク生成ともいう）は、ファイルシステムおよびＩＰＡ１０２の基本ソフトによってアトミックに実行される。
【０１５６】
アプリケーションインストール用実行対象リンク１９０１は、ＡｐｐＩＦ２０５もしくはその複製である複製ＡｐｐＩＦ１４０１を実際に実行時に読み込む際にその参照に使用されるハードリンクである。ライブラリ実行コード格納実行対象リンク１９０２は、ＬｉｂＥＣＡＦ２５３もしくはその複製である複製ＬｉｂＥＣＡＦ１４０２を実際に実行時に読み込む際にその参照に使用されるハードリンクである。
【０１５７】
ここでは、説明を簡単にするため、複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２や実行対象リンク１９０１及び実行リンク１９０２が、元のＥＣＡＦ２０５及びＥＣＡＦ２５３に対して常に存在する例を図示している。ただし、必ずしも元のＥＣＡＦ２０５及び２５３に対して内部のＥＣＦ２４１の書き換えが起こるわけではなく、そのようなケースでは複製や実行対象リンクは作成されない。
【０１５８】
＜インストール処理の動作＞
図１７は、第４実施形態におけるインストール処理のフローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２がＡｐｐをインストールする処理を示している。以下では、図３に対する差異部分についてのみ説明を加える。
【０１５９】
ステップＳ３１３では、ＡｐｐＭＦＷ２０２は、ＣＰ２７３に第１のクラス２１３のクラス名が存在するかをチェックし、存在する場合にはステップＳ３１４へ進む。ない場合にはステップＳ２００４へ進む。
【０１６０】
ステップＳ３１４の処理後、ステップＳ２００１では、ＡｐｐＭＦＷ２０２は、ＡｐｐＩＦ２０５の複製ＡｐｐＩＦ１４０１を作成し、別名を与える。書き換えたＭ−ＥＣＦ２５１で複製ＡｐｐＩＦ１４０１の中のファイルを置き換え、ＡｐｐＩＦ２０５のファイル名を変更する。そして元のＡｐｐＩＦ２０５に対してＡｐｐＩＦ２０５の元の名称を備えた実行対象リンク１９０１を張る。
【０１６１】
ステップＳ３１３もしくはステップＳ２００１からステップＳ２００４進むと、ＡｐｐＭＦＷ２０２は、ＳｕｂＥＣＦ２５２についてもそれぞれ同様の処理を行う。全てのＳｕｂＥＣＦ２０５の処理が終わったらステップＳ３１８へ進む。
【０１６２】
ステップＳ３１８では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１のＭＦ２４２に新バージョン対応の記述があるかをチェックする。あればステップＳ２００９へ進む。なければステップＳ３１９へ進む。ステップＳ３２０では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１のＥＣＦ２４１−１のＣＰ２７３に第１のクラス２１３のクラス名が存在する場合にはステップＳ３２１へ進む。存在しない場合にはステップＳ２００８へ進む。ステップＳ３２１では、ＡｐｐＭＦＷ２０２は、ＥＣＦ２４１−１のＣＰ２７３の第１のクラス２１３のクラス名を第２のクラス２１４のクラス名に書き換える。
【０１６３】
ステップＳ２００５では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１の複製である複製ＬｉｂＥＣＡＦ１４０２−１を別名で作成し、書き換えたＥＣＦ２４１−１でその中のファイルを置き換える。その後、ＬｉｂＥＣＡＦ２５３−１の名称を別名に変更し、ＬｉｂＥＣＡＦ２５３−１の元のファイル名を用いて、ＬｉｂＥＣＡＦ２５３−１に対する実行対象リンク１９０２−１を張る。
【０１６４】
ステップＳ２００８では、ＡｐｐＭＦＷ２０２は、ＬｉｂＥＣＡＦ２５３−１に含まれる残りのＥＣＦ２４１についても同様の処理を行う。全てのＥＣＦ２５３に対して実行し終わったらステップＳ２００９へ進む。
【０１６５】
ステップＳ３１８もしくはステップＳ２００８からステップＳ２００９へ進むと、ＡｐｐＭＦＷ２０２は、区画に展開されたＬｉｂＥＣＡＦについても同様の処理を実行する。全てのＬｉｂＥＣＡＦに対して処理が完了したらステップＳ３２５へ進み処理を完了する。
【０１６６】
＜初回起動時の動作＞
図１８は、第４実施形態におけるアプリケーション実行環境の初回起動時の処理のフローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２が、更新後の初回起動時に実施するアップグレード処理を示している。以下では、図４との差異部分についてのみ説明を加える。
【０１６７】
ステップＳ４０４にてＡｐｐＩＦ２０５のＭＦ２４２に新バージョン対応の記述があればステップＳ４０８へ進む。なければステップＳ２１０１へ進む。
【０１６８】
ステップＳ２１０１ではＭ−ＥＣＦ２５１のＣＰ２７３に第１のクラス２１３のクラス名が含まれているかをチェックする。含まれている場合には文字列を第２のクラス２１４のクラス名に書き換える。ＡｐｐＩＦ２０５の複製である複製ＡｐｐＩＦ１４０１を作成する。そして複製ＡｐｐＩＦ１４０１に含まれるＭ−ＥＣＦ２５１を書き換えたものと置き換える。そしてＡｐｐＩＦ２０５の名称を変更する。そしてＡｐｐＩＦ２０５の元の名称で、ＡｐｐＩＦ２０５に対する実行対象リンク１９０２を張る。
【０１６９】
ステップＳ２１０２では同様のことをＳｕｂＥＣＦ２５２があればそれらに対して行う。全てのＳｕｂＥＣＦ２５２に対して処理が完了したらステップＳ４０８へ進む。
【０１７０】
ステップＳ４０８では、ＬｉｂＥＣＡＦ２５３−１のＭＦ２４２に新バージョン対応の記述があるかどうかをチェックする。ある場合にはステップＳ２１０４へ進む。ない場合にはステップＳ２１０３へ進む。
【０１７１】
ステップＳ２１０３では、ＬｉｂＥＣＡＦ２５３−１に含まれるＥＣＦ２４１のそれぞれについて同様の処理を実行する。ＬｉｂＥＣＡＦ２５３−１に含まれる全てのＥＣＦ２４１について処理が完了したらステップＳ２１０４へ進む。
【０１７２】
ステップＳ２１０４ではＡｐｐＳｅｃ２３０−１に配置されている他のＬｉｂＥＣＡＦがあればそれらに対して同様の処理を実行する。ＡｐｐＳｅｃ２３０−１に配置されたＬｉｂＥＣＡＦ２５３全てに対して処理が完了したらステップＳ２１０５へ進む。
【０１７３】
ステップＳ２１０５では他のＡｐｐＳｅｃ２３０が存在すればそれらＡｐｐＳｅｃ２３０−２からＡｐｐＳｅｃ２３０−Ｎまでについて同様の処理を実行する。全てのＡｐｐＳｅｃ２３０に対して処理を実行し終わったらステップＳ４１２へ進む。ステップＳ４１２にて処理を完了する。
【０１７４】
＜起動処理時の動作＞
図１９は、アプリケーション実行環境の起動処理のフローチャートである。ここでは、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２がＡｐｐを起動する際に行う処理を示している。ステップＳ２２０１では、ＡｐｐＭＦＷ２０２のＡｐｐＩＳＭＭ２２１は処理を開始する。
【０１７５】
ステップＳ２２０２では、ＡｐｐＩＳＭＭ２２１は、ＡｐｐＣＭＭ２２２を通じて起動しようとするＡｐｐのＡｐｐＳｅｃ２３０をチェックする。ＡｐｐＳｅｃ２３０内にＥＣＡＦの複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２が存在していればステップＳ２２０３へ進む。存在しない場合にはステップＳ２２０８へ進む。
【０１７６】
ステップＳ２２０３では、ＡｐｐＩＳＭＭ２２１は、複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２の存在するファイルそれぞれについて以下のステップＳ２２０４を繰り返し処理する。
【０１７７】
ステップＳ２２０４では、ＡｐｐＩＳＭＭ２２１は、ＥＣＡＦの実行対象リンク１９０１及び実行対象リンク１９０２を、複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２それぞれに対して張る。全ての複製の存在するＥＣＡＦ２０４に対して処理が完了したらステップＳ２２０５へ進む。
【０１７８】
ステップＳ２２０５では、ＡｐｐＩＳＭＭ２２１は、Ａｐｐを起動し当該Ａｐｐが完全に起動するまで待機する。ステップＳ２２０６では、ＡｐｐＩＳＭＭ２２１は、全ての複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２の存在するファイルそれぞれについて、以下のステップＳ２２０７を繰り返し実行する。
【０１７９】
ステップＳ２２０７では、ＡｐｐＩＳＭＭ２２１は、ＥＣＡＦの実行対象リンク１９０１及び実行対象リンク１９０２を、複製ではなく元のファイル２０５及びファイル２５３それぞれに対して張る。全ての複製ＡｐｐＩＦ１４０１及び複製ＬｉｂＥＣＡＦ１４０２の存在するファイルについて処理が完了したら、ステップＳ２２０９に進んで処理を終了する。
【０１８０】
ステップＳ２２０８では、ＡｐｐＩＳＭＭ２２１は、Ａｐｐを起動し、ステップＳ２２０９にて処理を終了する。
【０１８１】
以上説明したとおり第４実施形態によれば、ＡｐｐＲＥ２００のＡｐｐＭＦＷ２０２は、Ａｐｐの起動時に図１９の処理を実施する。これにより、ＡｐｐＣａｃｈｅ２０３の上では実行対象リンク１９０１及び実行対象リンク１９０２は、元のファイル２０５及びファイル２５３に張られていることになる。このため、ＩＰＡ１０２が正常にシャットダウン出来ず、かつ、旧バージョンのＡｐｐＲＥ２００で起動した場合においても、好適にＡｐｐを動作させることが可能となる。
【０１８２】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【０１８３】
２００：アプリケーション実行環境；  ２０１：アプリケーション実行基盤；  ２０２：アプリケーション管理フレームワーク；  ２０３：アプリケーションキャッシュ；  ２１０：コード解釈実行モジュール；  ２１１：実行基盤ライブラリモジュール；  ２１２：互換性追加ライブラリモジュール；  ２１３：第１のクラス；  ２１４：第２のクラス
【図１】
2017073036.tif 000003
【図２Ａ】
2017073036.tif 000004
【図２Ｂ】
2017073036.tif 000005
【図２Ｃ】
2017073036.tif 000006
【図２Ｄ】
2017073036.tif 000007
【図２Ｅ】
2017073036.tif 000008
【図２Ｆ】
2017073036.tif 000009
【図３】
2017073036.tif 000010
【図４】
2017073036.tif 000011
【図５Ａ】
2017073036.tif 000012
【図５Ｂ】
2017073036.tif 000013
【図６】
2017073036.tif 000014
【図７】
2017073036.tif 000015
【図８】
2017073036.tif 000016
【図９】
2017073036.tif 000017
【図１０】
2017073036.tif 000018
【図１１】
2017073036.tif 000019
【図１２】
2017073036.tif 000020
【図１３】
2017073036.tif 000021
【図１４】
2017073036.tif 000022
【図１５】
2017073036.tif 000023
【図１６】
2017073036.tif 000024
【図１７】
2017073036.tif 000025
【図１８】
2017073036.tif 000026
【図１９】
2017073036.tif 000027