(57)【要約】【課題】オブジェクトからオブジェクトへのＪａｖａネイティブインタフェースマッピングの方法及び装置【解決手段】本発明は、Ｊａｖａのオブジェクト構造に非常に酷似しているオブジェクト構造を備えたＣ＋＋でネイティブコードを直接実行する方法及び装置を対象とする。この方法は、ＪａｖａをＣ＋＋オブジェクトへマッピングしてＪａｖａネイティブインタフェースを呼び出し、Ｃ＋＋オブジェクトをＪａｖａへマッピングして対応したＪａｖａオブジェクトを返却し、クラス名によりクラスファクトリを取得し返却し、Ｃ＋＋環境とＪａｖａ環境の両方でガーベッジコレクションを実行する。【選択図】なし【特許請求の範囲】
【請求項１】
少なくとも１つのオブジェクト記述はアプリケーションと関連付けられた互換性のあるコンピュータ言語であり、各アプリケーション側オブジェクトは関連付けられたアプリケーション側識別データを含む、少なくとも１つのアプリケーション側オブジェクト記述を含むアプリケーションを記憶する、第１のメモリ部を具備したメモリと、
実行可能コードは少なくとも１つのネイティブ側オブジェクト記述を含み、各ネイティブ側オブジェクト記述は関連付けられたネイティブ側識別データを含む、実行可能コードを選択されたプロセッサにネイティブ対応したフォーマットで記憶する、前記メモリの第２のメモリ部と、
アプリケーション側識別データをネイティブ側識別データと関連付ける手段を含み、前記少なくとも１つのアプリケーション側オブジェクト記述と、前記ネイティブ側オブジェクト記述との間でマッピングするオブジェクトマップ手段と、
前記少なくとも１つのアプリケーション側オブジェクト記述、及び前記少なくとも１つのネイティブ側オブジェクト記述と関連付けられたクラスを識別するクラス識別部と、
識別されたクラスと関連付けられたオブジェクトのインスタンス化のためのネイティブクラスファクトリをロードするクラスローダと、
を備える、オペレーティング環境とネイティブプロセッサ言語との間でオブジェクトからオブジェクトへマッピングするシステム。
【請求項２】
前記少なくとも１つのアプリケーション側オブジェクトの有無を判定する手段と、
前記少なくとも１つのアプリケーション側オブジェクトの有無の判定結果に応じて前記クラスローダを起動する手段と、
をさらに備える、請求項１に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングするシステム。
【請求項３】
クラスファクトリのロード後にクラスファクトリが未だ要求されているかどうかをテストする、クラスファクトリテスト手段と、
前記クラスファクトリテスト手段の出力に応じてネイティブクラスファクトリを選択的にアンロードする手段と、
をさらに備える、請求項２に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングするシステム。
【請求項４】
ネイティブ側オブジェクト記述が予め選択された範囲外であるかどうかをテストするオブジェクトテスト手段と、
前記オブジェクトテスト手段の出力に応じてネイティブ側オブジェクトへのリファレンスを除去するガーベッジコレクション手段と、
をさらに備える、請求項２に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングするシステム。
【請求項５】
前記ガーベッジコレクション手段の動作を周期的に可能にする手段をさらに備える、請求項４に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングするシステム。
【請求項６】
前記ガーベッジコレクション手段の動作を周期的に可能にする手段は、予め選択された繰り返しで周期的に有効にされる、請求項５に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングするシステム。
【請求項７】
前記関連付けられたネイティブ側識別データはオブジェクトポインタを含み、
前記関連付けられたアプリケーション側識別データはＪａｖａネイティブインタフェースのｊオブジェクト（ｊｏｂｊｅｃｔ）を含む、
請求項３に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングするシステム。
【請求項８】
少なくとも１つのオブジェクト記述はアプリケーションと関連付けられた互換性のあるコンピュータ言語であり、各アプリケーション側オブジェクトは関連付けられたアプリケーション側識別データを含む、少なくとも１つのアプリケーション側オブジェクト記述を含むアプリケーションをメモリの第１のメモリ部に記憶する工程と、
実行可能コードは少なくとも１つのネイティブ側オブジェクト記述を含み、各ネイティブ側オブジェクト記述は関連付けられたネイティブ側識別データを含む、実行可能コードを選択されたプロセッサにネイティブ対応したフォーマットで前記メモリの第２のメモリ部に記憶する工程と、
アプリケーション側識別データをネイティブ側識別データと関連付ける手段を含むオブジェクトマップを用いて、前記少なくとも１つのアプリケーション側オブジェクト記述と前記ネイティブ側オブジェクト記述との間でマッピングする工程と、
前記少なくとも１つのアプリケーション側オブジェクト記述、及び前記少なくとも１つのネイティブ側オブジェクト記述と関連付けられたクラスを識別する工程と、
識別されたクラスと関連付けられたオブジェクトのインスタンス化のためのネイティブクラスファクトリをロードする工程と、
を備える、オペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする方法。
【請求項９】
前記少なくとも１つのアプリケーション側オブジェクトの有無を判定する工程と、
前記少なくとも１つのアプリケーション側オブジェクトの有無の判定結果に応じてクラスローダを起動する工程と、
をさらに備える、請求項８に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする方法。
【請求項１０】
クラスファクトリのロード後にクラスファクトリが未だ要求されているかどうかをテストする工程と、
前記テストの出力に応じてネイティブクラスファクトリを選択的にアンロードする工程と、
をさらに備える、請求項９に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする方法。
【請求項１１】
ネイティブ側オブジェクト記述が予め選択された範囲外であるかどうかをテストする工程と、
ガーベッジコレクション手段を用いて、前記テストの出力に応じてネイティブ側オブジェクトへのリファレンスを除去する工程と、
をさらに備える、請求項９に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする方法。
【請求項１２】
前記ガーベッジコレクション手段の動作を周期的に可能にする工程をさらに備える、請求項１１に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする方法。
【請求項１３】
前記ガーベッジコレクション手段の動作を周期的に可能にする工程は、予め選択された繰り返しで周期的に有効にされる、請求項１２に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする方法。
【請求項１４】
前記関連付けられたネイティブ側識別データはオブジェクトポインタを含み、
前記関連付けられたアプリケーション側識別データはＪａｖａネイティブインタフェースのｊオブジェクト（ｊｏｂｊｅｃｔ）を含む、請求項１０に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする方法。
【請求項１５】
少なくとも１つのオブジェクト記述はアプリケーションと関連付けられた互換性のあるコンピュータ言語であり、各アプリケーション側オブジェクトは関連付けられたアプリケーション側識別データを含む、少なくとも１つのアプリケーション側オブジェクト記述を含むアプリケーションを記憶する、第１のメモリ部を具備したメモリと、
実行可能コードは少なくとも１つのネイティブ側オブジェクト記述を含み、各ネイティブ側オブジェクト記述は関連付けられたネイティブ側識別データを含む、実行可能コードを選択されたプロセッサにネイティブ対応したフォーマットで記憶する、前記メモリの第２のメモリ部と、
アプリケーション側識別データをネイティブ側識別データと関連付ける手段を含み、前記少なくとも１つのアプリケーション側オブジェクト記述と、前記ネイティブ側オブジェクト記述との間でマッピングするオブジェクトマップ手段と、
前記少なくとも１つのアプリケーション側オブジェクト記述、及び前記少なくとも１つのネイティブ側オブジェクト記述と関連付けられたクラスを識別するクラス識別部と、
識別されたクラスと関連付けられたオブジェクトのインスタンス化のためのネイティブクラスファクトリをロードするクラスローダと、
を備える、オペレーティング環境とネイティブプロセッサ言語との間でオブジェクトからオブジェクトへマッピングする命令を記憶した、コンピュータ読み取り可能な媒体。
【請求項１６】
前記少なくとも１つのアプリケーション側オブジェクトの有無を判定する手段と、
前記少なくとも１つのアプリケーション側オブジェクトの有無の判定結果に応じて、前記クラスローダを起動する手段と、
をさらに備える、請求項１５に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする命令を記憶した、コンピュータ読み取り可能な媒体。
【請求項１７】
クラスファクトリのロード後にクラスファクトリが未だ要求されているかどうかをテストするクラスファクトリテスト手段と、
前記クラスファクトリテスト手段の出力に応じてネイティブクラスファクトリを選択的にアンロードする手段と、
をさらに備える、請求項１６に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする命令を記憶した、コンピュータ読み取り可能な媒体。
【請求項１８】
ネイティブ側オブジェクト記述が予め選択された範囲外であるかどうかをテストするオブジェクトテスト手段と、
前記オブジェクトテスト手段の出力に応じてネイティブ側オブジェクトへのリファレンスを除去するガーベッジコレクション手段と、
をさらに備える、請求項１６に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする命令を記憶した、コンピュータ読み取り可能な媒体。
【請求項１９】
前記ガーベッジコレクション手段の動作を周期的に可能にする手段をさらに備える、請求項１８に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする命令を記憶した、コンピュータ読み取り可能な媒体。
【請求項２０】
前記ガーベッジコレクション手段の動作を周期的に可能にする手段は、予め選択された繰り返しで周期的に有効にされる、請求項１９に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする命令を記憶した、コンピュータ読み取り可能な媒体。
【請求項２１】
前記関連付けられたネイティブ側識別データはオブジェクトポインタを含み、
前記関連付けられたアプリケーション側識別データはＪａｖａネイティブインタフェースのｊオブジェクト（ｊｏｂｊｅｃｔ）を含む、
請求項１７に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする命令を記憶した、コンピュータ読み取り可能な媒体。
【請求項２２】
少なくとも１つのオブジェクト記述はアプリケーションと関連付けられた互換性のあるコンピュータ言語であり、各アプリケーション側オブジェクトは関連付けられたアプリケーション側識別データを含む、少なくとも１つのアプリケーション側オブジェクト記述を含むアプリケーションを、メモリの第１のメモリ部に記憶する工程と、
実行可能コードは少なくとも１つのネイティブ側オブジェクト記述を含み、各ネイティブ側オブジェクト記述は関連付けられたネイティブ側識別データを含む、実行可能コードを選択されたプロセッサにネイティブ対応したフォーマットで、前記メモリの第２のメモリ部に記憶する工程と、
アプリケーション側識別データをネイティブ側識別データと関連付ける手段を含むオブジェクトマップを用いて、前記少なくとも１つのアプリケーション側オブジェクト記述と前記ネイティブ側オブジェクト記述との間でマッピングする工程と、
前記少なくとも１つのアプリケーション側オブジェクト記述、及び前記少なくとも１つのネイティブ側オブジェクト記述と関連付けられたクラスを識別する工程と、
識別されたクラスと関連付けられたオブジェクトのインスタンス化のためのネイティブクラスファクトリをロードする工程と、
を備える、オペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする、コンピュータにより実施される方法。
【請求項２３】
前記少なくとも１つのアプリケーション側オブジェクトの有無を判定する工程と、
前記少なくとも１つのアプリケーション側オブジェクトの有無の判定結果に応じてクラスローダを起動する工程と、
をさらに備える、請求項２２に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする、コンピュータにより実施される方法。
【請求項２４】
クラスファクトリのロード後にクラスファクトリが未だ要求されているかどうかをテストする工程と、
前記テストの出力に応じてネイティブクラスファクトリを選択的にアンロードする工程と、
をさらに備える、請求項２３に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする、コンピュータにより実施される方法。
【請求項２５】
ネイティブ側オブジェクト記述が予め選択された範囲外であるかどうかをテストする工程と、
ガーベッジコレクション手段を用いて、前記テストの出力に応じてネイティブ側オブジェクトへのリファレンスを除去する工程と、
をさらに備える、請求項２３に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする、コンピュータにより実施される方法。
【請求項２６】
前記ガーベッジコレクション手段の動作を周期的に可能にする工程をさらに備える、請求項２５に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする、コンピュータにより実施される方法。
【請求項２７】
前記ガーベッジコレクション手段の動作を周期的に可能にする工程は、予め選択された繰り返しで周期的に有効にされる、請求項２６に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする、コンピュータにより実施される方法。
【請求項２８】
前記関連付けられたネイティブ側識別データはオブジェクトポインタを含み、
前記関連付けられたアプリケーション側識別データはＪａｖａネイティブインタフェースのｊオブジェクト（ｊｏｂｊｅｃｔ）を含む、
請求項２４に記載のオペレーティング環境とネイティブプロセッサ言語との間で、オブジェクトからオブジェクトへマッピングする、コンピュータにより実施される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本願は、２００３年８月１９日に出願された米国仮出願第６０／４９６，２５３号に基づく優先権を主張する。
【０００２】
本発明は、オブジェクトからオブジェクトへのＪａｖａ（登録商標、以下記載を省略する）ネイティブインタフェーシングの方法及び装置を対象にする。より詳細には、本発明は、Ｊａｖａランタイム環境におけるネイティブ又はレガシーコードの直接的な実行を容易にさせる方法及び装置を対象にする。
【背景技術】
【０００３】
仮想マシン及び仮想マシン内で動く特別なマネージドコードは、プラットフォーム独立性、実行安定性及び開発ツールの利用可能性といったいくつもの重要な利点が得られるので、徐々に普及し始めている。マネージドコードとは、仮想マシン環境で動き、特に、その仮想マシンによって管理されたメモリアロケーションを有するプログラムのコードである。
【０００４】
しかし、すべての既存アプリケーションをマネージドコードに書き換えることがどんなに利益があるように思われても、それは殆ど実行不可能な作業である。少なくとも、書き換えはイタレーション中で徐々に発生するに違いないので、費用効率は高くなり、扱いやすくなる。
【０００５】
ここで生じる問題は、マネージドコードアプリケーションに非常に重要性のあるレガシーアプリケーションとのインターフェースの方法の１つである。仮想マシンの設計者が解決しなければならない困難の１つは、仮想マシンとその環境の外で動作する既存アプリケーションとの間で通信を可能にする方法である。
【０００６】
仮想マシンは非常に古いコンピューティング概念で作られているが、最近まで商業ベンダーは、商業的な価値があり、かつ、必要に応じてスケーリングするためのランタイム能力を備えたマシンを実際に構築できなかった。サンマイクロシステムズとそのＪａｖａプラットフォームは、最初のこのようなベンダーと環境、例えば、Ｓｕｎ  Ｊａｖａ  ２  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅであると考えられる。
【０００７】
Ｊａｖａネイティブインタフェース、すなわち、ＪＮＩは、Ｊａｖａアプリケーションがネイティブコードのプログラミング言語には無関係に、任意のネイティブコードを呼び出せるように十分な汎用性を備えることを目的として設計されている。この原理は、例えば、圧倒的に最も汎用性があり、ネイティブとの相性のよいプログラミング言語であるＣ言語関数を生成するＪＮＩブリッジ開発にツールをもたらした。
【０００８】
Ｊａｖａプログラミングでは、オブジェクトは、関連した変数及びメソッドのソフトウェアバンドルである。ソフトウェアオブジェクトはすべて、ステート（ｓｔａｔｅ）とビヘイビア（ｂｅｈａｖｉｏｒ）をもつ。各ソフトウェアオブジェクトは、そのステートを１つ以上の変数に保持する。変数は識別子によって指定されたデータの項目である。ソフトウェアオブジェクトはメソッドでそのビヘイビアを実現し、一方、メソッドはオブジェクトに関連付けられた関数（サブルーチン）である。明確にするため、ソフトウェアオブジェクトが知っていること（ステート）とソフトウェアオブジェクトが行い得ること（ビヘイビア）のすべては、そのオブジェクト内の変数とメソッドによって表現される。正式にはインスタンス変数として知られる変数は、特定のオブジェクトのステートを格納する。インスタンスメソッドは、特定のインスタンスのステートを点検又は変更する。
【０００９】
オブジェクトの変数は、オブジェクトの中心、すなわち、核を構成する。メソッドは、そのオブジェクトの核を取り囲み、プログラム中の他のオブジェクトから隠蔽する。カプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）は、このメソッドの保護監督内でのオブジェクトの変数のパッケージングを定義するため使用される。Ｊａｖａでは、オブジェクトは、その変数及びメソッドのそれぞれに対して４種類のアクセスレベルのうちの１つを指定できる。これらのレベルは、他のオブジェクト及びクラスの中で、その特定の変数又はメソッドにアクセスするものがどれであるかを決定する。クラスは、ある種類のすべてのオブジェクトに共通した変数及びメソッドを定義する青写真すなわちプロトタイプであり、したがって、オブジェクトは、典型的に、あるクラスのインスタンスである。換言すると、クラスは、１つの名前で１つにまとめられた関連したメソッド及び変数のグループにより構成される。
【００１０】
Ｃ＋＋では、オブジェクトは、通常そのアドレス（ポインタ）によって識別される。このアドレスは、不適切に使用されるならば、深刻で見つけ難いダメージをプログラムに加える可能性がある。このような不適切な用法の例には、ダブルフリーの、古くなったポインタの使用などがある。「スマートポインタ」、又は、オブジェクト参照の管理は、オブジェクトポインタを、オブジェクトとは独立に管理される別個の軽量オブジェクトであり、Ｊａｖａにおけるオブジェクトリファレンスと非常に似ているオブジェクトリファレンスに置き換える。クラスローダは、ディスク上の対応したクラスファイルを見つけ、ファイルをＲＡＭに読み込み、ＲＡＭイメージを正当なバイトコードとして取り扱うことをシステムに教えるｊａｖａ．ｌａｎｇ．ＣｌａｓｓＬｏａｄｅｒ．ｄｅｆｉｎｅＣｌａｓｓを呼び出すため、これらのポインタを使用する。
【００１１】
一部のオブジェクト指向言語は、プログラマが作成したオブジェクトのすべてをそのプログラマが把握し、オブジェクトが必要でなくなったときそれらを明示的に破棄することを要求する。明示的なメモリ管理は退屈であり、誤りを起こしやすい。Ｊａｖａプラットフォームは、プログラマが希望の（勿論、ユーザのシステムの取り扱える範囲で制限される）個数のオブジェクトを作成し、それらを破棄することを気にしなくても済むようにさせるガーベッジコレクションを使用する。Ｊａｖａランタイム環境は、オブジェクトがそれ以上使用されることがないと判定したとき、オブジェクトを削除する。
【００１２】
特定のオブジェクトへのリファレンスがなくなったとき、そのオブジェクトはガーベッジコレクションの対象として適格である。変数に保持されるリファレンスは、その変数が範囲外へ出たとき、通常破棄される。或いは、プログラマ又はユーザは、その変数に特殊な値ヌル（ｎｕｌｌ）をセットすることにより、オブジェクトリファレンスを明示的に破棄する。プログラムは、同じオブジェクトに複数のリファレンスをもつ場合があり、１つのオブジェクトに対するすべてのリファレンスは、そのオブジェクトがガーベッジコレクションの対象として適格になる前に、破棄されなければならない。Ｊａｖａランタイム環境は、参照されなくなったオブジェクトによって使用されていたメモリを周期的に開放する、ガーベッジコレクタを備えている。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
大半のレガシーコード、又は、Ｊａｖａが通信しなければならないコードは、Ｃ＋＋又はその他のオブジェクト指向言語で実際に記述される。Ｃ＋＋は、その性質によって、概念の点でＪａｖａに非常に近い。どちらのオブジェクト指向言語もクラス、オブジェクト、ネイティブクラスファクトリなどを使用する。実際に、Ｃ＋＋とＪａｖａは非常に近いので、キーワード、シンタックスなどのような共通の言語構造を共有する。しかし、ＪＮＩは、Ｃ言語バインディングだけを提供し、Ｃ＋＋言語のために必要なバインディングが欠けている。
【００１４】
したがって、Ｊａｖａオブジェクトの世界とＣ＋＋オブジェクトの世界との間の隔たりを橋渡しするための方法及び装置が必要である。
【課題を解決するための手段】
【００１５】
本発明によれば、Ｊａｖａのオブジェクト構造に非常に酷似しているオブジェクト構造を備えたＣ＋＋で、ネイティブコードを直接実行する方法及び装置が提供される。この方法は、オブジェクトモデル、実行の性能又はその他の特性を妨げることなく、ＪａｖａネイティブインタフェースによってＪａｖａオブジェクトをＣ＋＋オブジェクトへマッピングする。本発明は、また、Ｊａｖａガーベッジコレクションの欠陥を補償する、構造化可能なＣ＋＋ガーベッジコレクタを含む。
【００１６】
さらに、本発明によれば、ｊオブジェクト（ｊｏｂｊｅｃｔ）の値を獲得し、ＪａｖａオブジェクトをＣ＋＋オブジェクトへマッピングする方法が提供される。次に、ｊオブジェクトの値の判定が行われ、ここで、非ゼロ値は有効なＣ＋＋オブジェクトポインタを示し、ゼロ値はｊオブジェクトが未だＣ＋＋バウンダリへ渡されていないことを示す。ｊオブジェクトインスタンスは、ｊオブジェクトのＪａｖａクラス名を得るため使用される。クラス名は、クラスローダへ渡され、対応したクラスファクトリを返却するように要求される。クラスファクトリを初期化し、受信された元のｊオブジェクトに対応するネイティブ側オブジェクトをインスタンス化する。最後に、Ｃ＋＋オブジェクト型及びメソッドは、ＪＮＩラッパールーチンを用いてコンパイル時に解決される。
【００１７】
さらに本発明によれば、リファレンスをスマートポインタとしてＣ＋＋オブジェクトへ返却する工程を含む、Ｃ＋＋オブジェクトをＪａｖａオブジェクトへマッピングする方法が提供される。次に、スマートポインタは、オブジェクトＩＤ、すなわち、キーが問い合わされる。キーは、そのキーを作成する必要があるかどうかを判定するため、既存のマップと比較される。そのキーに対応したマップ内の値が取り出され、ｊオブジェクトの形式になる。ｊオブジェクトＩＤが次に返却される。
【００１８】
さらに本発明によれば、マネージドクラス名の要求を受信し、クラス名をネイティブクラス名にマッピングし、クラスファクトリがロードされたかどうかを判定する工程を含む、クラス名によりクラスファクトリを獲得し返却する方法が提供される。クラスローダは、ファクトリを格納した実行可能モジュールをロードし、事前合意モジュールバインディングポイントを呼び出すことにより、クラスファクトリインタフェースコントラクトを取り出す。
【００１９】
さらに本発明によれば、ガーベッジコレクタを呼び起こし、弱いリファレンスのためのオブジェクトマップを反復し、ネイティブ側スマートポインタを回収し、スマートポインタによって参照されるネイティブ側オブジェクトの参照数を減少させる工程を含み、対応したＪａｖａ側対応部が範囲を外れているすべてのネイティブ側オブジェクトが削除される、ネイティブ側ガーベッジコレクションを実行する方法が提供される。
【００２０】
本発明のさらに別の利点及び態様は、本発明を実施するため最も適したベストモードの一例としてのみ、本発明の好ましい実施形態が明らかにされ記載された以下の説明から、当業者に容易に理解されるであろう。本発明はその他の異なる実施形態が可能であり、そのいくつかの細部は、本発明から全く制限されることなく、種々の明白な態様を変更可能であることが理解されるであろう。したがって、図面及び解説は、本質的に例示であり、限定ではないとして考えられるであろう。
【発明を実施するための最良の形態】
【００２１】
本発明は、ある言語から別の言語へのオブジェクトの移動のための自然なマップを提供する装置及び方法を対象とする。より詳細には、本発明は、Ｊａｖａネイティブインタフェースを使用してオブジェクトからオブジェクトへマッピングする方法及び装置を対象とする。
【００２２】
オブジェクト指向プログラミングでは、オブジェクトは、関連した変数及びメソッドのソフトウェアバンドルである。本発明は、オブジェクトマップとクラスローダとガーベッジコレクタの３つのコンポーネントの相互作用で機能する。オブジェクトマップは、瞬時かつ低コストで、ネイティブ側からマネージド側へオブジェクトをマッピングする。後述される好ましい実施形態では、マップは、Ｎ分木（Ｎ−ａｒｙ  ｔｒｅｅ）として実現された標準テンプレートライブラリマップである。本発明のオブジェクトマップは、ネイティブオブジェクトＩＤであるキーと（Ｃ＋＋用語では、これはオブジェクトポインタである）、マネージド側オブジェクトＩＤである値と（Ｊａｖａネイティブインタフェース用語では、これはｊオブジェクト（ｊｏｂｊｅｃｔ）である）、を有する。
【００２３】
クラスローダコンポーネントは、その特定のクラスのオブジェクトをインスタンス化する責任を負うネイティブクラスファクトリを実行するために識別及びロードを担う。後述される好ましい実施形態では、このローディングは要求に応じて実行され、すなわち、特定のクラスのオブジェクトがマネージド側からネイティブ側へはじめて「渡る」ときに常に実行される。換言すると、はじめてクラスローダがネイティブ側オブジェクトをインスタンス化するように要求され、対応したクラスファクトリがロードされないとき、クラスローダは、実行可能モジュールをロードし、任意のクラス初期化を実行し、この場合に限り、クラスファクトリにオブジェクトをインスタンス化するように要求する。クラスローダは、クラスローダの実施に固有の基準に基づいて、クラスファクトリをアンロードすることを決定する。これは、当業者によってＪａｖａプログラミング言語に標準的な技術であると認められるであろう。好ましい実施形態では、クラスファクトリは決してアンロードされず、システム停止、すなわち、シャットダウン時に限り消滅するであろう。当業者に容易に理解されるように、代替的な方法がクラスファクトリをロード及びアンロードするため使用される。このような方法には、バックグラウンドスレッドへのロード、関連したクラスファクトリのロード、一定の休止期間後のアンロード、最長不使用（Ｌｅａｓｔ  Ｒｅｃｅｎｔｌｙ  Ｕｓｅｄ）ファクトリのアンロード、及び、最小使用頻度（Ｌｅａｓｔ  Ｒｅｃｅｎｔｌｙ  Ｕｓｅｄ）ファクトリのアンロードが含まれるが、これらに限定されない。
【００２４】
ガーベッジコレクタがネイティブ側オブジェクトへのリファレンスを破棄するのは、それらのマネージド側対応部が範囲外になるときである。すなわち、ガーベッジコレクタは、マネージド側対応部がＪａｖａプログラミングに固有である通常のガーベッジコレクションプロセス中に除去されたとき、ネイティブ側オブジェクトへのポインタを除去する。好ましい実施形態では、ガーベッジコレクタは、メモリを開放するため５秒間隔で作動する。
【００２５】
図１を参照すると、言語Ａのオブジェクト１０のインスタンスデータにオブジェクトリファレンス１４を保持する、簡単なブロック図が示されている。図１は、マネージド側言語である言語Ａとネイティブ側言語を表す言語Ｂの、２つの別個のプログラミング言語からのオブジェクトを表す。オブジェクト１０は言語Ａで記述され、内部オブジェクトリファレンス１４を有することが表示されている。オブジェクトリファレンス１４は、言語Ａのオブジェクト１０内に存在し、対応した言語Ｂのオブジェクト１２へのポインタとして作用する。すなわち、内部オブジェクトリファレンス１０は、言語Ｂのオブジェクト１２のオブジェクトＩＤを格納する。図２は、一方の型のオブジェクトリファレンスから別の型へのマップを保持する例を示している。図２を参照すると、言語Ａのオブジェクト２０と言語Ｂのオブジェクト２２とマップ２４とが示されている。図２に示されるように、マップ２４はキー２６及び値２８を格納する。キー２６はネイティブオブジェクト識別情報を表し、値２８はマネージド側オブジェクト識別情報を表す。動作中、マップ２４は、複数のキーとそれに対応した値を格納する。これは、マップ２４がプログラミング言語Ａからプログラミング言語Ｂへの翻訳を容易に行うことを可能にする。
【００２６】
図３を参照すると、Ｊａｖａオブジェクト３０からＣ＋＋オブジェクト３４への翻訳のためのマップＣが示されている。図３はＪａｖａとＣ＋＋を表すが、当業者にわかるように、マップＣはその他のオブジェクト指向プログラミング言語に適用することができる。Ｊａｖａすなわちマネージド側のオブジェクト３０は、ｊオブジェクト型のインスタンスの形で与えられる。Ｊａｖａオブジェクト３０には、所定の値を有する変数を含むポインタ３２が不可欠である。この変数の値が非ゼロであるならば、それは、有効なＣ＋＋オブジェクトポインタ３２として解釈される。これは、Ｊａｖａオブジェクト３０が、Ｊａｖａネイティブインタフェース（ＪＮＩ）を介して、Ｃ＋＋オブジェクト３４に格納されたメソッドを呼び出すことを可能にする。
【００２７】
図４は、Ｃ＋＋からＪａｖａへ翻訳するためのマップ、より正しくは、Ｃ＋＋プログラムがＪａｖａプログラムに存在するメソッドを呼び出すか、若しくは、変数を獲得するために必要なマップを示している。マップ４４は、キー４６と対応した値４８とを格納する。当業者に明らかであるように、キー４６及び値４８は１つしか示されていないが、ここで検討されている方法は、複数のキー及び対応した値に適用可能である。単一キー４６及び単一値４８の使用は、例示の目的だけのためである。図４に戻ると、Ｃ＋＋オブジェクト４０及びＪａｖａオブジェクト４２が存在する。Ｃ＋＋からＪａｖａへの翻訳を容易化するため、マップ４４は、ネイティブオブジェクトＩＤ（キー４６のようなＣ＋＋オブジェクトポインタ）と、マネージド側オブジェクトＩＤ（ＪＮＩ  ｊオブジェクト又は値４８）を利用する。各キー４６は１つのＣ＋＋オブジェクト４０だけを指示し、各値４８は１つのＪａｖａオブジェクト４２を表すので、マップは２つのプログラミング言語間の翻訳をすることができる。
【００２８】
Ｊａｖａオブジェクト４２が、レガシープログラムに存在するメソッド又は変数、例えば、Ｃ＋＋オブジェクト４０に格納されているメソッド又は変数を読み出すとき、値４８はマップ４４によって登録される。マップ４４は、もしあるとすれば、どのキーがＪａｖａオブジェクト４２の値４８に対応するかを判定するため、記憶されたキーを問い合わせる。マップ４４が値４８に対応するのはキー４６であることを判定したとき、マップはキー４６をアクティブ化する。キー４６はＣ＋＋オブジェクト４０を指示し、これにより、Ｊａｖａオブジェクト４２が求めていたメソッド又は変数が取り出される。
【００２９】
上記の非常に簡単な説明は、以下に残りの図面を参照して例示される方法及び装置の概要を与えることを意図している。図５を参照すると、ＪａｖａオブジェクトをＣ＋＋オブジェクトへ翻訳、すなわち、マッピングし、その中に格納されたメソッドを呼び出すときの本発明の動作を記述するフローチャートが示されている。明らかではあるが、Ｊａｖａ及びＣ＋＋が使用されているのは、単に例示の目的のためであり、この方法をＪａｖａ翻訳又はＣ＋＋翻訳だけに制限するためであるとして解釈されるべきではない。当業者は、以下に説明される方法が、Ｊａｖａ及びＣ＋＋を表していても、その他のオブジェクト指向言語間に適用できることを認めるであろう。
【００３０】
Ｊａｖａ、すなわち、マネージド側オブジェクトは、ｊオブジェクト（ｊｏｂｊｅｃｔ）型のインスタンスの形で与えられる。このインスタンスは、所定のＪａｖａオブジェクトメンバー変数であるｎａｔｉｖｅＣｔｘを解決するため使用される。ステップ５０２から始めて、ＪＮＩコールを使用して、ｎａｔｉｖｅＣｔｘの値が取り出される。ＪＮＩコールを使用して取り出す手段は技術的に周知であり、当業者はこの点でその用法を理解するであろう。この方法は、ｎａｔｉｖｅＣｔｘの値が判定されるべき判定ステップ５０４まで進む。例えば、ゼロ値は、ｎａｔｉｖｅＣｔｘが属するクラスが未だ見つかっていないことを表す。非ゼロ値は、ステップ５０２で取り出された値が有効なＣ＋＋オブジェクトポインタを表現することを表す。ステップ５０４において、非ゼロ値がステップ５０２で取り出されたことが判定されると、この方法はステップ５０６へ進み、その値は、有効なＣ＋＋オブジェクトポインタとして解釈される。ステップ５０８において、有効なＣ＋＋オブジェクトポインタは、対応したメソッド、すなわち、そのポインタが参照するＣ＋＋オブジェクトを呼び出すため使用される。ステップ５１０で、Ｃ＋＋オブジェクト型及びメソッド名は、適切なＪＮＩラッパールーチンの使用によってコンパイル時に解決される。この方法はステップ５２２へ進み、そこで、ｎａｔｉｖｅＣｔｘの値は、ガーベッジコレクション中に値の除去を禁止して、アクティブリファレンスを反映するため更新される。
【００３１】
ステップ５０４を再度参照すると、ｎａｔｉｖｅＣｔｘの値がゼロであると判定されたとき、Ｊａｖａオブジェクトは未だネイティブ（Ｃ＋＋）側へ渡されていない。この場合、ｊオブジェクトインスタンスは、ステップ５１２でオブジェクトのＪａｖａクラス名を判定するため使用される。このようにして判定されたクラス名は、次にステップ５１４でクラスローダへ渡され、クラスローダは対応したクラスファクトリを返却するように要求される。クラスローダは、ステップ５１６に示されるように、クラスファクトリを返却する前に、クラスファクトリをロードし初期化する。当業者に明らかであるように、クラスファクトリの初期化はクラスファクトリの返却に続いて行われても構わない。ロードされ初期化されたクラスファクトリは、次に、ステップ５１８でプログラムへ返却される。ステップ５２０において、ネイティブ側オブジェクトは、ネイティブ側オブジェクトにインスタンス化され、すなわち、元のＪａｖａのｊオブジェクトは対応したＣ＋＋オブジェクトに翻訳されている。ｎａｔｉｖｅＣｔｘの値は次にステップ５２２で更新される。当業者に明らかであるように、ｎａｔｉｖｅＣｔｘの値の更新は、Ｃ＋＋オブジェクトポインタをＪａｖａオブジェクトに格納するためにＪＮＩメソッドを使用することと等価的である。このようにして、プログラムは、ＪａｖａをＣ＋＋オブジェクトへマッピングし、本発明のＪＮＩメソッドを呼び出す。
【００３２】
Ｃ＋＋オブジェクトのＪａｖａへのマッピングと、オブジェクトの返却は、図６のフローチャートに例示されている。Ｃ＋＋オブジェクトリファレンスは、ステップ６０２において、「スマートポインタ」の形式でプログラムに返却される。スマートポインタはオブジェクトリファレンス管理ツールであり、通常のＣ＋＋オブジェクトポインタをオブジェクトリファレンスに置き換える。スマートポインタである軽量オブジェクトリファレンスは、次に、ステップ６０４で、それが参照するオブジェクトＩＤのＩＤについて問い合わされる。すなわち、スマートポインタは、参照先のＣ＋＋オブジェクトポインタを明らかにすることが要求される。このようにステップ６０４でキーが取り出されると、プログラムは、ステップ６０６へ進み、そのキーがマップに存在するかどうかを判定する。そのキーがマップに存在しない場合、プログラムはステップ５１２へ戻り、そこから進む。ステップ６０６でＹＥＳ判定がなされた場合、キーに対応する値がステップ６０８で取り出され、これにより、プログラムにｊオブジェクトインスタンスが与えられる。ｊオブジェクトＩＤは次にステップ６１０で返却される。このように、Ｃ＋＋オブジェクトはＪａｖａへマッピングされ返却される。
【００３３】
図５及び６に記載された上記のネイティブＣ＋＋コードの直接的な実行は、Ｃ＋＋コードが特有のＪａｖａ構造に非常に酷似している構造を備えることを可能にさせる。このタイプの実行はアプリケーション・プログラマ・インタフェース（ＡＰＩ）バインディングに適当であり、この実行はＣ＋＋ネイティブ側で完全に達成され、Ｊａｖａ側は単にＡＰＩのバインディング（ラッパー）である。
【００３４】
最初に図５を再度参照すると、ステップ５１４において、クラス名は、対応したクラスファクトリを取り出すためクラスローダへ送信されている。したがって、クラスローダは、特定のマネージド（Ｊａｖａ）クラス名（このクラス名はｊオブジェクトタイプに基づいている）に対するクラスファクトリを返却するように要求されている。次に図７を参照すると、クラスローダが要求された情報を取り出し返却する方法のフローチャートが示されている。クラスローダは、ステップ７０２で、特定のマネージド（Ｊａｖａ）クラス名に対するクラスファクトリを返却する要求を受信する。クラスローダは、次に、ステップ７０４でマネージド（Ｊａｖａ）クラス名をネイティブ（Ｃ＋＋）クラス名にマッピングする。当業者に理解されるように、オブジェクト指向プログラミングはクラスレイアウト／クラス関数を利用するので、本発明のクラスローダは任意のオブジェクトからオブジェクトへのプログラムで利用される。クラスローダは、次に、ステップ７０６で、ステップ７０４においてマッピングされたネイティブクラス名に対応するクラスファクトリが既にロードされているかどうかを判定しなければならない。対応するクラスファクトリが予めロードされている場合、クラスローダは、ステップ７１８でクラスファクトリをプログラムに返却する。
【００３５】
クラスローダがステップ７０６において必要なクラスファクトリは未だロードされていないと判定した場合、クラスローダは、ステップ７０８でクラスファクトリを格納する実行可能モジュールをロードする。クラスローダは、次に、ステップ７１０で事前合意モジュールバインディングポイントを呼び出し、ステップ７１２でクラスファクトリインタフェースコントラクトを取り出す。ステップ７１４において、取り出しは不成功であることが判定された場合、クラスローダはステップ７０８へ戻り、クラスファクトリを格納する実行可能モジュールの再ロードを試みる。ステップ７１４で取り出しは成功であることが判定されると、この方法はステップ７１６へ進み、クラスローダは、将来使用するためのリファレンス及びコントラクトの少なくとも一方を記憶する。このように取り出されたクラスファクトリは、次にステップ７１８で返却される。
【００３６】
したがって、Ｃ＋＋クラスファクトリは、特定のクラスのインスタンスが必要であるとき、又は、Ｊａｖａクラスローダが特定のパッケージをロードしたときに、いつでも要求に応じてロードすることができる。これは、必要なときに限り動的にロードされるＣ＋＋コードの非常にモジュール化された構造に対して、特に有用である。このようにして、プログラムは、クラス名を用いてクラスファクトリを取り出し、返却する。
【００３７】
Ｊａｖａプログラミング言語に本来備わっている性質として、ガーベッジコレクションは、使用されていないオブジェクトを除去し、メモリ利用率を高めるために発生する。しかし、本発明は、さらに、ネイティブ側ガーベッジコレクタ、又は、単にＣ＋＋リファレンスを回収するガーベッジコレクタを提供する。すなわち、十分に利用されていないＪａｖａオブジェクトが除去されるとき、対応したＣ＋＋スマートポインタも回収され除去される。次に、図８を参照すると、本発明のガーベッジコレクタの動作のフローチャートが示されている。使用されていないオブジェクト及びリファレンスを回収するプロセスは、ガーベッジコレクタがスリープ状態からウェイクアップされるステップ８０２で始まる。当業者に明らかであるように、Ｊａｖａは、ガーベッジコレクタの手動アクティべーションと、自動アクティべーションの両方が可能である。この点で好ましい実施形態では、ガーベッジコレクタは、使用されていない項目を破棄するため、５秒ごとに作動するようセットされる。ガーベッジコレクタは、ステップ８０４で、Ｊａｖａのｊオブジェクトごとにオブジェクトマップを繰り返すため始動する。ステップ８０４における終了後、ガーベッジコレクタは、ステップ８０６で、各リファレンスが弱いリファレンスであるか否かを判定しなければならない。弱い（ｗｅａｋ）は、範囲外又は使用されていないオブジェクト若しくはリファレンスを表す、Ｊａｖａの専門用語である。弱くないリファレンスはそのまま残される。ガーベッジコレクタは弱いリファレンスを見つけた場合、ステップ８０８でネイティブ側リファレンスを回収する。この目的のため、このように回収されたリファレンスはＣ＋＋スマートポインタである。スマートポインタ、すなわちリファレンスは、破棄され、ステップ８１０でＣ＋＋オブジェクトの参照数を減少させる。この減少は、参照数がゼロまで低下した場合、最終的にＣ＋＋オブジェクト自体の除去につながる。
【００３８】
ガーベッジコレクションの最終結果は、Ｊａｖａ側の対応部が範囲外になったＣ＋＋オブジェクトの除去及び破棄である。Ｊａｖａガーベッジコレクタは、この時点では未だリファレンスを回収しないが、それに関連したネイティブリソース（Ｃ＋＋オブジェクト）は解放される。Ｊａｖａリファレンスは決して再び作動させられることがないので、「ｎａｔｉｖｅＣｔｘ」の例は更新されることがない。回収及び破棄のプロセスが終了した後、ガーベッジコレクタはステップ８１２へ進み、再び５秒ごとに作動されるまで「スリープ」状態に入る。
【００３９】
したがって、ネイティブ側によって割り当てられたメモリは、Ｊａｖａ（マネージド）側から割り当てられたメモリとは別個に管理される。Ｊａｖａガーベッジコレクションは周知の如く控えめであるので、正味の結果はメモリ利用率のかなりの量の改善である。
【００４０】
好ましい実施形態では、本発明はソフトウェアで実現されるが、当業者が容易に認めるように、本発明は、ハードウェアで実現してもよく、或いは、ソフトウェアとハードウェアの組み合わせで実現してもよい。
【００４１】
好ましい実施形態を詳細に説明したが、添付の特許請求の範囲に記載されるような本発明の精神及び範囲を逸脱することなく、様々の変更、置換、及び修正をなし得る。本発明の本質を説明するために記載され例示された部品の細部、材料及び配列の様々な変更は、添付の特許請求の範囲に記載されるような発明ならびにその等価物の原理及び範囲内で当業者によってなされることがわかるであろう。
【図面の簡単な説明】
【００４２】
【図１】オブジェクトリファレンスを別のオブジェクトのインスタンスデータ内に保持する例を説明するブロック図である。
【図２】一方のオブジェクト型のオブジェクトリファレンスから他方のオブジェクト型へのマップを保持する例を説明するブロック図である。
【図３】Ｃ＋＋オブジェクトのオブジェクトリファレンスを、Ｊａｖａオブジェクトのインスタンスデータ内に保持する例を説明するブロック図である。
【図４】Ｊａｖａ型オブジェクトのオブジェクトリファレンスからＣ＋＋型オブジェクトへのマップを保持する例を説明するブロック図である。
【図５】ＪａｖａのＣ＋＋へのマッピングとメソッドの呼び出しを表すフローチャートである。
【図６】Ｃ＋＋のＪａｖａへのマッピングとオブジェクトＩＤの返却を表すフローチャートである。
【図７】クラス名によるクラスファクトリの獲得及び返却を表すフローチャートである。
【図８】ガーベッジコレクタの使用されないリファレンスの破棄を表すフローチャートである。
【符号の説明】
【００４３】
１０、２０…言語Ａオブジェクト
１２、２２…言語Ｂオブジェクト
１４…オブジェクトリファレンス
２４、４４…マップ
２６、４６…キー
２８、４８…値
３０、４２…Ｊａｖａオブジェクト
３２…Ｃ＋＋オブジェクトポインタ
３４、４０…Ｃ＋＋オブジェクト
【図１】
2005063449.tif 000002
【図２】
2005063449.tif 000003
【図３】
2005063449.tif 000004
【図４】
2005063449.tif 000005
【図５】
2005063449.tif 000006
【図６】
2005063449.tif 000007
【図７】
2005063449.tif 000008
【図８】
2005063449.tif 000009
【外国語明細書】
2005063449000001.pdf