JP2018077690A - アプリケーションの実行環境の違いに依る互換性を考慮したインストール、及びファームアップ方法 - Google Patents

Abstract

【課題】アプリケーションの実行環境の違いに依る互換性を考慮したインストール、及びファームアップ方法を提供する。【解決手段】アプリが抱えているライブラリ実行コードが今のアプリ実行環境に対して互換性をもっているかを判断する。互換性をもっていない場合は、Ｓ６０３に進む。互換性を持っている場合は、Ｓ６０５に進み、差し替えない判定を返すために、Ｓ６０６に進む。Ｓ６０３において、アプリが抱えているライブラリ実行コードとアプリ実行基盤が保持している互換用ライブラリ実行コードのバージョンを比較する。アプリが抱えているライブラリ実行コードのほうが小さい場合は、Ｓ６０４に進み、差し替える判定を返すために、Ｓ６０６に進む。Ｓ６０３において、アプリが抱えているライブラリ実行コードのほうが大きい場合は、Ｓ６０５に進み、差し替えない判定を返すために、Ｓ６０６において、判断処理を終了し、最終的は判定を返すものとする。【選択図】図６

Description

本発明は、情報処理装置、画像形成装置における異なるアプリ実行環境用アプリケーションにおける互換性を考慮したインストール、及びファームアップ方法に関するものである。

近年、情報処理装置、及び画像形成装置においては、ＪＡＶＡ（登録商標、以下省略）環境に代表されるようなアプリケーション（以下「アプリ」と略称する）動作環境が提供されている。ＪＡＶＡの持つプログラムの可搬性を利用して、拡張可能なアプリを提供する技術が提案されている。アプリは、メインとなるモジュールだけでなく、その機能を補完するライブラリと呼ばれるサブのモジュールを保持していることが一般的である。そのメインとサブの組み合わせでアプリ全体の機能が達成されるため、この組み合わせでの動作確認が重要となってくる。

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

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

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

例えば、そのような技術の中には、以下のようなものが存在する。（特許文献１）この技術では、アプリ実行環境間の差異を吸収する互換機構部を有し、互換機構部はアプリ実行環境間のインストール仕様の差異を吸収するインストール仕様定義部と、アプリ実行環境間のインターフェース仕様の差異を吸収するインターフェース仕様定義部とを有し、これらをインストール時、及び実行時に利用することにより上記課題を解決する。

そのため、前述したアプリのサブモジュールに互換性がないようなときには、インストール時にこのサブモジュールを互換性のあるサブモジュールに置き換えることで互換性を保つことが考えられる。

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

しかしながら、そのような従来技術では、新しいアプリ実行環境にインストールされたアプリが抱えるサブモジュールと互換性のあるサブモジュールとのバージョンだけを比較し、互換性のあるサブモジュールが新しいときには常に差し替えるような処理が行われてきた。その結果、アプリとサブモジュールの組み合わせテストが十分になされ、差し替えが必ずしも必要でないアプリに対してまで差し替え処理が発生するという課題があった。

