(57)【特許請求の範囲】
【請求項１】
ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナにイベント通知を行うイベント通知方法において、
コンピュータにより、
優先的にイベント通知を受けるバンドルの識別子をプロパティファイルから読み出して保持する第１のステップと、
前記イベントリスナをＯＳＧｉフレームワークに登録する際にＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを呼び出した全てのバンドルの識別子をイベント通知対象リストに保持する第２のステップと、
バンドルのステータスが変更した際に、前記イベント通知対象リストに保持されているバンドル識別子のうち前記プロパティファイルから読み出したバンドル識別子に合致するバンドル識別子のイベントリスナに対して優先的にイベント通知を行う第３のステップと、を有し、
前記優先的にイベント通知を受けるバンドルは、
他のバンドルのリソース管理を行うバンドルであることを特徴とするイベント通知方法。
【請求項２】
前記優先的にイベント通知を受けるバンドルは複数であって、
前記第１のステップにおいて、複数のバンドル識別子の優先順位を更に保持し、
前記第３のステップにおいて、
前記優先順位に基づき前記合致する複数のバンドル識別子の各イベントリスナにイベント通知をそれぞれ行うことを特徴とする請求項１記載のイベント通知方法。
【請求項３】
前記優先的にイベント通知される複数のバンドルのうち優先順位が最上位のバンドルは、
他のバンドルのリソース管理を行うバンドルであることを特徴とする請求項２記載のイベント通知方法。
【請求項４】
ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナにイベント通知を行うイベント通知装置において、
優先的にイベント通知を受けるバンドルの識別子をプロパティファイルから読み出して保持する第１の保持手段と、
前記イベントリスナをＯＳＧｉフレームワークに登録する際にＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを呼び出した全てのバンドルの識別子をイベント通知対象リストに保持する第２の保持手段と、
バンドルのステータスが変更した際に、前記イベント通知対象リストに保持されているバンドル識別子のうち前記プロパティファイルから読み出したバンドル識別子に合致するバンドル識別子のイベントリスナに対して優先的にイベント通知を行う通知手段と、を有し、
前記優先的にイベント通知を受けるバンドルは、
他のバンドルのリソース管理を行うバンドルであることを特徴とするイベント通知装置。
【請求項５】
前記優先的にイベント通知を受けるバンドルは複数であって、
前記第１の保持手段は、複数のバンドル識別子の優先順位を更に保持し、
前記通知手段は、
前記優先順位に基づき前記合致する複数のバンドル識別子の各イベントリスナにイベント通知をそれぞれ行うことを特徴とする請求項４記載のイベント通知装置。
【請求項６】
前記優先的にイベント通知される複数のバンドルのうち優先順位が最上位のバンドルは、
他のバンドルのリソース管理を行うバンドルであることを特徴とする請求項５記載のイベント通知装置。
【請求項７】
請求項１乃至３のいずれかに記載のイベント通知方法をコンピュータに実行させることを特徴とするイベント通知プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＳＧｉバンドル（イベントリスナ）にイベント通知を行う技術に関する。
【背景技術】
【０００２】
ＯＳＧｉ仕様に準拠したＯＳＧｉフレームワーク上では、バンドルと呼ばれるソフトウェアモジュールが動作する。バンドルは、ＩＮＳＴＡＬＬＥＤ、ＲＥＳＯＬＶＥ、ＳＴＡＲＴＩＮＧ、ＡＣＴＩＶＥ、ＳＴＯＰＰＩＮＧ、ＵＮＩＮＳＴＡＬＬＥＤのステータスを持ち、そのステータスは、バンドルのインストール、起動、停止等のイベントによって変化する。
【０００３】
イベント通知を受けたい各バンドルＡ，Ｂは、図６に示すように、（１）各イベントリスナａ，ｂをＯＳＧｉフレームワークに各々登録しておくことにより、（２）他のバンドルＹでステータス変更が生じた際に、（３）ＯＳＧｉフレームワークの通知部により、当該ステータス変更に基づくイベント通知を個々のイベントリスナａ，ｂを通じて各々受けることができる。
【０００４】
ステータス変更が発生した際には、ＯＳＧｉフレームワーク内に登録されている全てのイベントリスナに対してイベント通知がそれぞれ行われるが、その優先度はイベントリスナの種類によって異なっている。
【０００５】
非特許文献１によれば、ステータス変更を検知するイベントリスナとして、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとＢｕｎｄｌｅＬｉｓｔｅｎｅｒの２種類が用意されており、最初に、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナが呼び出され（イベント通知の同期的実行）、続いて、ＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナが呼び出される。図６の場合には、イベントリスナｂよりも先にイベントリスナａが呼び出され、バンドルＢよりも前にバンドルＡにバンドルＹのイベントが通知される。
【０００６】
ゆえに、イベント通知の優先度は、ＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナよりもＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナの方が高いことから、先にイベント通知を受けたいバンドルは、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとしてイベントリスナを登録しておけばよい。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「ＯＳＧｉ  Ｓｅｒｖｉｃｅ  Ｐｌａｔｆｏｒｍ  Ｃｏｒｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、ＯＳＧｉ  Ａｌｌｉａｎｃｅ、Ｒｅｌｅａｓｅ  ４、Ｖｅｒｓｉｏｎ  ４．３、Ａｐｒｉｌ  ２０１１、＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｏｓｇｉ．ｏｒｇ／Ｄｏｗｎｌｏａｄ/Ｒｅｌｅａｓｅ４Ｖ４３＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録されたイベントリスナが複数ある場合、その複数のイベントリスナ間での呼び出し順序はＯＳＧｉフレームワークの実装に依存し不定であることから、以下のような問題があった。
【０００９】
例えば、リソースが限られたデバイスでＯＳＧｉフレームワークを利用する場合には、バンドル毎の消費リソースを管理する必要がある。管理すべきリソースの１つとしてヒープメモリ消費量がある。ここで、バンドル毎のヒープメモリ消費量の管理を行うＭａｎａｇｅｍｅｎｔ  Ａｇｅｎｔをメモリ管理ＭＡとする。
【００１０】
メモリ管理ＭＡとは、ＯＳＧｉフレームワーク上で動作するバンドルのライフサイクル制御やリソース消費量の管理を行う役割を担うもので、１つ以上のバンドルで構成される。
【００１１】
Ｊａｖａ（登録商標）では、クラスがロードされる際に一度だけ実行されるコード（ｓｔａｔｉｃイニシャライザ）を記載することができ、この処理においてヒープメモリが消費される可能性がある。よって、メモリ管理ＭＡは、バンドルに含まれるクラスがロードされる前（バンドルがヒープメモリを消費する前）に、管理を開始するための準備を行う必要がある。
【００１２】
また、ＯＳＧｉフレームワークでは、バンドル毎にクラスローダ（バンドルクラスローダ）が生成され、バンドルに含まれるクラスは、バンドルクラスローダからロードされる。よって、メモリ管理ＭＡは、バンドル毎のヒープメモリ消費量を管理するため、このバンドルクラスローダが生成された直後から管理を開始する必要がある。
【００１３】
ＯＳＧｉ仕様によれば、バンドルクラスローダはバンドルのステートがＲＥＳＯＬＶＥＤとなった以降に生成されるという規定があるため、メモリ管理ＭＡは、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナを登録し、バンドルのＲＥＳＯＬＶＥＤイベントを検知した際に上記準備を行うことが考えられる。
【００１４】
ここで、メモリ管理ＭＡと同様に、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナを登録してバンドルのＲＥＳＯＬＶＥＤイベント契機で処理を行うバンドルＸが存在すると仮定する。
【００１５】
ＯＳＧｉ仕様では、前述したように複数のＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒの呼び出し順序は不定であることから、あるバンドルＹのバンドルのステートがＲＥＳＯＬＶＥＤとなった際のＢｕｎｄｌｅＥｖｅｎｔ通知（イベント通知）は、メモリ管理ＭＡが登録したＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナよりもバンドルＸが登録したＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナが先に呼び出される可能性がある。
【００１６】
その場合、メモリ管理ＭＡがバンドル毎のヒープメモリ消費量の管理を開始する前に、バンドルＸによる何らかの処理によりバンドルＹがヒープメモリを消費してしまう。こうなると、メモリ管理ＭＡがバンドルＹの消費するヒープメモリ消費量の管理を開始する前に、バンドルＹがヒープメモリを消費してしまうことになり、メモリ管理ＭＡにおいて所期するメモリ管理を実現できないことになる。
【００１７】
つまり、上記メモリ管理ＭＡのバンドルのように、どのバンドルよりも先にバンドルのステータス変更によるイベント通知を受けたいバンドルがあったとしても、他のバンドルがイベントリスナをＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録している場合には、その呼び出し順序は不定であるため、そのバンドルが登録するイベントリスナが最優先にイベント通知を受けられる保証はない。
【００１８】
本発明は、上記を鑑みてなされたものであり、その課題とするところは、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録されているイベントリスナへのイベント通知順序をバンドル単位で保証することにある。
【課題を解決するための手段】
【００１９】
請求項１記載のイベント通知方法は、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナにイベント通知を行うイベント通知方法において、コンピュータにより、優先的にイベント通知を受けるバンドルの識別子をプロパティファイルから読み出して保持する第１のステップと、前記イベントリスナをＯＳＧｉフレームワークに登録する際にＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを呼び出した全てのバンドルの識別子をイベント通知対象リストに保持する第２のステップと、バンドルのステータスが変更した際に、前記イベント通知対象リストに保持されているバンドル識別子のうち前記プロパティファイルから読み出したバンドル識別子に合致するバンドル識別子のイベントリスナに対して優先的にイベント通知を行う第３のステップと、を有し、前記優先的にイベント通知を受けるバンドルは、他のバンドルのリソース管理を行うバンドルであることを特徴とする。
【００２０】
本発明によれば、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナにイベント通知を行うイベント通知方法において、優先的にイベント通知を受けるバンドルの識別子をプロパティファイルから読み出して保持し、上記イベントリスナをＯＳＧｉフレームワークに登録する際にＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを呼び出した全てのバンドルの識別子をイベント通知対象リストに保持し、バンドルのステータスが変更した際に、そのイベント通知対象リストに保持されているバンドル識別子のうち上記プロパティファイルから読み出したバンドル識別子に合致するバンドル識別子のイベントリスナに対して優先的にイベント通知を行うため、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録されているイベントリスナへのイベント通知順序をバンドル単位で保証することができる。また、優先的にイベント通知を受けるバンドルは、他のバンドルのリソース管理を行うバンドルであるため、優先順位不確定に起因するリソースの管理漏れを解消することができる。
【００２１】
請求項２記載のイベント通知方法は、請求項１記載のイベント通知方法において、前記優先的にイベント通知を受けるバンドルは複数であって、前記第１のステップにおいて、複数のバンドル識別子の優先順位を更に保持し、前記第３のステップにおいて、前記優先順位に基づき前記合致する複数のバンドル識別子の各イベントリスナにイベント通知をそれぞれ行うことを特徴とする。
【００２２】
本発明によれば、優先的にイベント通知を受けるバンドルは複数であって、その複数のバンドル識別子の優先順位に基づき、上記合致する複数のバンドル識別子の各イベントリスナにイベント通知をそれぞれ行うため、優先的にイベント通知を受けるバンドル間でのイベント通知順序を保証することができる。
【００２５】
請求項３記載のイベント通知方法は、請求項２記載のイベント通知方法において、前記優先的にイベント通知される複数のバンドルのうち優先順位が最上位のバンドルは、他のバンドルのリソース管理を行うバンドルであることを特徴とする。
【００２６】
本発明によれば、優先的にイベント通知される複数のバンドルのうち優先順位が最上位のバンドルは、他のバンドルのリソース管理を行うバンドルであるため、優先順位不確定に起因するリソースの管理漏れを解消することができる。
【００２９】
請求項４記載のイベント通知装置は、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナにイベント通知を行うイベント通知装置において、優先的にイベント通知を受けるバンドルの識別子をプロパティファイルから読み出して保持する第１の保持手段と、前記イベントリスナをＯＳＧｉフレームワークに登録する際にＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを呼び出した全てのバンドルの識別子をイベント通知対象リストに保持する第２の保持手段と、バンドルのステータスが変更した際に、前記イベント通知対象リストに保持されているバンドル識別子のうち前記プロパティファイルから読み出したバンドル識別子に合致するバンドル識別子のイベントリスナに対して優先的にイベント通知を行う通知手段と、を有し、前記優先的にイベント通知を受けるバンドルは、他のバンドルのリソース管理を行うバンドルであることを特徴とする。
【００３０】
本発明によれば、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナにイベント通知を行うイベント通知装置において、優先的にイベント通知を受けるバンドルの識別子をプロパティファイルから読み出して保持し、上記イベントリスナをＯＳＧｉフレームワークに登録する際にＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを呼び出した全てのバンドルの識別子をイベント通知対象リストに保持し、バンドルのステータスが変更した際に、そのイベント通知対象リストに保持されているバンドル識別子のうち上記プロパティファイルから読み出したバンドル識別子に合致するバンドル識別子のイベントリスナに対して優先的にイベント通知を行うため、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録されているイベントリスナへのイベント通知順序をバンドル単位で保証することができる。また、優先的にイベント通知を受けるバンドルは、他のバンドルのリソース管理を行うバンドルであるため、優先順位不確定に起因するリソースの管理漏れを解消することができる。
【００３１】
請求項５記載のイベント通知装置は、請求項４記載のイベント通知装置において、前記優先的にイベント通知を受けるバンドルは複数であって、前記第１の保持手段は、複数のバンドル識別子の優先順位を更に保持し、前記通知手段は、前記優先順位に基づき前記合致する複数のバンドル識別子の各イベントリスナにイベント通知をそれぞれ行うことを特徴とする。
【００３２】
本発明によれば、優先的にイベント通知を受けるバンドルは複数であって、その複数のバンドル識別子の優先順位に基づき、上記合致する複数のバンドル識別子の各イベントリスナにイベント通知をそれぞれ行うため、優先的にイベント通知を受けるバンドル間でのイベント通知順序を保証することができる。
【００３５】
請求項６記載のイベント通知装置は、請求項５記載のイベント通知装置において、前記優先的にイベント通知される複数のバンドルのうち優先順位が最上位のバンドルは、他のバンドルのリソース管理を行うバンドルであることを特徴とする。
【００３６】
本発明によれば、優先的にイベント通知される複数のバンドルのうち優先順位が最上位のバンドルは、他のバンドルのリソース管理を行うバンドルであるため、優先順位不確定に起因するリソースの管理漏れを解消することができる。
請求項７記載のイベント通知プログラムは、請求項１乃至３のいずれかに記載のイベント通知方法をコンピュータに実行させることを特徴とする。
【発明の効果】
【００３７】
本発明によれば、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録されているイベントリスナへのイベント通知順序をバンドル単位で保証することができる。
【図面の簡単な説明】
【００３８】
【図１】イベント通知装置の機能ブロック構成を示す図である。
【図２】優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅの設定例を示す図である。
【図３】イベント通知装置の処理フローを示す図である。
【図４】優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅの設定例を示す図である。
【図５】イベント通知装置の処理フローを示す図である。
【図６】イベント通知される仕組みを説明する図である。
【発明を実施するための形態】
【００３９】
以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。
【００４０】
〔第１の実施の形態〕
第１の実施の形態では、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録された複数のイベントリスナのうち、ある特定のバンドルによって登録されたイベントリスナに対して優先的にイベント通知を行う方法について説明する。
【００４１】
図１は、第１の実施の形態に係るイベント通知装置の機能ブロック構成を示す図である。本イベント通知装置１００は、ＯＳＧｉフレームワーク上で動作し、設定部１１と、第１判定部１３と、第１取得・保持部１４と、第２判定部１５と、第２取得・保持部１６と、照合部１７と、通知部１８とを備えている。
【００４２】
このようなイベント通知装置１００は、メモリ等の記憶手段やＣＰＵ等の計算・制御手段を備えたコンピュータで実現可能であり、その動作処理はプログラムによって実行される。以下、各機能部について説明する。
【００４３】
設定部１１は、ＪＶＭ（Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）が有するＪａｖａシステムプロパティファイル１２へ優先的にイベント通知を受けるバンドル（以下、優先バンドル）のＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅ（バンドル識別子）を設定する機能を有する。
【００４４】
例えば、図２に示すように設定する。「ｐｒｉｏｒｉｔｉｚｅｄ．ｌｉｓｔｅｎｅｒ」は、優先バンドルを指定するためのｋｅｙであり、「ｃｏｍ．ａｃｍｅ．ｂｕｎｄｌｅＡ」は、ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅを示している。
【００４５】
尚、Ｊａｖａシステムプロパティファイル１２を用いるのは例であり、ＯＳＧｉフレームワーク起動時に読み込まれるプロパティファイルであれば任意に利用できる。また、Ｊａｖａシステムプロパティファイル１２は、ＪＶＭによって管理されたメモリに記憶され、当該メモリから読み出されることによって適宜利用される。
【００４６】
第１判定部１３は、ＯＳＧｉフレームワーク起動時に読み込まれたＪａｖａシステムプロパティファイル１２に優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅが設定されているか否かを判定する機能を有する。
【００４７】
第１取得・保持部１４は、優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅをＪａｖａシステムプロパティファイル１２から取得して、保持する機能を有する。
【００４８】
第２判定部１５は、イベントリスナをＯＳＧｉに登録する時にＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）が呼びされた際、そのＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）に登録されたＢｕｎｄｌｅＬｉｓｔｅｎｅｒの型（イベントリスナの型）が、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒ型か否かを判定する機能を有する。
【００４９】
尚、ＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）とは、ＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを意味し、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒ等、バンドルのステータス変更に基づくイベント通知を受けるイベントリスナを登録するＯＳＧｉ仕様のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）である（非特許文献１参照）。
【００５０】
第２取得・保持部１６は、第２判定部１５での判定結果がＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒ型である場合に、ＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）を呼び出した全てのバンドルからＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅをそれぞれ取得し、イベント通知対象バンドルリストに保持しておく機能を有する。
【００５１】
尚、ＯＳＧｉフレームワークは、ＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）の呼び出し元のバンドルを把握しているため、そのバンドルからＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅを取得することができる。
【００５２】
照合部１７は、イベント通知対象バンドルリスト内の各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅが優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅであるかどうかを判断するため、イベント通知対象バンドルリスト内の各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅについて、「ｐｒｉｏｒｉｔｉｚｅｄ．ｌｉｓｔｅｎｅｒ」に対応して保持されているＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅと照合する機能を有する。
【００５３】
通知部１８は、照合部１７での照合結果、合致するＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅのイベントリスナに対して優先的にイベント通知を行う機能を有する。
【００５４】
次に、イベント通知装置１００の動作を説明する。図３は、イベント通知装置１００の処理フローを示す図である。但し、優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅが既にＪａｖａシステムプロパティファイル１２に設定されているとする。
【００５５】
最初に、ＯＳＧｉフレームワークが起動すると（ステップＳ１０１）、Ｊａｖａシステムプロパティファイル１２が読み込まれ（ステップＳ１０２）、第１判定部１３により、その読み込んだＪａｖａシステムプロパティファイル１２内に優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅが設定されているか（Ｙｅｓ）否か（Ｎｏ）が判定される（ステップＳ１０３）。
【００５６】
ステップＳ１０３の判定結果がＹｅｓの場合には、次に、第１取得・保持部１４により、その設定されている優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅがＪａｖａシステムプロパティファイル１２から読み出され、保持される（ステップＳ１０４）。尚、ステップＳ１０３の判定結果がＮｏの場合には、ステップＳ１０４を行うことなくステップＳ１０５に進む。
【００５７】
次に、イベントリスナがＯＳＧｉフレームワークに登録されると（ステップＳ１０５）、第２判定部１５により、そのイベントリスナ登録時にＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）が呼びされた際、そのＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）に登録されたＢｕｎｄｌｅＬｉｓｔｅｎｅｒの型（イベントリスナの型）が、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒ型か（Ｙｅｓ）否か（Ｎｏ）がｉｎｓｔａｎｃｅｏｆ演算子を用いて判定される（ステップＳ１０６）。
【００５８】
ステップＳ１０６の判定結果がＹｅｓの場合には、次に、第２取得・保持部１６により、ＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）を呼び出した全てのバンドルからＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅがそれぞれ取得され、イベント通知対象バンドルリストに保持される（ステップＳ１０７）。尚、ステップＳ１０６の判定結果がＮｏの場合には、後述するステップＳ１１１に進む。
【００５９】
ここで、バンドルのステータス変更が発生した場合には（ステップＳ１０８）、照合部１７により、ステップＳ１０７で保持したイベント通知対象バンドルリスト内のＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅが、ステップＳ１０４で保持したＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅと照合される（ステップＳ１０９）。
【００６０】
その後、通知部１８により、イベント通知対象バンドルリスト内のうち、ステップＳ１０９の照合結果で合致するＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅのイベントリスナ（すなわち、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒであり、且つ優先的にイベント通知を受けるように設定されたバンドルのイベントリスナ）に対して、優先的にイベント通知が行われる（ステップＳ１１０）。
【００６１】
一方、合致しないＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅのイベントリスナ（すなわち、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒであるが、優先的にイベント通知を受けるように設定されていないバンドルのイベントリスナ）に対しては、ＯＳＧｉ仕様で規定されている既存のイベント通知処理が行われる（ステップＳ１１１）。
【００６２】
これにより、フレームワーク起動時に読み込まれるＪａｖａシステムプロパティファイル１２に設定されたＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅを持つバンドルによって登録されたＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナは、他のＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒよりも先にイベント通知が行われる。
【００６３】
最後に、そのような優先的に処理されるイベントリスナ以外にも様々なイベントリストが複数登録されている可能性があることから、ステップＳ１１０又はステップＳ１１１の後、イベント未通知のイベントリスナが存在するか（Ｙｅｓ）否か（Ｎｏ）が判定される（ステップＳ１１２）。そして、その判定結果がＹｅｓの場合にはステップＳ１０９に戻って残りのイベントリスナにイベント通知を行い、一方、その判定結果がＮｏの場合には処理を終了する。
【００６４】
本実施の形態によれば、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナにイベント通知を行うイベント通知装置１００において、第１取得・保持部１４が、優先的にイベント通知を受けるバンドルの識別子をプロパティファイルから読み出して保持し、第２取得・保持部１６が、上記イベントリスナをＯＳＧｉフレームワークに登録する際にＢｕｎｄｌｅＣｏｎｔｅｘｔインタフェースのａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒメソッドを呼び出した全てのバンドルの識別子をイベント通知対象リストに保持し、通知部１８が、バンドルのステータスが変更した際に、そのイベント通知対象リストに保持されているバンドル識別子のうち上記プロパティファイルから読み出したバンドル識別子に合致するバンドル識別子のイベントリスナに対して優先的にイベント通知を行うので、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒとして登録されているイベントリスナへのイベント通知順序をバンドル単位で保証することができる。
【００６５】
〔第２の実施の形態〕
第２の実施の形態では、優先バンドルが複数存在する場合に、その複数の優先バンドル間において優先的なイベント通知を実現する方法について説明する。
【００６６】
本実施の形態に係るイベント通知装置１００の機能構成は、図１に示した第１の実施の形態と同様である。以下、第１の実施の形態で説明した機能との相違について説明する。
【００６７】
設定部１１は、複数の優先バンドルの各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅをＪａｖａシステムプロパティファイル１２にそれぞれ設定すると共に、それら優先バンドル間での優先順位を各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅに対応付けてそれぞれ設定する機能を有する。
【００６８】
例えば、図４に示すように設定する。図４（ａ）において、各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅの後にそれぞれ指定された各数値は、イベント通知の優先度を意味する。数値は１以上の整数で指定され、数値が低く設定されているバンドルが優先的にイベント通知される。数値で示す方法に代えて、アルファベット順に優先度を指定してもよいし、図４（ｂ）のようにＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅの記述順に優先度を指定してもよい。
【００６９】
第１取得・保持部１４は、複数の優先バンドルの各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅ及びその優先順位をＪａｖａシステムプロパティファイル１２から取得して、保持する機能を有する。
【００７０】
通知部１８は、照合部１７での照合結果、合致する複数のＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅの各イベントリスナに対して、設定された優先順位に基づき、優先的にイベント通知をそれぞれ行う機能を有する。
【００７１】
次に、イベント通知装置１００の動作を説明する。図５は、イベント通知装置１００の処理フローを示す図である。但し、複数の優先バンドルの各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅ及びその優先順位が既にＪａｖａシステムプロパティファイル１２に設定されているとする。
【００７２】
最初に、ＯＳＧｉフレームワークが起動すると（ステップＳ２０１）、Ｊａｖａシステムプロパティファイル１２が読み込まれ（ステップＳ２０２）、第１判定部１３により、その読み込んだＪａｖａシステムプロパティファイル１２内に優先バンドルのＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅが設定されているか（Ｙｅｓ）否か（Ｎｏ）が判定される（ステップＳ２０３）。
【００７３】
ステップＳ２０３の判定結果がＹｅｓの場合には、次に、第１取得・保持部１４により、その設定されている全ての優先バンドルの各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅがＪａｖａシステムプロパティファイル１２からそれぞれ読み出され、保持される（ステップＳ２０４）。尚、ステップＳ２０３の判定結果がＮｏの場合には、ステップＳ２０４を行うことなくステップＳ２０５に進む。
【００７４】
次に、イベントリスナがＯＳＧｉフレームワークに登録されると（ステップＳ２０５）、第２判定部１５により、そのイベントリスナ登録時にＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）が呼びされた際、そのＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）に登録されたＢｕｎｄｌｅＬｉｓｔｅｎｅｒの型（イベントリスナの型）が、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒ型か（Ｙｅｓ）否か（Ｎｏ）がｉｎｓｔａｎｃｅｏｆ演算子を用いて判定される（ステップＳ２０６）。
【００７５】
ステップＳ２０６の判定結果がＹｅｓの場合には、次に、第２取得・保持部１６により、ＢｕｎｄｌｅＣｏｎｔｅｘｔ＃ａｄｄＢｕｎｄｌｅＬｉｓｔｅｎｅｒ（ＢｕｎｄｌｅＬｉｓｔｅｎｅｒ）を呼び出した全てのバンドルからＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅがそれぞれ取得され、イベント通知対象バンドルリストに保持される（ステップＳ２０７）。尚、ステップＳ２０６の判定結果がＮｏの場合には、後述するステップＳ２１１に進む。
【００７６】
ここで、バンドルのステータス変更が発生した場合には（ステップＳ２０８）、照合部１７により、ステップＳ２０７で保持したイベント通知対象バンドルリスト内のＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅが、ステップＳ２０４で保持した各ＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅとそれぞれ照合される（ステップＳ２０９）。
【００７７】
その後、通知部１８により、イベント通知対象バンドルリスト内のうち、ステップＳ２０９の照合結果で合致する複数のＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅの各イベントリスナ（すなわち、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒであり、且つ優先的にイベント通知を受けるように設定されたバンドルのイベントリスナ）に対して、指定されている優先順位に従って、優先的にイベント通知が行われる（ステップＳ２１０）。
【００７８】
一方、合致しないＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅのイベントリスナ（すなわち、ＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒであるが、優先的にイベント通知を受けるように設定されていないバンドルのイベントリスナ）に対しては、ＯＳＧｉ仕様で規定されている既存のイベント通知処理が行われる（ステップＳ２１１）。
【００７９】
これにより、フレームワーク起動時に読み込まれるＪａｖａシステムプロパティファイル１２に設定されたＢｕｎｄｌｅＳｙｍｂｏｌｉｃＮａｍｅを持つバンドルによって登録されたＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒの各イベントリスナに対し、指定された優先順位に沿ってイベント通知が優先的に行われる。
【００８０】
最後に、そのような優先的に処理されるイベントリスナ以外にも様々なイベントリストが複数登録されている可能性があることから、ステップＳ２１０又はステップＳ２１１の後、イベント未通知のイベントリスナが存在するか（Ｙｅｓ）否か（Ｎｏ）が判定される（ステップＳ２１２）。そして、その判定結果がＹｅｓの場合にはステップＳ２０９に戻って残りのイベントリスナにイベント通知を行い、一方、その判定結果がＮｏの場合には処理を終了する。
【００８１】
本実施の形態によれば、優先的にイベント通知を受けるバンドルは複数であって、通知部１８が、その複数のバンドル識別子の優先順位に基づき、上記照合の結果、合致する複数のバンドル識別子の各イベントリスナにイベント通知をそれぞれ行うので、優先的にイベント通知を受けるバンドル間でのイベント通知順序を保証することができる。
【００８２】
すなわち、従来の技術では、バンドルのステータス変更が発生した際に、そのイベント通知を受けることができるＳｙｎｃｈｒｏｎｏｕｓＢｕｎｄｌｅＬｉｓｔｅｎｅｒのイベントリスナについて、権限さえあればどのバンドルでも登録でき、その呼び出し順序を保証することはできなかった。しかし、これまで説明したイベント通知装置１００を用いることによって、上記イベントを優先的に検知するべきバンドルに対する優先的なイベント通知を保証できるようになる。
【００８３】
最後に、第１の実施の形態で説明した優先バンドルや、第２の実施の形態で説明した優先順位が最も高い優先バンドルとしては、例えば、他のバンドルのリソース管理を行うメモリ管理バンドル（課題で説明したメモリ管理ＭＡ）がある。これにより、ヒープメモリ消費量の管理等、バンドルのリソース管理を特定のイベントを使って行う際に、管理を行うバンドルを優先することにより、優先順位不確定に起因するリソースの管理漏れを解消することができる。
【符号の説明】
【００８４】
１００…イベント通知装置
１１…設定部
１２…Ｊａｖａシステムプロパティファイル
１３…第１判定部
１４…第１取得・保持部（第１の保持手段）
１５…第２判定部
１６…第２取得・保持部（第２の保持手段）
１７…照合部
１８…通知部（通知手段）
Ｓ１０１〜Ｓ１１２、Ｓ２０１〜Ｓ２１２…ステップ
【図１】
0005458147.tif 000002
【図２】
0005458147.tif 000003
【図３】
0005458147.tif 000004
【図４】
0005458147.tif 000005
【図５】
0005458147.tif 000006
【図６】
0005458147.tif 000007