アプリケーションを実行することができる実行環境（２００）を備えた画像形成装置（１３０）であって、
当該実行環境（２００）は、アプリケーションをネットワーク、あるいは外部記憶装置からインストールするインストール手段（２２０）と、
当該アプリケーションにより利用されるサブモジュールの、当該実行環境（２００）上で実行される場合に本来の意図通りの動作をすることが分かっている第一のバージョンを保持する互換性サブモジュール（２１４）を保持する手段（２１３）と、を備えており、
当該実行環境（２００）がその別のバージョンから更新されて現在のバージョンが当該画像形成装置（１３０）上に配備された後初めて起動されたことを検知する検知手段（２２２）と、
既にインストールされている一つまたは複数のアプリケーションを更新する更新手段（２２１）と、を備えており、
当該更新手段（２２１）が、当該検知手段により当該実行環境が更新された後初めて起動されたことを検知した場合には、それらインストールされている当該一つまたは複数のアプリケーションのインストール先の当該フォルダを検索する検索ステップ（Ｓ５０２）と、
当該検索ステップにより当該サブモジュールが当該フォルダ内に置かれていると判定する第一の判定ステップ（Ｓ４０３）と、
当該第一の判定ステップにて当該サブモジュールが含まれていると判定された際には、
過去の当該サブモジュールにおいて差し替えられた履歴があるかどうかを判定する第二の判定ステップ（Ｓ６０１）と、
当該第二の判定ステップにより当該サブモジュールが差し替えられた履歴がある場合には、当該サブモジュールのバージョンと当該互換性サブモジュール（２１４）が保持する第一のバージョンとを比較する第三の判定ステップ（Ｓ６０３）と
当該第三の判定ステップにおいて当該第一のバージョンが当該サブモジュールのバージョンより新しい場合には、当該互換性サブモジュール（２１４）に差し替える第一の置換ステップ（Ｓ４０５）と
一方、当該第二の判定ステップにより当該サブモジュールが差し替えられた履歴がない場合には、当該サブモジュールのバージョンが当該実行環境（２００）に対して互換性を持つバージョンかを判断する第四の判定ステップ（Ｓ６０２）と
当該第四の判定ステップにより、差し替え不要という判断した場合は、差し替えを行わないステップ（Ｓ６０５）を含むように構成されていることを特徴とする、画像形成装置。

本発明によれば、最初のインストール時におけるサブモジュールの差し替え処理を行ったかどうかの履歴を基に、その後のサブモジュールの差し替え処理の判断に利用することで、差し替え処理を適切に実行することが可能となる。

画像形成装置のハードウェア構成図である。 第一の実施例におけるアプリ実行環境およびその関連モジュールやファイルの構成を示す図である。 第一の実施例におけるアプリ実行環境およびその関連モジュールやファイルの構成を示す図である。 第一の実施例におけるアプリ実行環境およびその関連モジュールやファイルの構成を示す図である。 第一の実施例におけるアプリのインストールとその後のアプリ実行環境のバージョンアップ時における互換対応モジュールのライブラリ実行コードの扱いについて説明するための図である。 第一の実施例におけるアプリのインストールとその後のアプリ実行環境のバージョンアップ時における互換対応モジュールのライブラリ実行コードの扱いについて説明するための図である。 第一の実施例におけるアプリの互換対応を含むインストール処理の手順を表す図である。 第一の実施例における新しいアプリケーション実行環境にバージョンアップ後の初回起動時の処理の手順を表す図である。 第一の実施例における差し替え判断の手順を表す図である。 第二の実施例におけるアプリのインストールとその後のアプリ上書きインストール時における互換対応モジュールのライブラリ実行コードの扱いについて説明するための図である。 第二の実施例におけるアプリの互換対応を含む上書きインストール処理の手順を表す図である。

以下、本発明を実施するための最良の形態について図面を用いて説明する。
［実施例１］
図１は、プリント機能やスキャン機能、ネットワーク通信機能などを備える画像形成装置１３０のハードウェア構成図である。図１において、コントローラ１００は画像形成装置１３０のコントローラである。コントローラ１００はスキャナ部１１３やプリンタ部１１４と電気的に接続され、一方でＬＡＮ１１６を介して外部デバイスと接続される。

ＣＰＵ１０１は、ＲＯＭ１０２に記憶された制御プログラム等に基づいて接続中の各種ハードウェアとのアクセスを統括的に制御し、またコントローラ内部で行われる各種処理についても統括的に制御する。ＲＯＭ１０２は読み出し専用の不揮発記憶領域であり、画像形成装置１３０のブートプログラム、ファームウェアなどが格納されている。ＲＡＭ１０３は、ＣＰＵ１０１が動作するためのシステムワークメモリであり、各種データを一時記憶するためのメモリである。このＲＡＭ１０３は、記憶した内容を電源オフ後も保持可能なＦＲＡＭ（登録商標）およびＳＲＡＭ、電源オフ後に記憶内容が消去されるＤＲＡＭなどにより構成される。

ＨＤＤ１０４は不揮発記憶領域であり、システムアプリなどを格納する。図２で説明するインストールするアプリを含むファームウェアは、ＨＤＤ１０４に格納される。操作部Ｉ／Ｆ１０５は、システムバス１１９と操作部１１８を接続するインターフェース部である。具体的には操作部１１８に表示するデータをシステムバス１１９から受取り表示すると共に、操作部１１８からの入力情報をシステムバス１１９へ出力する。画像形成装置１３０に対するユーザの指示や情報提示は、操作部１１８を介して行う。

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

図２（ａ）は、第一の実施例のアプリ実行環境の構成を図示したものである。２００は、アプリ実行環境である。本実施例では、ＪＡＶＡ環境を想定している。２０１は、アプリ実行基盤である。以降、旧バージョンとしてＶ１．０、新バージョンとしてＶ２．０を想定する。２１０は、コード解釈実行モジュールである。２１３は、新バージョンのアプリ実行基盤２０１に非対応であるアプリを補完する為の互換用サポートライブラリモジュールである。２１４は、互換用サポートライブラリモジュール２１３に含まれる、互換性を維持する為に用意された互換用ライブラリ実行コードである。

なお、互換用ライブラリ実行コード２１４は、複数用意されることもある。互換用ライブラリ実行コード２１４は、アプリのサブモジュールとして利用されることがある。互換用サポートライブラリモジュール２１３は、互換の為に用意されたものであるので、２１５で示すように、旧バージョンのアプリ実行基盤２０１には存在せず、新バージョンのアプリ実行基盤２０１にのみあるものとする。

２０２は、アプリ管理フレームワークである。２２０は、アプリのインストール、及びアップデートを実行する為のインストール手段である。インストール手段２２０は、インストールやアップデート時に、アプリインストール用ファイルをアプリキャッシュ２０３へ展開を行う。２２１は、インストール時にアプリの互換対応を行う為の更新手段である。

更新手段２２１は、インストール時やアプリ実行基盤のバージョンアップ時に、アプリが抱えるライブラリ実行コード２４３がアプリ実行基盤に対して互換があるかどうかをバージョンから判断し、互換がないと判断した場合、アプリが抱えるライブラリ実行コード２４３の代わりに互換用ライブラリ実行コード２１４をインストールする処理を行う。そのため、更新手段２２１は、ライブラリ実行コードのどのバージョンが、そのアプリ実行環境に互換があるかを把握している。

実施例１や２の図３や図７の例で言うと、ライブラリ実行コード（Ｖ１．０）が、アプリ実行環境（Ｖ２．０）以降では互換性がないことを更新手段２２１は、把握している。また、ライブラリ実行コード（Ｖ２．０／Ｖ２．１）が、アプリ実行環境（Ｖ２．０）以降で互換性があることを更新手段２２１は、把握している。２２２は、アプリ実行環境２００が別のバージョンから更新されて現在のバージョンが画像形成装置１３０上に配備された後初めて起動されたことや、インストールが上書きインストーであることを検知する検知手段である。

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

図２（ｂ）は、本実施例のアプリ実行環境２００にインストールされるアプリのアプリインストール用ファイルの一般的な構成を図示したものである。

２４０は、アプリインストール用ファイルである。一般的にＪＡＶＡの場合、拡張子がｊａｒで示される。アプリインストール用ファイル２４０は、マニフェストファイル２４１、いくつかの実行コードファイル２４２、いくつかのライブラリ実行コード２４３を内包している。実行コードファイル２４２は、実際に実行されるべきプログラムコードを保持しているファイルである。一般的にこのファイルはソフトウェア的な単位であるクラスごとに一つのファイル（ｃｌａｓｓファイル）になっている。その中身は、バイトコードと呼ばれる中間形式となっている。

ライブラリ実行コード２４３は、マニフェストファイル、いくつかの実行コードファイルから成る。また、ライブラリ実行コード２４３は、拡張子がｊａｒで示され、いわゆるサブモジュールと呼ばれるものに相当する。

図２（ｃ）は、本実施例のアプリ実行環境２００におけるアプリキャッシュ２０３にアプリが保持されている状態を図示したものである。アプリキャッシュ２０３は、ＨＤＤ１０４上に確保されており、ここに、アプリ１用区画２３０は、アプリ１用ディレクトリ２５１以下で示される。ｄａｔａフォルダ２５２は、アプリ１が利用するデータを置くディレクトリを示す。

アプリ１インストール用ファイル２５３は、インストールされたアプリ１のアプリインストールファイル２４０から展開され配置されたものである。ライブラリ実行コード２５４は、ライブラリ実行コード２４３をアプリインストール用ファイル２４０から抜き出して配置したものである。

図３は、本実施例のアプリ実行環境２００の新バージョンにおいて、アプリをインストールし、その後に、アプリ実行環境２００をバージョンアップした時の、振る舞いについて説明したブロック図である。図３（ａ）は、アプリ３００をアプリ実行環境（Ｖ２．０）３０３にインストールするときの図である。アプリ３００は、サブモジュールとして、ライブラリ実行コード（Ｖ１．０）３０１を保持している。ライブラリ実行コード（Ｖ１．０）３０１は、アプリ実行環境（Ｖ２．０）３０３に互換性がないサブモジュールであり、そのままインストールしたのでは、動作できないものとする。

一方、アプリ実行環境（Ｖ２．０）３０３は、アプリ実行基盤（Ｖ２．０）３０４を持ち、アプリ実行基盤（Ｖ２．０）３０４は、互換用ライブラリ実行コード（Ｖ２．０）３０５を保持している。

アプリ３００が、指示３１０で示すように、アプリ実行環境（Ｖ２．０）３０３にインストールされるときのことを考える。その結果、アプリキャッシュ２０３に対して、アプリ３００がインストールされる。一方、更新手段２２１は、ライブラリ実行コード（Ｖ１．０）３０１にアプリ実行環境（Ｖ２．０）３０３の互換性がないことをバージョンから検知すると、ライブラリ実行コード（Ｖ１．０）の代わりに、互換用ライブラリ実行コード（Ｖ２．０）３０５をアプリキャッシュにインストールする。

更新手段２２１は、ライブラリ実行コード（Ｖ１．０）からライブラリ実行コード（Ｖ２．０）に差し替えたことを示す差し替え履歴ファイル３２０を、アプリキャッシュに作成する。３２１は、このとき作成される差し替え履歴ファイル３２０の履歴である。アプリ３００がＹＹＹＹ／ＭＭ／ＤＤの日付において、ライブラリ実行コードが１．０から２．０に差し替えられたことを示す。

この後、更に指示３１１で示すように、アプリ実行環境のバージョンアップが行わるときのことを考える。アプリ実行環境（Ｖ２．１）３０６は、アプリ実行基盤（Ｖ２．１）３０７を持ち、アプリ実行基盤（Ｖ２．１）３０７は、互換用ライブラリ実行コード（Ｖ２．１）３０８を保持している。

アプリ実行基盤のバージョンアップが行わると、更新手段２２１は、差し替え履歴ファイル３２０に、アプリ３００に差し替え履歴があることを検知すると、アプリキャッシュ２０３に格納されているライブラリ実行コード（Ｖ２．０）３０５を、互換用ライブラリ実行コード（Ｖ２．１）３０８をアプリキャッシュに置換してインストールする。更新手段２２１は、ライブラリ実行コード（Ｖ２．０）からライブラリ実行コード（Ｖ２．１）に差し替えたことを示す差し替え履歴ファイル３２２を、アプリキャッシュに作成する。

３２３は、このとき作成される差し替え履歴ファイル３２２の履歴である。アプリ３００がＹＹＹＹ／ＭＭ／ＤＤの日付において、ライブラリ実行コードが２．０から２．１に差し替えられたことを示す。

図３（ｂ）は、アプリ３５０をアプリ実行環境（Ｖ２．０）３０３にインストールするときの図である。アプリ３５０は、サブモジュールとして、ライブラリ実行コード（Ｖ２．０）３５１を保持している。ライブラリ実行コード（Ｖ２．０）３５１は、アプリ実行環境（Ｖ２．０）３０３に互換性をもつサブモジュールであり、そのままインストールしても、動作可能であるとする。

一方、アプリ実行環境（Ｖ２．０）３０３は、アプリ実行基盤（Ｖ２．０）３０４を持ち、アプリ実行基盤（Ｖ２．０）３０４は、互換用ライブラリ実行コード（Ｖ２．０）３０５を保持している。アプリ３５０が、指示３１０で示すように、アプリ実行環境（Ｖ２．０）３０３にインストールされるときのことを考える。その結果、アプリキャッシュ２０３に対して、アプリ３５０がインストールされる。

一方、更新手段２２１は、ライブラリ実行コード（Ｖ２．０）３５１にアプリ実行環境（Ｖ２．０）３０３の互換性があることをバージョンから検知すると、そのままライブラリ実行コード（Ｖ２．０）３５１をアプリキャッシュにインストールする。更新手段２２１は、ライブラリ実行コード（Ｖ２．０）を差し替えなかったことを示す差し替え履歴ファイル３６０を、アプリキャッシュに作成する。３６１は、このとき作成される差し替え履歴ファイル３６０の履歴である。Ｎ／Ａは、アプリ３５０がＹＹＹＹ／ＭＭ／ＤＤの日付において、ライブラリ実行コードが差し替えられなかったことを示す。

この後、更に指示３１１で示すように、アプリ実行環境のバージョンアップが行わるときのことを考える。アプリ実行環境（Ｖ２．１）３０６は、アプリ実行基盤（Ｖ２．１）３０７を持ち、アプリ実行基盤（Ｖ２．１）３０７は、互換用ライブラリ実行コード（Ｖ２．１）３０８を保持している。

アプリ実行基盤のバージョンアップが行わると、更新手段２２１は、差し替え履歴ファイル３６０に、アプリ３５０に差し替え履歴がないことを検知すると、アプリキャッシュ２０３に格納されているライブラリ実行コード（Ｖ２．０）３５１を、そのまま利用する。更新手段２２１は、ライブラリ実行コード（Ｖ２．０）を差し替えなかったことを示す差し替え履歴ファイル３６２を、アプリキャッシュに作成する。３６３は、このとき作成される差し替え履歴ファイル３６２の履歴である。Ｎ／Ａは、アプリ３５０がＹＹＹＹ／ＭＭ／ＤＤの日付において、ライブラリ実行コードが差し替えられなかったことを示す。

図４は、本実施例のアプリ実行環境２００におけるアプリインストール処理時にインストール手段２２０と更新手段２２１が、互換対応を含むインストール処理するフローチャートである。

Ｓ４００からインストール処理を開始する。Ｓ４０１において、インストール手段２２０は、インストールファイルであるｊａｒファイルを図２（ｃ）で示したようにアプリキャッシュ２０３にアプリ用ディレクトリを作成して配置する。この後、キャッシュに配置されたインストールファイルセットに対して、更新手段２２１が処理を進める。ステップＳ４０２からＳ４０７までの動作＃１によって、更新手段２２１は、差し替え条件を満たすアプリが差し替える必要があるライブラリ実行コードを保持しているかどうかを判断し、差し替え条件を満たす場合、互換用ライブラリ実行コードでライブラリ実行コードを差し替える処理を行う。

Ｓ４０２において、アプリキャッシュ２０３にインストールされたインストールファイル内のライブラリ実行コードを取得しループ処理を開始する。Ｓ４０３において、取得したライブラリ実行コードが、互換用ライブラリ実行コードと同じものかどうかを判断する。同じ場合は、Ｓ４０４に進む。同じでない場合は、Ｓ４０７に進む。Ｓ４０４において、図６で示す差し替え判断フローにより差し替え条件を満たすかどうかを判断する。詳細は図６で示す。差し替え条件を満たすＹＥＳの場合は、Ｓ４０５に進む。一方、ＮＯと判断した場合は、Ｓ４０６に進む。

Ｓ４０５において、差し替え条件を満たすと判定された互換用ライブラリ実行コードによってライブラリ実行コードが差し替えられる。Ｓ４０６において、差し替え履歴ファイルを出力する。Ｓ４０７において、全てのライブラリ実行コードのループ終端でなければ、Ｓ４０２に戻って処理を繰り返す。全てのライブラリ実行コードに対する処理が完了した場合は、Ｓ４０８に進む。Ｓ４０８において、処理を終了する。

図５は、検知手段２１５がアプリ実行環境２００が当該画像形成装置１３０で別のバージョンから書き換えられた後の初回起動であることを検知したときの、更新手段２２１が、ライブラリ実行コードの差し替えを含む更新処理を行う時のフローチャートである。

Ｓ５００から実行環境のバージョンアップ処理を開始する。Ｓ５０１において、インストール制御モジュール２２０は、アプリキャッシュ２０３配下にある全てのアプリをアップデートする。次に、更新手段２２１によって、Ｓ５０２からＳ５０４まで、Ｓ５０１でアップデートされたアプリキャッシュ２０３配下のアプリ用区画全てを対象としたループ処理を行う。Ｓ５０３において、各アプリ用区画配下にある全てのｊａｒファイルに対して、図４で示した差し替え処理を実行する。

ここでの差し替え処理は、各ｊａｒファイルに対して、図４で示したＳ４０２からＳ４０７までの動作＃１と同じ処理となるため省略する。Ｓ５０４において、アプリ用区画のループ終端でなければ、Ｓ５０２に戻って処理を繰り返す。全てのアプリ用区画のｊａｒに対する処理が完了した場合は、Ｓ５０５に進む。Ｓ５０５において、ファームアップ処理を終了する。

図６は、Ｓ４０４で示した判断の詳細を示したフローとなる。Ｓ６００から判断処理を開始する。Ｓ６０１において、対象としているライブラリ実行コードに対する差し替え履歴があるかどうかを判断する。差し替え履歴がない場合は、Ｓ６０２に進む。差し替え履歴がある場合は、Ｓ６０３に進む。

Ｓ６０２において、アプリが抱えているライブラリ実行コードが今のアプリ実行環境に対して互換性をもっているかを判断する。互換性をもっていない場合は、Ｓ６０３に進む。互換性を持っている場合は、Ｓ６０５に進み、差し替えない判定を返すために、Ｓ６０６に進む。Ｓ６０３において、アプリが抱えているライブラリ実行コードとアプリ実行基盤が保持している互換用ライブラリ実行コードのバージョンを比較する。アプリが抱えているライブラリ実行コードのほうが小さい場合は、Ｓ６０４に進み、差し替える判定を返すために、Ｓ６０６に進む。

Ｓ６０３において、アプリが抱えているライブラリ実行コードのほうが大きい場合は、Ｓ６０５に進み、差し替えない判定を返すために、Ｓ６０６に進む。Ｓ６０６において、判断処理を終了し、最終的は判定を返すものとする。

以上、実施例１で示した方法により、具体的には以下に示すような効果を得ることができる。

［効果事例１］
アプリがライブラリ実行コードを抱える理由の一つに、アプリ本体とライブラリ実行コードの組み合わせでの動作を保証したいということが挙げられる。そのため、組み合わせは重要であり、それに手を加えることは動作が不安定になるリスクがあるといえる。最初のインストールにおいて、差し替えを実行しなかった場合、その後のアプリ実行環境のバージョンアップの際に、互換用ライブラリ実行コードに新しいバージョンが出ている場合でも、動作保障された組み合わせを重視し、差し替えを行わないで済む（図３（ｂ）のケース）。

一方で、最初のインストールにおいて、差し替えを実行した場合、その後のアプリ実行環境のバージョンアップの際に、互換用ライブラリ実行コードに新しいバージョンが出ている場合、更に差し替えることが可能となる。（図３（ａ）のケース）

［実施例２］
図７は、本実施例のアプリ実行環境２００の新バージョンにおいて、アプリをインストールし、その後に、同じアプリを上書きインストールする時の、振る舞いについて説明したブロック図である。アプリ７００は、サブモジュールとして、ライブラリ実行コード（Ｖ１．０）７０１を保持している。ライブラリ実行コード（Ｖ１．０）７０１は、アプリ実行環境（Ｖ２．１）７０３に互換性がないサブモジュールであり、そのままインストールしたのでは、動作できないものとする。

一方、アプリ実行環境（Ｖ２．１）７０３は、アプリ実行基盤（Ｖ２．１）７０４を持ち、アプリ実行基盤（Ｖ２．１）７０４は、互換用ライブラリ実行コード（Ｖ２．１）７０５を保持している。アプリ７００が、指示７１０で示すように、アプリ実行環境（Ｖ２．１）７０３にインストールされるときのことを考える。その結果、アプリキャッシュ２０３に対して、アプリ７００がインストールされる。

一方、更新手段２２１は、ライブラリ実行コード（Ｖ１．０）７０１にアプリ実行環境（Ｖ２．１）７０３の互換性がないことをバージョンから検知すると、ライブラリ実行コード（Ｖ１．０）の代わりに、互換用ライブラリ実行コード（Ｖ２．０）７０５をアプリキャッシュにインストールする。更新手段２２１は、ライブラリ実行コード（Ｖ１．０）からライブラリ実行コード（Ｖ２．１）に差し替えたことを示す差し替え履歴ファイル７２０を、アプリキャッシュに作成する。７２１は、このとき作成される差し替え履歴ファイル３２０の履歴である。アプリ７００がＹＹＹＹ／ＭＭ／ＤＤの日付において、ライブラリ実行コードが１．０から２．１に差し替えられたことを示す。

アプリ７５０は、サブモジュールとして、ライブラリ実行コード（Ｖ２．０）７５１を保持している。ライブラリ実行コード（Ｖ２．０）７５１は、アプリ実行環境（Ｖ２．１）７０３に互換性があるサブモジュールであり、そのままインストールすることが可能である。この後、更に指示７１１で示すように、アプリ実行環境（Ｖ２．１）７０３にアプリ７５０を上書きインストールするときのことを考える。

更新手段２２１は、上書きインストールであることを検知すると、差し替え履歴ファイル３２０を一旦削除する。その後、インストール処理を試みる。その結果、アプリキャッシュ２０３に対して、アプリ７５０がインストールされる。一方、更新手段２２１は、ライブラリ実行コード（Ｖ２．０）７５１にアプリ実行環境（Ｖ２．０）７０３の互換性があることをバージョンから検知すると、そのままライブラリ実行コード（Ｖ２．０）７５１をアプリキャッシュにインストールする。

更新手段２２１は、ライブラリ実行コード（Ｖ２．０）を差し替えなかったことを示す差し替え履歴ファイル７２２を、アプリキャッシュに作成する。７２３は、このとき作成される差し替え履歴ファイル７２２の履歴である。Ｎ／Ａは、アプリ７５０がＹＹＹＹ／ＭＭ／ＤＤの日付において、ライブラリ実行コードが差し替えられなかったことを示す。このように、インストールする前に差し替え履歴を削除していないと、互換用ライブラリ実行コード（Ｖ２．１）７０５の方が、アプリ７５０が保持するライブラリ実行コード（Ｖ２．０）７５１よりバージョンが大きい為に、上書きされてしまうことになる。

図８は、本実施例のアプリ実行環境２００におけるアプリインストール処理時にインストール手段２２０と更新手段２２１が、互換対応を含む上書きインストール処理するフローチャートである。

Ｓ８００から上書きインストール処理を開始する。Ｓ８０１において、インストール手段２２０は、インストールファイルであるｊａｒファイルを図２（ｃ）で示したようにアプリキャッシュ２０３にアプリ用ディレクトリを作成して配置する。Ｓ８０２からＳ８０３においては、Ｓ４０２からＳ４０３と同一の処理であるため、説明は省略する。

この後、検知手段２２２が上書きインストールを検知した場合は、Ｓ８０４において、ライブラリ実行コードを過去に差し替えたことがある差し替え履歴があるかどうかを判断する。差し替え履歴がある場合は、Ｓ８０５に進む。差し替え履歴がない場合は、Ｓ８０６に進む。Ｓ８０５において、差し替え履歴を削除する。この後、Ｓ８０６からＳ８０９の処理は、Ｓ４０４からＳ４０７と同一の処理であるため、説明は省略する。Ｓ８０９において、上書きインストール処理を終了する。

［効果事例２］
上書きインストール時において、最初に差し替え履歴を削除することで、その後の差し替え処理は差し替え履歴がないときと同じ処理となる。これにより、実施例１と同様、動作保障されたサブモジュールを抱えているアプリの場合は、その組み合わせを保つために差し替えを行わないで済むようになる（図７のケース）。

１３０ 画像形成装置
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ ＨＤＤ
１０５ 操作部Ｉ／Ｆ
１０６ ネットワークＩ／Ｆ

Claims (3)

1. アプリケーションを実行することができる実行環境（２００）を備えた画像形成装置（１３０）であって、
   当該実行環境（２００）は、アプリケーションをネットワーク、あるいは外部記憶装置からインストールするインストール手段（２２０）と、
   当該アプリケーションにより利用されるサブモジュールの、当該実行環境（２００）上で実行される場合に本来の意図通りの動作をすることが分かっている第一のバージョンを保持する互換用サブモジュール（２１４）を保持する手段と、を備えており、
   当該実行環境（２００）がその別のバージョンから更新されて現在のバージョンが当該画像形成装置（１３０）上に配備された後初めて起動されたことを検知する検知手段（２２２）と、
   既にインストールされている一つまたは複数のアプリケーションを更新する更新手段（２２１）と、を備えており、
   当該更新手段（２２１）が、当該検知手段により当該実行環境が更新された後初めて起動されたことを検知した場合には、それらインストールされている当該一つまたは複数のアプリケーションのインストール先の当該フォルダを検索する検索ステップ（Ｓ５０３）と、
   当該検索ステップにより当該サブモジュールが当該フォルダ内に置かれていると判定する第一の判定ステップ（Ｓ４０３）と、
   当該第一の判定ステップにて当該サブモジュールが含まれていると判定された際には、
   過去の当該サブモジュールにおいて差し替え履歴があるかどうかを判定する第二の判定ステップ（Ｓ６０１）と、
   当該第二の判定ステップにより当該サブモジュールが差し替えられた履歴がある場合には、当該サブモジュールのバージョンと当該互換性サブモジュール（２１４）が保持する第一のバージョンとを比較する第三の判定ステップ（Ｓ６０３）と
   当該第三の判定ステップにおいて当該第一のバージョンが当該サブモジュールのバージョンより新しい場合には、差し替える判断をするステップ（Ｓ６０４）と、当該互換性サブモジュール（２１４）に差し替える置換ステップ（Ｓ４０５）と
   一方、当該第二の判定ステップ（Ｓ６０１）により当該サブモジュールが差し替えられた履歴がない場合には、当該サブモジュールのバージョンが当該実行環境（２００）に対して互換性を持つバージョンかを判断する第四の判定ステップ（Ｓ６０２）と
   当該第四の判定ステップにより、差し替え不要という判断した場合は、差し替えを行わないステップ（Ｓ６０５）を含むように構成されていることを特徴とする、画像形成装置。
2. サブモジュールを差し替えた場合、その差し替え履歴をファイルで保存するステップ（Ｓ４０６）を備えることを特徴とする、
   請求項１に記載の画像形成装置。
3. アプリケーションの上書きインストールを検知した場合、差し替え履歴を削除するステップ（Ｓ８０５）を備え、その後にインストール処理を行うことを特徴とする、
   請求項１に記載の画像形成装置。